案例追踪 三起怪异的网络故障

　　案例1：前网管的恶意报复

　　故障表现

　　前不久，网管辞职朋友接手了公司的网络管理。这是一家广告公司，网络规模不大，计算机数量大概有40台。公司有4个部门，各部门通过一台小型交换机，连接到核心交换机。核心交换机的Uplink口连接TP-LINK宽带路由器，路由器通过ADSL连接到Internet，网络拓扑见图1。朋友上任不到一天就遇到了网络故障，具体表现为：企业外网基本上两小时自动掉一次线，然后过一分钟又自动连接上。这期间虽然耽误时间只有一分钟，但由于公司很多广告设计都是多人在线协作完成。另外，公司的视频点播系统对网络的连通性要求很高。因此，这一分钟的掉线对公司的影响还是比较大的。

　　图1

　　故障分析

　　朋友检查了节点间的线缆连接以及员工们的计算机的系统，排除了硬件连接和病毒因素，但故障依旧，找笔者帮忙。就笔者日常维护网络经验来看，断网主要由两方面引起：本地链路不稳及感染蠕虫所致。联系电信部门对ADSL链路进行检查，排除了链路故障，于是将重点放到蠕虫病毒上。大家知道，当网络中蠕虫数据包过多会造成宽带路由器的“假死”，从而逻辑关闭对应端口，造成断网。而逻辑关闭的接口随后会自动打开，这正好和故障症状相吻合。

　　根据以上的分析，笔者把重点放在具有ARP欺骗特性的病毒上。之后，笔者和朋友详细检查了所有员工的计算机，没有发现任何问题。同时检测发现，当出现断线时ARP缓存表里的网关MAC地址与正常上网时是一致，这说明断网并不是因为ARP欺骗引起的。

　　排查否定了病毒和链路因素，那么还有什么可能造成如此蹊跷的网络故障呢?为了更好地定位故障笔者决定使用分割法进行分析，也就是说将网络各个区域隔离开来检查。首先，笔者关闭了大多数员工计算机，只让一台笔记本上网，故障依旧，看来问题不是出现在计算机上。难道是交换机或者路由器出现了问题?

　　接下来把笔记本直接连接路由器上网，结果还是两小时自动断一次，之后又恢复连接。因此，基本可以断定故障在路由器或线路本身。接着，用笔记本直接连接ADSL猫，在系统中手工建立拨号连接后拨号上网，自动断线问题没有再出现。这说明线路是好的，ADSL猫也没有任何问题，肯定是宽带路由器在作祟。

　　故障解决

　　于是笔者登录路由器进入管理界面，一一比对各个参数设置信息，结果发现在“网络参数→WAN口设置”处的拨号设置被设置为“按需连接，在有访问时自动连接，自动断线等待时间15分钟”见图2。这就是说当有人要访问外部internet时宽带路由器才会拨号上网，而且当网络需求在15分钟之内没有时就会自动断线。笔者将其修改为“自动连接，在开机和断线后自动连接”后，经过一段时间的测试，企业内网再也没有出现怪异的断网现象。

　　图2

　　笔者事后了解到，原来是前管理员为泄愤修改了宽带路由器的拨号连接设置才造成了如此蹊跷的网络故障。笔者在本次排故过程中走了不少弯路，没有想到人才是网络安全最重要的因素。不过，文中涉及的层层推理分析解决网络故障的方法希望对大家有所帮助。

　　案例2：系统盲目优化的后遗症

　　故障重现

　　单位局域网规模相对较大，为了方便管理工作站，特意搭建了DHCP服务器，利用DHCP服务为每一台工作站自动分配IP地址。很长一段时间里，局域网中所有工作站都联网正常，速度也比较理想。最近的某天早晨，笔者一上班总务室的小张打电话说他们办公室的6台电脑都不能连接上网了，系统任务栏处的“本地连接”图标总不断提示本地连接受到了限制。

　　这类故障现象，笔者见得太多了，当即通过电话进行了远程指导：先将网络线缆拔出来，然后重新插一下，实在不行的话，可以重新启动一下计算机系统。不一会，小张又打来电话说还是不行!电话刚撂下档案室小吴打来电话求助，故障和总务室的类似。没办法，亲自跑一趟。

　　故障分析

　　查看总务室小李的电脑故障确实如他所述，笔者首先考虑会不会是本地工作站从DHCP服务器那里没有获取到合法的IP地址，从而导致该工作站出现“本地连接”受到限制的提示呢?随机在打开命令行工具执行“ipconfig /all”命令，该工作站获取的IP地址竟然为“169.254.11.156”!很明显该IP地址并不是从DHCP服务器那里得来的，而是Windows系统自动分配的，这么说该工作站与DHCP服务器失去了联系。

　　会不会是DHCP服务器出现了问题呢?询问得知，局域网中的其他工作站都能上网，这说明DHCP服务器自身运行是正常的。有没有可能是本地工作站的网络连接线缆出现了短路或断裂现象，从而导致本地工作站与局域网失去了联系呢?于是特地找来了专门的网络测试仪，对本地工作站的线缆连通性进行了现场测试，从测试结果来看，该网络线缆完全正常。笔者又把自己的笔记本电脑联入网络，同时设置IP动态获取，结果笔记本电脑能够很快速地获得IP上网一切正常。很显然，这条网络线缆以及其所连的交换机端口都没有问题。

　　既然网络线缆没有问题，交换机连接端口也没有问题，DHCP服务器也能正常工作，看来问题肯定出在本地工作站系统身上。对客户端进行杀毒和文件修复操作，经测试故障依旧。 在确认本地工作站自身运行正常的前提下，笔者不得不再次将怀疑目光转向DHCP服务器。考虑到DHCP服务器能够为局域网中的其他工作站正常分配地址，惟独不能给个别工作站分配地址，会不会是这些工作站先前从DHCP服务器获得的IP地址过了租约期呢?

