使用Linux工具诊断网络问题

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

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

3、端口镜像 不会显示物理层错误，但我还是通常偏爱端口镜像功能。我把 Linux 嗅探器接到先前插入的集线器，继续进行探 测:只要使用基本的 tcpdump -i -n 命令。因为我希望问题属于 某一种类型的数据包，与数据包里面实际所含内容没有关 系。我猜对了，因为记录的入站数据包几乎全都是来自不同 IP 地址的因特网控制消息协议（ ICMP ）回应请求。打电话 给因特网服务提供商（ISP）要求封阻入站ICMP回应请求后， 问题马上得到了解决。Napster 耗用带宽第二个例子与因特网带宽使用量增加有关，但还不至于 发展到导致不稳定性的地步。当时因特网带宽的使用量接近 了需要带宽升级的地步。单单添

4、加带宽来解决这类问题似乎 是项合理的措施，但是如果与用户工作毫无关系的某个应用 引起使用量增加，那么也许没有必要花这笔费用。我的任务就是，确定带宽使用量的增加是由于工作需 要、拒绝服务攻击还是其他什么因素。该网络类似第一个例 子，但交换机能够对连接到出站路由器的端口进行镜像处 理。局域网管理员为出站路由器设置了端口镜像功能，以便 把复制的所有流量引导至我接入嗅探器的那只端口上。Tcpdump 会话本身不会获得任何明显的结果，于是我决 定试试趋势分析。我在网络边界开始了 iptraf 会话选择 端口分析是为了确定流量模式，结果发现传输到 TCP 端口 6699 的流量很大。在路由器端通过访问控制

5、列表（ ACL ）封 阻该端口，就可以让网络流量模式恢复正常。进一步研究后发现，使用这个端口的是当时属于第一个大规模的因特网对等音乐共享服务：Napster。由于Napster音乐共享不属于工作计划的一部分，所以就封阻了该端口， 这样就用不着掏大笔费用升级因特网带宽了。第三个例子围绕名为 Slammer 蠕虫的微软 SQL Server 2000 和微软桌面引擎 2000 漏洞，这个蠕虫从技术上来说又 叫 W32.SQLExp.Worm 。赛门铁克公司对这个漏洞有详细介 绍，不过当时我遇到这个问题时，显然不知道原因是什么。 症状类似第一个例子当中的 ICMP 拒绝服务攻击，因为因特 网连接速度

6、变慢了。 不过这个网络比较复杂 :局域网由几个子网组成，这些子网通过路由器互连起来，如图3 所示。幸好，使用 MRTG 可以定期收集到有关每个子网的流量 模式的基准统计信息，因而可以了解正常流量应当是什么样 的历史信息。我们立即发现，其中三个子网的入站流量（来 自子网本身）比正常情况大得多。直觉告诉我，问题就出现 在这些子网上。不过，因为受到影响的是因特网连接，所以 在网络边界进行探测再度成了合理的步骤。网络管理员在网络边界处安装了 Linux 嗅探器，与边界 相连的是 100Mbps 速率的边界网络交换机，该交换机通过 tcpdump 不断收集统计信息， 并且每隔 15 分钟，然后通过 cr

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

8、如果记有精确的网络记录， 就有可能把 IP 地址与交换机 端口关联起来、找到合适的端口，并且以逻辑或者物理方式 断开端口。但问题是没有这样的记录。幸好，网络管理员运行了网络管理软件包，可以查询子 网上的所有交换机，确定某个介质访问控制（ MAC ）地址在 何处连接。把 MAC 地址和 IP 地址关联起来，这就如同查询 核心路由器的地址解析协议表这么简单。端口确认后，被感染的机器处于断开状态，直到问题解 决后再让它们连接到网络上，因而恢复了网络运作。核心路由器被感染确认及解决第四个例子中的问题相当困难。问题不是在 于漏洞类型，也不在于生成流量的数量；实际上，流量不像 前几个例子那样让因特网带宽处

9、于满负荷状态。区别在于， 核心网络路由器的感染方式。网络拓扑结构类似第三个例子。问题不仅仅表现为因特 网连接速度缓慢，还表现为子网之间的连接速度也很慢，就 连以物理和逻辑方式与同一路由器相连接的那些子网也是 这样。与第三个例子一样， 也建立了 MRTG 查询机制， 以监 控每个路由器的子网流量以及核心路由器的 CPU 负载。查看 MRTG 的图示结果后即可看到正确的稳定流量和 CPU 使用率。 MRTG 的特点之一就是， 如果它无法查询具有 简单网络管理协议（ SNMP ）功能的设备，会在统计信息最 后取得的值上显示一条水平线，不管是什么值。这个例子也 是如此。 MRTG 服务器工作正常得到了

10、证实。大多数企业核心路由器具有类似 Linux 中 top 命令的功 能。这个命令实际上显示了 CPU 使用率最高的路由器进程。 我试图向其中一个路由器开启终端会话， 但没有成功。 幸好， 每个核心路由器都有调解解调器连接到路由器的通信端口， 所以使用 Windows 中的超级终端 （ HyperTerminal ）程序，就 能够拨号进入其中一个路由器的控制台会话。虽然连控制台连接的速度也很慢， 我还是得以查明 :路由 器的CPU使用率达到了峰值：100%。CPU使用率最高的进 程是路由进程本身。探测子网是理所当然的步骤。探测表明多个源 IP 地址和目的地 IP 地址集中于一个 TCP 目的地

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