使用Linux工具诊断网络问题

1、使用Linux工具诊断网络问题如果结合使用Linux发行版Fedora Core和开放源代 码软件包libpcap 、tcpdump、iptraf以及多路由器流量图示器（MRT）就可以为查明网络问题产生的根源提供有价 值的信息。连接速度慢在第一个例子中，一个小型网络使用384Kbps速率的ISDN连接至因特网，其问题在为网络排除故障时，不管面临哪种情形，把嗅探器（sniffer ）放在合适位置，深入了解 网络拓扑结构至关重要。我对该网络并不熟悉，于是与网络 管理员一起进行了排查。网络很简单：通过网络地址转换（NAT协议转换成单一公共IP地址的专用子网，由两只集 线器和一只交换机（几台本地服务器

2、与交换机相连）负责分 布，一条线路从该交换机连接到因特网，如图1所示。轻则速度缓慢，重则不稳定。局域网性能良好，只是因特网流量 受到了影响。因为这只速率100Mbps的交换机没有端口镜像（portmirroring ）这项功能，我从自己的网络工具包中取出了一 只小型集线器，把它插入在100Mbps交换机和ISDN路由器之间，如图2所示。没错，这改变了原有的网络拓扑结构， 但因为没有端口镜像功能端口镜像功能可以把一个端口上经过的所有流量复制到另一个端口上，所以插入集线器 是最好的选择办法了。这种办法有着诸多优点，虽然端口镜 像不会显示物理层错误，但我还是通常偏爱端口镜像功能。我把Linux嗅探器

3、接到先前插入的集线器，继续进行探 测：只要使用基本的tcpdump -i -n 命令。因为我希望问题 属于某一种类型的数据包，与数据包里面实际所含内容没有 关系。我猜对了，因为记录的入站数据包几乎全都是来自不 同IP地址的因特网控制消息协议（ICMP）回应请求。打电 话给因特网服务提供商（ISP）要求封阻入站ICMP回应请求 后，问题马上得到了解决。Napster耗用带宽第二个例子与因特网带宽使用量增加有关，但还不至于 发展到导致不稳定性的地步。当时因特网带宽的使用量接近 了需要带宽升级的地步。单单添加带宽来解决这类问题似乎 是项合理的措施，但是如果与用户工作毫无关系的某个应用 引起使用量增加

4、，那么也许没有必要花这笔费用。我的任务就是，确定带宽使用量的增加是由于工作需要、拒绝服务攻击还是其他什么因素。该网络类似第一个例 子，但交换机能够对连接到出站路由器的端口进行镜像处 理。局域网管理员为出站路由器设置了端口镜像功能，以便 把复制的所有流量引导至我接入嗅探器的那只端口上。Tcpdump会话本身不会获得任何明显的结果，于是我决 定试试趋势分析。我在网络边界开始了iptraf 会话选择端口分析是为了确定流量模式，结果发现传输到TCP端口6699的流量很大。在路由器端通过访问控制列表（ACL）封阻该端口，就可以让网络流量模式恢复正常。进一步研究后发现，使用这个端口的是当时属于第一个大规模

5、的因特网对等音乐共享服务：Napster。由于Napster音乐共享不属于工作计划的一部分，所以就圭寸阻了该端口， 这样就用不着掏大笔费用升级因特网带宽了。第三个例子围绕名为 Slammer蠕虫的微软SQL Server 2000和微软桌面引擎2000漏洞，这个蠕虫从技术上来说又 叫W32.SQLExp.Worm赛门铁克公司对这个漏洞有详细介绍， 不过当时我遇到这个问题时，显然不知道原因是什么。症状 类似第一个例子当中的ICMP拒绝服务攻击，因为因特网连 接速度变慢了。不过这个网络比较复杂：局域网由几个子网组成，这些子网通过路由器互连起来，如图3所示。幸好，使用MRT刮以定期收集到有关每个子网

6、的流量 模式的基准统计信息，因而可以了解正常流量应当是什么样 的历史信息。我们立即发现，其中三个子网的入站流量（来 自子网本身）比正常情况大得多。直觉告诉我，问题就出现 在这些子网上。不过，因为受到影响的是因特网连接，所以 在网络边界进行探测再度成了合理的步骤。网络管理员在网络边界处安装了Linux嗅探器，与边界相连的是100Mbps速率的边界网络交换机，该交换机通过 tcpdump不断收集统计信息，并且每隔15分钟，然后通过cron任务和FTP把结果转储到中央服务器。分析这些日志后发现：通过三个内部IP地址的流量占了流量的大部分。我在嗅探器上运行了 iptraf 会话，因为局域网管理员 以前

