使用Linux工具诊断网络问题

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

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

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

4、网带宽使用量增加有关，但还不至 于发展到导致 不稳定性的地步。当时因特网带宽的使用量 接近了需要带 宽 升级的地步。单单添加带宽来解决这类问 题似乎是项合 理 的措施，但是如果与用户工作毫无关系的 某个应用引起 使 用量增加，那么也许没有必要花这笔费用 我的任务 就 是，确定带宽使用量的增加是由于工作需 要、拒绝服务 攻 击还是其他什么因素。该网络类似第一个 例子，但交换 机 能够对连接到出站路由器的端口进行镜像 处理。局域网 管 理员为出站路由器设置了端口镜像功能， 以便把复制的 所 有流量引导至我接入嗅探器的那只端口上 Tcpdump 会话本身 不会 获得任何明显的结果，于是我 决定试试趋

5、势 分析。我在网络边界开始了 iptraf 会 话选 择端口分析是 为 了确定流量模式，结果发现传输到 TCP 端 口 6699 的流量很大。在路由器端通过访问 控制 列表 （ACL ）封阻该端口，就可以让网络流量模式恢复 正常 。 进一步研 究 后发现，使用这个端口的是当时属于第一个大 规模的因 特网对等音乐共享服务： Napster。 由于 Napster 音乐共享不属于工作计划的一部分，所以就 封阻 了 该端口， 这样就用不着掏大笔费用升级因特网带宽了。 第三个例 子 围绕名为 Slammer 蠕虫的微软 SQL Server 2000 和微软桌面引擎 2000 漏洞，这个蠕虫从技术上来

6、说 又 叫 W32.SQLExp.Worm 。 赛门铁克公司对这个漏洞有详细介 绍，不过当时 我 遇到这个问题时，显然不知道原因是什么。 症状类似第一 个 例子当中的 ICMP 拒绝服务攻击，因 为因 特 网连接速度变 慢 了。不过这个网络比较复杂 :局域网由几个 子网组成，这 些子网通过路由器互连起来，如图 3 所示。 幸好，使 用 MRTG 可以定期收集到有关每个子网的流 量模 式的基准 统 计信息，因而可以了解正常流量应当是什 么样 的历史信 息 。我们立即发现，其中三个子网的入站流 量 （来自子网 本 身）比正常情况大得多。直觉告诉我，问 题 就出现在这 些 子网上。不过，因为受到影响

7、的是因特网 连 接，所以在 网 络边界进行探测再度成了合理的步骤。 网络管理 员 在网络边界处安装了 Linux 嗅 探器，与边界 相连 的是 100Mbps 速 率的边界网络交换机，该交换机通过 tcpdump 不 断收集统计信息，并且每隔 15 分钟，然后通过 cron 任务和 FTP 把结 果转储到中央服务器。分析这些日志 后发现 :通过三个内部 IP 地址的流量占了流量的大部分。 我在嗅探 器上运行了 iptraf 会话，因为局域网 管理 员以 前也 加载了这 个软件包。尽管我期望看到针对单个 TCP 端 口出 现多次访 问 （这是拒绝服务攻击的常见特征 ），但实际 情况 并非如此 。

8、然而，底部的 iptraf 容 器却在迅速滚屏显示 发往 某个UDP端口： 1434的用户数据报协议（UDP）数据 包。 把三个核 心局域网路由器上的这个端口封阻后，拒绝 服务 攻击就不 复存在了。不过，含有受感染机器的三个子 网的性能仍相 当 低，这是由于这些被感染机器带来了很大 的网络流量。 如果记有 精 确的网络记录，就有可能把 IP 地址 与交换 机端口关联起 来 、找到合适的端口，并且以逻辑或者物理 方式断开端口 。 但问题是没有这样的记录。 幸好，网 络 管 理员运行了网络管理软件包，可以查询 子网上的所有 交 换机，确定某个介质访问控制（ MAC ）地 址在何处连接 。把 MAC

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

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

11、有调解解调器连接到路由器的通信 端口，所以 使用 Windows 中的超级终端( HyperTerminal ) 程序，就能 够拨号进入其中一个路由器的控制台会话。虽然连控 制台连接的速度也很慢，我还是得以查明 :路 由器的 CPU 使 用率达到了峰值： 100%。 CPU 使用率最高 的进程是路由 进 程本身。探测子网是理所当然的步骤。探测表明 多个 源 IP 地址和目的地 IP 地址集中于一个 TCP 目的地端 口： 135。 这时，全凭经验的 我信心十足地建 议：网络管理 员应 当利用 ACL 封阻每个路由器的 TCP 端口 135。我以为，我们 可以以后处理停止正常 工作的微软应用 软

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