案例1：前網管的惡意報復

　　故障表現

　　前不久，網管辭職朋友接手了公司的網絡管理。這是一家廣告公司，網絡規模不大，計算機數量大概有40臺。公司有4個部門，各部門通過一臺小型交換機，連接到核心交換機。核心交換機的Uplink口連接TP-LINK寬帶路由器，路由器通過ADSL連接到Internet，網絡拓撲見圖1。朋友上任不到一天就遇到了網絡故障，具體表現為：企業外網基本上兩小時自動掉一次線，然后過一分鐘又自動連接上。這期間雖然耽誤時間只有一分鐘，但由于公司很多廣告設計都是多人在線協作完成。另外，公司的視頻點播系統對網絡的連通性要求很高。因此，這一分鐘的掉線對公司的影響還是比較大的。

圖1

　　故障分析

　　朋友檢查了節點間的線纜連接以及員工們的計算機的系統，排除了硬件連接和病毒因素，但故障依舊，找筆者幫忙。就筆者日常維護網絡經驗來看，斷網主要由兩方面引起：本地鏈路不穩及感染蠕蟲所致。聯系電信部門對ADSL鏈路進行檢查，排除了鏈路故障，于是將重點放到蠕蟲病毒上。大家知道，當網絡中蠕蟲數據包過多會造成寬帶路由器的“假死”，從而邏輯關閉對應端口，造成斷網。而邏輯關閉的接口隨后會自動打開，這正好和故障癥狀相吻合。

　　根據以上的分析，筆者把重點放在具有ARP欺騙特性的病毒上。之后，筆者和朋友詳細檢查了所有員工的計算機，沒有發現任何問題。同時檢測發現，當出現斷線時ARP緩存表里的網關MAC地址與正常上網時是一致，這說明斷網并不是因為ARP欺騙引起的。

　　排查否定了病毒和鏈路因素，那么還有什么可能造成如此蹊蹺的網絡故障呢?為了更好地定位故障筆者決定使用分割法進行分析，也就是說將網絡各個區域隔離開來檢查。首先，筆者關閉了大多數員工計算機，只讓一臺筆記本上網，故障依舊，看來問題不是出現在計算機上。難道是交換機或者路由器出現了問題?

　　接下來把筆記本直接連接路由器上網，結果還是兩小時自動斷一次，之后又恢復連接。因此，基本可以斷定故障在路由器或線路本身。接著，用筆記本直接連接ADSL貓，在系統中手工建立撥號連接后撥號上網，自動斷線問題沒有再出現。這說明線路是好的，ADSL貓也沒有任何問題，肯定是寬帶路由器在作祟。

　　故障解決

　　于是筆者登錄路由器進入管理界面，一一比對各個參數設置信息，結果發現在“網絡參數→WAN口設置”處的撥號設置被設置為“按需連接，在有訪問時自動連接，自動斷線等待時間15分鐘”見圖2。這就是說當有人要訪問外部internet時寬帶路由器才會撥號上網，而且當網絡需求在15分鐘之內沒有時就會自動斷線。筆者將其修改為“自動連接，在開機和斷線后自動連接”后，經過一段時間的測試，企業內網再也沒有出現怪異的斷網現象。

圖2

　　筆者事后了解到，原來是前管理員為泄憤修改了寬帶路由器的撥號連接設置才造成了如此蹊蹺的網絡故障。筆者在本次排故過程中走了不少彎路，沒有想到人才是網絡安全最重要的因素。不過，文中涉及的層層推理分析解決網絡故障的方法希望對大家有所幫助。

#p#副標題#e#

　　案例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

#p#副標題#e#

　　故障解決

 

　　馬上重啟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

#p#副標題#e#

　　依舊是我們熟悉的典型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-計算機名”對應表，找到真兇電腦，對其進行斷網、系統重裝、查殺病毒等操作，確認安全后，再連接上網。網絡又恢復了往日的寧靜，學校的正常教學秩序得到了保證。

　　總結：本文列舉的三起比較怪異的網絡故障，追蹤到最后都被確認是人為造成的。不管是惡意的還是無意，都毫無例外地影響了網絡的正常運行。因此，網絡管理除了技術之外，制度管理必須要跟上，只有雙管齊下，才能在最大程度上避免因網絡故障對企業造成不必要的損失。另外，管理員們在解決網絡故障時要避免慣性思維，突破心理定勢，少走彎路。