關(guān)于局域網(wǎng)癱瘓的解決方法有哪些

　　最近有網(wǎng)友想了解下局域網(wǎng)癱瘓的解決方法,所以學習啦小編就整理了相關(guān)資料分享給大家,具體內(nèi)容如下.希望大家參考參考!!!

　　局域網(wǎng)癱瘓的解決方法(學習啦小編推薦一個非常不錯的例子給大家參考參考)

　　學習啦小編接到網(wǎng)友求助，最近進行了一次網(wǎng)絡(luò)“出診”。這是一個由傀儡主機的DDos攻擊引發(fā)的網(wǎng)絡(luò)故障，案例比較典型，排錯過程也頗曲折。所以小編我就就還原其過程，與大家分享。

　　1.網(wǎng)絡(luò)環(huán)境

　　這個客戶是一家化工企業(yè)，網(wǎng)絡(luò)規(guī)模不大。十多臺交換機組成的局域網(wǎng)，節(jié)點大約150個左右。沒有劃分VLAN，—部分主機運行IPX協(xié)議，另一部分運行TCP/IP協(xié)議。其中只有少數(shù)主機可以訪問Internet，接入模式為ADSL路由器直接連接網(wǎng)絡(luò)中的一臺交換機。ADSL路由器中啟用了其自帶防火墻功能，所有可以上網(wǎng)的主機安裝了防病毒軟件。

　　2.故障描述

　　最近的某一天，整個網(wǎng)絡(luò)突然癱瘓?？梢钥吹剿薪粨Q機端口指示燈急速閃爍，測試得知網(wǎng)絡(luò)中任意兩臺主機之間不能相互ping通，所有網(wǎng)絡(luò)應(yīng)用均不能正常進行。在拔掉部分網(wǎng)線(交換機之間的級連線)后，癥狀有所減緩，最后恢復正常。將拔掉的網(wǎng)線逐一插回原位，故障現(xiàn)象未重新出現(xiàn)。此后這種現(xiàn)象不定時、無規(guī)律地出現(xiàn)。

　　3.故障分析

　　基于故障發(fā)生時交換機端口指示燈急速閃爍、網(wǎng)絡(luò)中任意兩臺主機之間相互不能ping通這一現(xiàn)象，初步斷定此時網(wǎng)絡(luò)中充斥了大量的廣播包，耗盡了網(wǎng)絡(luò)資源。那么這些突然出現(xiàn)的巨量廣播包是哪里來的呢?為查找廣播源，在故障出現(xiàn)時，使用Sninffer軟件捕捉數(shù)據(jù)包。結(jié)果發(fā)現(xiàn)，網(wǎng)絡(luò)中并沒有出現(xiàn)原來估計的廣播包，卻有大量的不正常單目IP數(shù)據(jù)包。

　　4.排除故障

　　通過分析發(fā)現(xiàn)，這些數(shù)據(jù)包是主機172.*.*.1l發(fā)送給主機219.*.*.88的，發(fā)送速度不小于每秒l萬5千個。詢問管理員得知，172.*.*.1l是內(nèi)網(wǎng)的一臺可以訪問Internet的主機。這明顯是不正常的，將該可疑主機斷開后，問題解決。

　　5.深入分析

　　網(wǎng)絡(luò)故障雖然排錯，但學習啦小編感覺一切并沒有這么簡單。因為按常理，發(fā)送給主機219.*.*.88的數(shù)據(jù)包不是廣播包，不應(yīng)該被發(fā)送到運行Sniffer主機所在的交換機端口。很明顯，這些數(shù)據(jù)包在網(wǎng)絡(luò)中以廣播的形式被發(fā)送了。如此數(shù)量的廣播包充斥網(wǎng)絡(luò)，正是造成網(wǎng)絡(luò)癱瘓的罪魁禍首。

　　(1).局域網(wǎng)主機成了傀儡

　　為搞清故障原因，在可疑主機上安裝Sniffer，分析網(wǎng)絡(luò)行為。通過抓包分析發(fā)現(xiàn)，一旦連接Internet，該主機主動連接到外網(wǎng)中一FTP服務(wù)器，并下載文本文件ddos.txt。那么，ddos.txt文件內(nèi)容中有什么呢?原來是一個IP地址和8O端口。然后，對數(shù)據(jù)包進一步分析發(fā)現(xiàn)所有數(shù)據(jù)包的目標主機正好是ddos.txt中指定的IP地址。這些無意義的數(shù)據(jù)包之所以使用8O端口，是為了突破防火墻的限制。原來，這臺主機“有幸”成了一次分布式拒絕服務(wù)攻擊(DDoS)的傀儡機。每次連接E互連網(wǎng)，自動到一個FTP服務(wù)器下載文件ddos.txt，如果該文件為空，則繼續(xù)以一定時間間隔下載文件，直到獲得的文件中有目標主機的IP地址和端口后，即開始向目標主機展開DoS攻擊。這正是網(wǎng)絡(luò)故障現(xiàn)象不定時、無規(guī)律地出現(xiàn)的原因。

　　(2).ADSL路由器被“淹沒”

