使用Linux工具诊断网络问题

如果结合使用Linux发行版Fedora Core和开放源代码软件包 libpcap、tcpdump、iptraf以及多路由器流量图示器（MRTG），就可以为查明网络问题产生的根源提供有价值的信息。

连接速度慢

在第一个例子中，一个小型网络使用384Kbps速率的ISDN连接至因特网，其问题在为网络排除故障时，不管面临哪种情形，把嗅探器（sniffer）放在合适位置，深入了解网络拓扑结构至关重要。我对该网络并不熟悉，于是与网络管理员一起进行了排查。网络很简单：通过网络地址转换（NAT）协议转换成单一公共IP地址的专用子网，由两只集线器和一只交换机（几台本地服务器与交换机相连）负责分布，一条线路从该交换机连接到因特网，如图1所示。轻则速度缓慢，重则不稳定。局域网性能良好，只是因特网流量受到了影响。

因为这只速率100Mbps的交换机没有端口镜像（port mirroring）这项功能，我从自己的网络工具包中取出了一只小型集线器，把它插入在100Mbps交换机和ISDN路由器之间，如图2所示。没错，这改变了原有的网络拓扑结构，但因为没有端口镜像功能――端口镜像功能可以把一个端口上经过的所有流量复制到另一个端口上，所以插入集线器是最好的选择办法了。这种办法有着诸多优点，虽然端口镜像不会显示物理层错误，但我还是通常偏爱端口镜像功能。

我把Linux嗅探器接到先前插入的集线器，继续进行探测:只要使用基本的tcpdump -i -n命令。因为我希望问题属于某一种类型的数据包，与数据包里面实际所含内容没有关系。我猜对了，因为记录的入站数据包几乎全都是来自不同IP地址的因特网控制消息协议（ICMP）回应请求。打电话给因特网服务提供商（ISP）要求封阻入站ICMP回应请求后，问题马上得到了解决。

Napster耗用带宽

第二个例子与因特网带宽使用量增加有关，但还不至于发展到导致不稳定性的地步。当时因特网带宽的使用量接近了需要带宽升级的地步。单单添加带宽来解决这类问题似乎是项合理的措施，但是如果与用户工作毫无关系的某个应用引起使用量增加，那么也许没有必要花这笔费用。

我的任务就是，确定带宽使用量的增加是由于工作需要、拒绝服务攻击还是其他什么因素。该网络类似第一个例子，但交换机能够对连接到出站路由器的端口进行镜像处理。局域网管理员为出站路由器设置了端口镜像功能，以便把复制的所有流量引导至我接入嗅探器的那只端口上。

Tcpdump会话本身不会获得任何明显的结果，于是我决定试试趋势分析。我在网络边界开始了iptraf会话――选择端口分析是为了确定流量模式，结果发现传输到TCP端口6699的流量很大。在路由器端通过访问控制列表（ACL）封阻该端口，就可以让网络流量模式恢复正常。

进一步研究后发现，使用这个端口的是当时属于第一个大规模的因特网对等音乐共享服务：Napster。由于Napster音乐共享不属于工作计划的一部分，所以就封阻了该端口，这样就用不着掏大笔费用升级因特网带宽了。

第三个例子围绕名为Slammer蠕虫的微软SQL Server 2000和微软桌面引擎2000漏洞，这个蠕虫从技术上来说又叫W32.SQLExp.Worm。赛门铁克公司对这个漏洞有详细介绍，不过当时我遇到这个问题时，显然不知道原因是什么。症状类似第一个例子当中的ICMP拒绝服务攻击，因为因特网连接速度变慢了。不过这个网络比较复杂:局域网由几个子网组成，这些子网通过路由器互连起来，如图3所示。

幸好，使用MRTG可以定期收集到有关每个子网的流量模式的基准统计信息，因而可以了解正常流量应当是什么样的历史信息。我们立即发现，其中三个子网的入站流量（来自子网本身）比正常情况大得多。直觉告诉我，问题就出现在这些子网上。不过，因为受到影响的是因特网连接，所以在网络边界进行探测再度成了合理的步骤。

网络管理员在网络边界处安装了Linux嗅探器，与边界相连的是100Mbps速率的边界网络交换机，该交换机通过tcpdump不断收集统计信息，并且每隔15分钟，然后通过cron任务和FTP把结果转储到中央服务器。分析这些日志后发现:通过三个内部IP地址的流量占了流量的大部分。

