使用linux工具诊断网络问题.pdfVIP

使用 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 把结果转储到中央服务器。分析这些日志后发现: 通过