网络诊断工具使用Linu工具诊断网络问题

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

2、）负责分布，一条线路从该交换机连接到因特网，如图1 所示。轻则速度缓慢，重则不稳定。局域网性能良好，只是因特网流量受到了影响。因为这只速率100Mbps的交换机没有端口镜像（port mirrori ng）这项功能，我从自己的网络工具包中取出了一只小型集线器，把它插入在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漏洞， 这个蠕虫从技术上来说又叫W3SQLExp.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、这样。 与第三个例子一样，也建立了 MRTG询机制，以监控每个路由器的子网流量以及核心路由器的CPU负载。查看MRT啲图示结果后即可看到正确的稳定流量和CPU使用率。MRTG勺特点之一就是，如果它无法查询具有简单网络管理协议（SNM）P 功能的设备，会在统计信息最后取得的值上显示一条水平线，不管是什么值。这个例子也是如此。MRTG艮务器工作正常得到了证实。大多数企业核心路由器具有类似 Linux 中 top 命令的功能。这个命令实际上显示了 CPU 使用率最高的路由器进程。我试图向其中一个路由器开启终端会话，但没有成功。幸好，每 个核心路由器都有调解解调器连接到路由器的通信端口，所以使用Win

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

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