我在嗅探器上运行了iptraf会话，因为局域网管理员以前也加载了这个软件包。尽管我期望看到针对单个TCP端口出现多次访问（这是拒绝服务攻击的常见特征），但实际情况并非如此。然而，底部的iptraf容器却在迅速滚屏显示发往某个UDP端口：1434的用户数据报协议（UDP）数据包。把三个核心局域网路由器上的这个端口封阻后，拒绝服务攻击就不复存在了。不过，含有受感染机器的三个子网的性能仍相当低，这是由于这些被感染机器带来了很大的网络流量。

如果记有精确的网络记录，就有可能把IP地址与交换机端口关联起来、找到合适的端口，并且以逻辑或者物理方式断开端口。但问题是没有这样的记录。

幸好，网络管理员运行了网络管理软件包，可以查询子网上的所有交换机，确定某个介质访问控制（MAC）地址在何处连接。把MAC地址和IP地址关联起来，这就如同查询核心路由器的地址解析协议表这么简单。

端口确认后，被感染的机器处于断开状态，直到问题解决后再让它们连接到网络上，因而恢复了网络运作。

核心路由器被感染

确认及解决第四个例子中的问题相当困难。问题不是在于漏洞类型，也不在于生成流量的数量；实际上，流量不像前几个例子那样让因特网带宽处于满负荷状态。区别在于，核心网络路由器的感染方式。

网络拓扑结构类似第三个例子。问题不仅仅表现为因特网连接速度缓慢，还表现为子网之间的连接速度也很慢，就连以物理和逻辑方式与同一路由器相连接的那些子网也是这样。与第三个例子一样，也建立了MRTG查询机制，以监控每个路由器的子网流量以及核心路由器的CPU负载。

查看MRTG的图示结果后即可看到正确的稳定流量和CPU使用率。MRTG的特点之一就是，如果它无法查询具有简单网络管理协议（SNMP）功能的设备，会在统计信息最后取得的值上显示一条水平线，不管是什么值。这个例子也是如此。MRTG服务器工作正常得到了证实。

大多数企业核心路由器具有类似Linux中top命令的功能。这个命令实际上显示了CPU使用率最高的路由器进程。我试图向其中一个路由器开启终端会话，但没有成功。幸好，每个核心路由器都有调解解调器连接到路由器的通信端口，所以使用Windows中的超级终端（HyperTerminal）程序，就能够拨号进入其中一个路由器的控制台会话。

虽然连控制台连接的速度也很慢，我还是得以查明:路由器的CPU使用率达到了峰值：100%。CPU使用率最高的进程是路由进程本身。探测子网是理所当然的步骤。

探测表明多个源IP地址和目的地IP地址集中于一个TCP目的地端口：135。这时，全凭经验的我信心十足地建议：网络管理员应当利用ACL封阻每个路由器的TCP端口135。我以为，我们可以以后处理停止正常工作的微软应用软件，因为恢复网络功能极为重要。让我感到郁闷的是，封阻该端口后并没有降低路由器CPU的使用率。

路由器是第三层交换设备，正因为如此，它们通常被称为第三层交换机。这意味着，路由器根据第三层（这里是IP）地址来确定数据包的目的地。我查明：ACL之所以不起作用，原因就是路由器在实施ACL规则之前，仍得处理数据包的第三层信息。正是这个原因导致路由器CPU的使用率达到高峰以及随后的网络拥塞。

下面介绍为什么有必要深入了解开放系统互连（OSI）参考模型。每个子网分布交换机都是能够识别第三层和第四层的企业交换机。实际上这意味着，类似ACL的命令可以在这些交换机上执行。对与其中一个路由器相连的所有子网分布交换机实施封阻TCP端口135的操作，这可以获得封阻流量传输到路由器的预期效果，从而让CPU的使用率可以回落到正常水平。

第二层交换机本身不会出现CPU使用率增加的问题。这是由这类交换机具有的特性所决定的。虽然路由器必须检查每个IP数据包的源IP地址和目的地IP地址、还要对照路由表，但在MAC层上进行交换的交换机不进行这种操作。

正是被欺骗的源IP地址和目的地IP地址几乎无穷尽的组合导致路由器不堪重负。由于源地址被欺骗，找出被感染机器就很困难，而且很费时间。但恢复网络正常运作的主要目的还是实现了。