7、也加载了这个软件包。尽管我期望看到针对单个TCP端口出现多次访问（这是拒绝服务攻击的常见特征），但实际情况并非如此。然而，底部的iptraf 容器却在迅速滚屏显示发往某个UDP端口： 1434的用户数据报协议（UDP数据 包。把三个核心局域网路由器上的这个端口封阻后，拒绝服 务攻击就不复存在了。不过，含有受感染机器的三个子网的 性能仍相当低，这是由于这些被感染机器带来了很大的网络 流量。如果记有精确的网络记录，就有可能把IP地址与交换 机端口关联起来、找到合适的端口，并且以逻辑或者物理方 式断开端口。但问题是没有这样的记录。幸好，网络管理员运行了网络管理软件包，可以查询子 网上的所有交换机，确

8、定某个介质访问控制（MAC地址在何处连接。把 MAC地址和IP地址关联起来，这就如同查询 核心路由器的地址解析协议表这么简单。端口确认后，被感染的机器处于断开状态，直到问题解 决后再让它们连接到网络上，因而恢复了网络运作。核心路由器被感染确认及解决第四个例子中的问题相当困难。问题不是在 于漏洞类型，也不在于生成流量的数量；实际上，流量不像 前几个例子那样让因特网带宽处于满负荷状态。区别在于， 核心网络路由器的感染方式。网络拓扑结构类似第三个例子。问题不仅仅表现为因特 网连接速度缓慢，还表现为子网之间的连接速度也很慢，就 连以物理和逻辑方式与同一路由器相连接的那些子网也是 这样。与第三个例子一样

9、，也建立了MRTC查询机制，以监控每个路由器的子网流量以及核心路由器的CPU负载。查看MRTG勺图示结果后即可看到正确的稳定流量和CPU使用率。MRTG勺特点之一就是，如果它无法查询具有简单网 络管理协议（SNMP功能的设备，会在统计信息最后取得的 值上显示一条水平线，不管是什么值。这个例子也是如此。 MRTG艮务器工作正常得到了证实。大多数企业核心路由器具有类似Linux中top命令的功能。这个命令实际上显示了 CPU使用率最高的路由器进程。 我试图向其中一个路由器开启终端会话，但没有成功。幸好，每个核心路由器都有调解解调器连接到路由器的通信端口， 所以使用 Windows中的超级终端（Hy

10、perTerminal ）程序， 就能够拨号进入其中一个路由器的控制台会话。虽然连控制台连接的速度也很慢，我还是得以查明 ：路 由器的CPU使用率达到了峰值：100% CPU使用率最高的进 程是路由进程本身。探测子网是理所当然的步骤。探测表明多个源IP地址和目的地IP地址集中于一个 TCP目的地端口： 135。这时，全凭经验的我信心十足地建议： 网络管理员应当利用 ACL封阻每个路由器的 TCP端口 135。 我以为，我们可以以后处理停止正常工作的微软应用软件， 因为恢复网络功能极为重要。让我感到郁闷的是，封阻该端 口后并没有降低路由器 CPU的使用率。路由器是第三层交换设备，正因为如此，它们

11、通常被称 为第三层交换机。这意味着，路由器根据第三层（这里是IP） 地址来确定数据包的目的地。我查明：ACL之所以不起作用，原因就是路由器在实施 ACL规则之前，仍得处理数据包的第三层信息。正是这个原因导致路由器CPU的使用率达到高峰以及随后的网络拥塞。下面介绍为什么有必要深入了解开放系统互连（OSI）参考模型。每个子网分布交换机都是能够识别第三层和第四 层的企业交换机。实际上这意味着，类似ACL的命令可以在这些交换机上执行。对与其中一个路由器相连的所有子网分 布交换机实施圭寸阻 TCP端口 135的操作，这可以获得圭寸阻流 量传输到路由器的预期效果，从而让CPU的使用率可以回落到正常水平。第二层交换机本身不会出现 CPU使用率增加的