　　另一個問題是，這些攻擊包應(yīng)該是從傀儡機發(fā)送到ADSL路由器，然后到Internet中目標主機的，并不是通常所說的廣播包，為什么交換機以廣播的形式發(fā)送這些廣播包呢?分析可能原因只有一個：此時交換機的地址轉(zhuǎn)發(fā)表(CAM)中沒有ADSL路由器內(nèi)網(wǎng)接口的物理地址，引起交換機將單目包廣播到所有交換機端口。

　　開始時，交換機地址轉(zhuǎn)發(fā)表中包含ADSL路由器的物理地址。那么，傀儡機開始攻擊后，網(wǎng)絡(luò)中形成一個穩(wěn)定的攻擊數(shù)據(jù)流：傀儡機→若干交換機→ADSL路由器→被攻擊的目標主機。此時對內(nèi)網(wǎng)的影響僅僅是某些交換機的端口和ADSL路由器，ADSL路由器因為忙于處理大量的攻擊包而被“淹沒”，會導致內(nèi)網(wǎng)中主機訪問互連網(wǎng)出現(xiàn)問題。下點!應(yīng)該懂了吧!

　　(3).交互導致的廣播風暴

　　什么原因?qū)е陆粨Q機的地址轉(zhuǎn)發(fā)表丟棄了ADSL路由器內(nèi)網(wǎng)接口的物理地址昵?有兩種情況：一是缺省情況下，5分鐘內(nèi)，如果交換機沒有接到某個設(shè)備發(fā)送的數(shù)據(jù)幀，則認為該設(shè)備已經(jīng)宕機，為節(jié)省資源，將從CAM表中刪除該地址。二是當STP協(xié)議探測到網(wǎng)絡(luò)拓撲有改變時，將清空所有未刷新的CAM表項。假定此時有人因為不能上網(wǎng)而重新啟動主機，或插撥網(wǎng)線，則會引起交換機端口狀態(tài)發(fā)生變化。此時，交換機認為網(wǎng)絡(luò)拓撲發(fā)生了變化，它的下—個動作是通知所有交換機，15秒內(nèi)清除未被刷新的地址轉(zhuǎn)發(fā)表表項。

　　這里的“未被刷新”是指，交換機沒有收到以該物理地址為源地址的數(shù)據(jù)幀，也就是說，該設(shè)備沒有發(fā)送數(shù)據(jù)幀經(jīng)過交換機到其他設(shè)備，那么該設(shè)備的物理地址在交換機的地址轉(zhuǎn)發(fā)表中將被清除。以后，所有以該設(shè)備物理地址為目的地址的數(shù)據(jù)幀，雖然不是廣播幀，也將被發(fā)送到交換機的所有端口，這就是平時所說的廣播風暴。

　　(4).故障形成過程

　　通過上面的分析，最后回到我們的例子理一理這次故障形成的過程。在傀儡機的攻擊行為開始后，小小的ADSL路由器每秒要接收、處理不少于l5o00個數(shù)據(jù)包，它縱然是有三頭六臂，也沒機會向交換機發(fā)送數(shù)據(jù)包了。也就是說，它現(xiàn)在是只有接受沒有發(fā)送，沒辦法刷新交換機cAM表中的相關(guān)表項。那么，快的話15秒后，慢的話5分鐘，交換機就會清除ADSL路由器的物理地址記錄。別忘了，此時攻擊數(shù)據(jù)流并沒有停止，而這些攻擊數(shù)據(jù)幀恰恰是以ADSL路由器物理地址為目的地址的，這樣，災(zāi)難發(fā)生了，所有數(shù)據(jù)幀被廣播到網(wǎng)絡(luò)中每臺交換機中的每—個端口。

　　6.解決方案

　　這此網(wǎng)絡(luò)故障從表面上看是由一臺傀儡主機引起的，具有一定的偶然性。但從根本上來說是必然，不合理的網(wǎng)絡(luò)結(jié)構(gòu)是造成這次故障的關(guān)鍵因素。學習啦小編給出的解決方案是：

　　(1).將充當傀儡機的電腦從網(wǎng)絡(luò)中斷開后，重新安裝系統(tǒng)，徹底杜絕隱患。

　　(2).加強本地網(wǎng)絡(luò)安全防范措施的同時，對原網(wǎng)絡(luò)結(jié)構(gòu)進行調(diào)整：據(jù)不同應(yīng)用分成幾個VLAN，將可以上網(wǎng)的機劃分到某個特定VLAN中，限定此類故障的影響范圍。

　　(3).將連接主機的端口配置為STP速端口，不參與STP協(xié)議，可以減少網(wǎng)絡(luò)中交換機不

　　必要的拓撲改變操作。

　　就這次網(wǎng)絡(luò)排錯學習啦小編的啟示是：網(wǎng)絡(luò)排錯類同于醫(yī)生治病，庸醫(yī)往往是“頭痛醫(yī)頭，腳痛醫(yī)教”不會從根上進行醫(yī)治，而高明的醫(yī)生卻往往是治本。網(wǎng)絡(luò)排錯何嘗不是呢?