　　于是，笔者以超级管理员权限登录到DHCP服务器，打开DHCP控制台窗口，进入该服务器“目标作用域”属性对话框，从中找到“地址租约”选项，并将那些租约到期的工作站全部解除锁定，最后又重新启动了一下DHCP服务器。接着笔者再次在小李的电脑上依次执行“ipconfig /release”，“ipconfig /renew”释放并重新获得IP地址。接着执行“ipconfig /all”发现IP地址还是不正确，工作站仍然不能访问网络。

　　这让笔者纳闷了，于是重新执行上面的命令，系统提示RPC服务无法调用之类的错误，难道客户端的RPC服务被禁用?大家知道DHCP Client服务依存于RPC，如果其被禁用则DHCP Client服务不能启动，就无法从DHCP服务器获得IP。于是打开客户端主机的“服务管理器”，发现“Remote Procedure Call (RPC)”服务果然被禁用处于停止状态见图3，原因终于找到了。

　　图3

　　故障解决

　　马上重启Remote Procedure Call (RPC)服务，然后启动DHCP Client服务，接着执行上面获取IP的操作，IP成功获得，联网测试成功。其他的主机也如法炮制，这起电脑故障才算最终解决。但笔者不禁要问：为什么这两个办公室的电脑会出现类似的故障呢?询问小李后得知，原来他在前一天从网上下载了一款系统优化工具，用其对自己的系统进行了优化，优化过系统后系统快了不少。于是他把该软件提供给了办公室的同事，当然也推荐给了隔壁的档案室，所以当第二天大家打开电脑时不约而同地出现了如上的症状。

　　案例3：病毒实施的ARP攻击

　　故障现象

　　笔者本地某中学的一栋教学楼内的网络突然出现故障，网络时断时续，主机间互访经常超时并且丢包现象非常严重，影响了正常的教学工作。

　　故障分析

　　该校的网络中天科技承建的，笔者作为客服人员立即着手进行调查，据老师们反映：联网时，有时候网页打开速度非常缓慢，有时丝毫没有动静，显示无法打开网页。不过，在非上班时间，如中午和晚上等休息时间，网络一切正常。根据这一情况判断，网络硬件故障的可能性微乎其微，经过检查没有发现异常情况，排除了物理上的错误。看来是软件上的问题，脑海中的第一反应就是局域网中比较流行的ARP攻击。

　　大家知道，ARP协议的中文名为“地址解析协议”，用于将网络中的IP地址解析为硬件地址(MAC地址)，以保证通信的顺利进行。当计算机接收到ARP应答数据包的时候，就会对本地的ARP缓存进行更新，将应答中的IP和MAC地址存储在ARP缓存中。所以在网络中，如果有人发送一个自己伪造的ARP应答，网络可能就会出现问题，这就是ARP欺骗，其常见的特征就是主机频繁掉线。

　　这与该网络症状非常相似，但是ARP攻击需要找到它的源头，一般的方法很难查找，需要在交换机上进行抓包分析，于是找到了Iris Network Traffic Analyzer(以下简称Iris)。这是一款网络流量分 析监测工具，可以帮助系统管理员轻易地捕获和查看用户的使用情况，同时检测进入和发出的信息流，自动进行存储和统计。这款软件的图标很像一只眼睛，看来 “火眼金睛”是找到了，现在就花工夫怎么用好它了!

　　由于该教学楼的交换机是一台非网管型交换机，只好拿着笔记本电脑在网络设备房“蹲点”。把笔记本电脑连接在交换机端口上，打开Iris，界面显示。

　　图4

　　依旧是我们熟悉的典型Windows软件风格，单击开始捕获按钮，Iris开始工作，对数据包实施抓捕。Iris对数据包抓捕的同时可以对其进行分析， 点击某一时刻的数据包在快速分析窗口中查看解析内容。在Statistics(统计表)窗口中，我们可以浏览实时数据统计图，对Protocol (网络协议)、Top Hosts(最高流量主机)、Size Distribution(数据包大小分类)和Bandwidth(带宽)进行直接查看。

　　不一会，“凶手”出现了!Iris捕获窗口出现了大量的ARP数据包，Protocol(网络协议)图表显示出来的ARP数据包在不断增长!整个网络的流量一下加大了好几倍!

　　图5

　　为了分析方便，用Iris的Filters(过滤)功能，将ARP和Reverse ARP两种类型的数据过滤出来。终于，找到了ARP欺骗的真凶了，在捕获窗口中可以看到，所有的ARP数据包源都是来自MAC地址为00:0A:E6:98:84:87的电脑，终于掌握罪证了!也就是说，找到这个 MAC地址的电脑就可以铲除祸根了!

　　图6

　　故障解决

　　接下来的工作就简单了，拿出平时记录好的“MAC-IP-计算机名”对应表，找到真凶电脑，对其进行断网、系统重装、查杀病毒等操作，确认安全后，再连接上网。网络又恢复了往日的宁静，学校的正常教学秩序得到了保证。

　　总结：本文列举的三起比较怪异的网络故障，追踪到最后都被确认是人为造成的。不管是恶意的还是无意，都毫无例外地影响了网络的正常运行。因此，网络管理除了技术之外，制度管理必须要跟上，只有双管齐下，才能在最大程度上避免因网络故障对企业造成不必要的损失。另外，管理员们在解决网络故障时要避免惯性思维，突破心理定势，少走弯路。