使用Linux工具诊断网络问题.docVIP

使用Linux工具诊断网络问题 使用Linux工具诊断网络问题 　　如果结合使用Linux发行版Fedora Core和开放源代码软件包 libpcap、tcpdump、iptraf以及多路由器流量图示器（MRTG），就可以为查明网络问题产生的根源提供有价值的信息。 　　 　　连接速度慢 　　 　　在第一个例子中，一个小型网络使用384Kbps速率的ISDN连接至因特网，其问题在为网络排除故障时，不管面临哪种情形，把嗅探器（sniffer）放在合适位置，深入了解网络拓扑结构至关重要。我对该网络并不熟悉，于是与网络管理员一起进行了排查。网络很简单：通过网络地址转换（NAT）协议转换成单一公共IP地址的专用子网，由两只集线器和一只交换机（几台本地服务器与交换机相连）负责分布，一条线路从该交换机连接到因特网，如图1所示。轻则速度缓慢，重则不稳定。局域网性能良好，只是因特网流量受到了影响。 　　 　　 因为这只速率100Mbps的交换机没有端口镜像（port 引起使用量增加，那么也许没有必要花这笔费用。 　　我的任务就是，确定带宽使用量的增加是由于工作需要、拒绝服务攻击还是其他什么因素。该网络类似第一个例子，但交换机能够对连接到出站路由器的端口进行镜像处理。局域网管理员为出站路由器设置了端口镜像功能，以便把复制的所有流量引导至我接入嗅探器的那只端口上。 　　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查询机制，以监控每个路由器的