網(wǎng)絡(luò)診斷工具使用Linu工具診斷網(wǎng)絡(luò)問題

1、如果結(jié)合使用 Linux 發(fā)行版 Fedora Core 和開放源代碼軟件包 libpcap 、tcpdump 、iptraf 以及多路由器流量圖示器（MRTG,就可以為查明網(wǎng)絡(luò)問題產(chǎn)生的根源提供有價值的信息。連接速度慢在第一個例子中，一個小型網(wǎng)絡(luò)使用 384Kbps速率的ISDN連接至因特網(wǎng)，其問題在為網(wǎng) 絡(luò)排除故障時，不管面臨哪種情形，把嗅探器（ sniffer ）放在合適位置，深入了解網(wǎng)絡(luò)拓?fù)?結(jié)構(gòu)至關(guān)重要。我對該網(wǎng)絡(luò)并不熟悉，于是與網(wǎng)絡(luò)管理員一起進(jìn)行了排查。網(wǎng)絡(luò)很簡單通過 網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT協(xié)議轉(zhuǎn)換成單一公共 IP地址的專用子網(wǎng)，由兩只集線器和一只交換機(jī) （幾臺本地服務(wù)器與交換機(jī)相連

2、）負(fù)責(zé)分布，一條線路從該交換機(jī)連接到因特網(wǎng)，如圖1 所示。輕則速度緩慢，重則不穩(wěn)定。局域網(wǎng)性能良好，只是因特網(wǎng)流量受到了影響。因為這只速率100Mbps的交換機(jī)沒有端口鏡像（port mirrori ng）這項功能，我從自己的網(wǎng)絡(luò)工具包中取出了一只小型集線器，把它插入在100Mbps交換機(jī)和ISDN路由器之間，如圖2所示。沒錯，這改變了原有的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，但因為沒有端口鏡像功能一一端口鏡像功 能可以把一個端口上經(jīng)過的所有流量復(fù)制到另一個端口上，所以插入集線器是最好的選擇辦 法了。這種辦法有著諸多優(yōu)點，雖然端口鏡像不會顯示物理層錯誤，但我還是通常偏愛端口 鏡像功能。我把 Linux 嗅探器接到先

3、前插入的集線器， 繼續(xù)進(jìn)行探測 : 只要使用基本的 tcpdump -i -n 命令。因為我希望問題屬于某一種類型的數(shù)據(jù)包，與數(shù)據(jù)包里面實際所含內(nèi)容沒有關(guān)系。我 猜對了，因為記錄的入站數(shù)據(jù)包幾乎全都是來自不同 IP 地址的因特網(wǎng)控制消息協(xié)議（ICMP）回應(yīng)請求。打電話給因特網(wǎng)服務(wù)提供商（ISP）要求封阻入站ICMP回應(yīng)請求后，問題馬上得到了解決。Napster 耗用帶寬第二個例子與因特網(wǎng)帶寬使用量增加有關(guān)，但還不至于發(fā)展到導(dǎo)致不穩(wěn)定性的地步。當(dāng) 時因特網(wǎng)帶寬的使用量接近了需要帶寬升級的地步。單單添加帶寬來解決這類問題似乎是項 合理的措施，但是如果與用戶工作毫無關(guān)系的某個應(yīng)用引起使用量增加，那么

4、也許沒有必要 花這筆費用。我的任務(wù)就是，確定帶寬使用量的增加是由于工作需要、拒絕服務(wù)攻擊還是其他什么因 素。該網(wǎng)絡(luò)類似第一個例子，但交換機(jī)能夠?qū)B接到出站路由器的端口進(jìn)行鏡像處理。局域 網(wǎng)管理員為出站路由器設(shè)置了端口鏡像功能，以便把復(fù)制的所有流量引導(dǎo)至我接入嗅探器的 那只端口上。Tcpdump 會話本身不會獲得任何明顯的結(jié)果，于是我決定試試趨勢分析。我在網(wǎng)絡(luò)邊界 開始了 iptraf 會話一一選擇端口分析是為了確定流量模式，結(jié)果發(fā)現(xiàn)傳輸?shù)絋CP端口 6699的流量很大。在路由器端通過訪問控制列表（ACL封阻該端口，就可以讓網(wǎng)絡(luò)流量模式恢復(fù)正常。進(jìn)一步研究后發(fā)現(xiàn)，使用這個端口的是當(dāng)時屬于第一個大

5、規(guī)模的因特網(wǎng)對等音樂共享服 務(wù) Napster 。由于 Napster 音樂共享不屬于工作計劃的一部分，所以就封阻了該端口，這樣就用不著掏大筆費用升級因特網(wǎng)帶寬了。第三個例子圍繞名為 Slammer蠕蟲的微軟SQL Server 2000和微軟桌面引擎 2000漏洞， 這個蠕蟲從技術(shù)上來說又叫W3SQLExp.Worm賽門鐵克公司對這個漏洞有詳細(xì)介紹，不過當(dāng)時我遇到這個問題時，顯然不知道原因是什么。癥狀類似第一個例子當(dāng)中的ICMP拒絕服務(wù)攻擊，因為因特網(wǎng)連接速度變慢了。 不過這個網(wǎng)絡(luò)比較復(fù)雜 : 局域網(wǎng)由幾個子網(wǎng)組成， 這些子網(wǎng) 通過路由器互連起來，如圖 3 所示。幸好，使用MRT刖以定期收集

6、到有關(guān)每個子網(wǎng)的流量模式的基準(zhǔn)統(tǒng)計信息，因而可以了解正常流量應(yīng)當(dāng)是什么樣的歷史信息。我們立即發(fā)現(xiàn)，其中三個子網(wǎng)的入站流量（來自子網(wǎng) 本身）比正常情況大得多。直覺告訴我，問題就出現(xiàn)在這些子網(wǎng)上。不過，因為受到影響的 是因特網(wǎng)連接，所以在網(wǎng)絡(luò)邊界進(jìn)行探測再度成了合理的步驟。網(wǎng)絡(luò)管理員在網(wǎng)絡(luò)邊界處安裝了Linux嗅探器，與邊界相連的是 100Mbps速率的邊界網(wǎng)絡(luò)交換機(jī)，該交換機(jī)通過 tcpdump 不斷收集統(tǒng)計信息，并且每隔 15 分鐘，然后通過 cron 任 務(wù)和FTP把結(jié)果轉(zhuǎn)儲到中央服務(wù)器。分析這些日志后發(fā)現(xiàn)：通過三個內(nèi)部IP地址的流量占了流量的大部分。我在嗅探器上運行了 iptraf 會話，

7、 因為局域網(wǎng)管理員以前也加載了這個軟件包。 盡管我 期望看到針對單個 TCP端口出現(xiàn)多次訪問（這是拒絕服務(wù)攻擊的常見特征），但實際情況并非 如此。然而，底部的iptraf 容器卻在迅速滾屏顯示發(fā)往某個UDP端口 1434的用戶數(shù)據(jù)報協(xié)議（UDP數(shù)據(jù)包。把三個核心局域網(wǎng)路由器上的這個端口封阻后，拒絕服務(wù)攻擊就不復(fù)存在了。不過，含有受感染機(jī)器的三個子網(wǎng)的性能仍相當(dāng)?shù)?，這是由于這些被感染機(jī)器帶來了很 大的網(wǎng)絡(luò)流量。如果記有精確的網(wǎng)絡(luò)記錄， 就有可能把 IP 地址與交換機(jī)端口關(guān)聯(lián)起來、 找到合適的端口， 并且以邏輯或者物理方式斷開端口。但問題是沒有這樣的記錄。幸好，網(wǎng)絡(luò)管理員運行了網(wǎng)絡(luò)管理軟件包，可以

8、查詢子網(wǎng)上的所有交換機(jī)，確定某個介 質(zhì)訪問控制（MAC地址在何處連接。把 MAC地址和IP地址關(guān)聯(lián)起來，這就如同查詢核心路 由器的地址解析協(xié)議表這么簡單。端口確認(rèn)后，被感染的機(jī)器處于斷開狀態(tài)，直到問題解決后再讓它們連接到網(wǎng)絡(luò)上，因 而恢復(fù)了網(wǎng)絡(luò)運作。核心路由器被感染確認(rèn)及解決第四個例子中的問題相當(dāng)困難。問題不是在于漏洞類型，也不在于生成流量 的數(shù)量；實際上，流量不像前幾個例子那樣讓因特網(wǎng)帶寬處于滿負(fù)荷狀態(tài)。區(qū)別在于，核心 網(wǎng)絡(luò)路由器的感染方式。網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)類似第三個例子。問題不僅僅表現(xiàn)為因特網(wǎng)連接速度緩慢，還表現(xiàn)為子網(wǎng) 之間的連接速度也很慢，就連以物理和邏輯方式與同一路由器相連接的那些子網(wǎng)也是

9、這樣。 與第三個例子一樣，也建立了 MRTG詢機(jī)制，以監(jiān)控每個路由器的子網(wǎng)流量以及核心路由器的CPU負(fù)載。查看MRT啲圖示結(jié)果后即可看到正確的穩(wěn)定流量和CPU使用率。MRTG勺特點之一就是，如果它無法查詢具有簡單網(wǎng)絡(luò)管理協(xié)議（SNM）P 功能的設(shè)備，會在統(tǒng)計信息最后取得的值上顯示一條水平線，不管是什么值。這個例子也是如此。MRTG艮務(wù)器工作正常得到了證實。大多數(shù)企業(yè)核心路由器具有類似 Linux 中 top 命令的功能。這個命令實際上顯示了 CPU 使用率最高的路由器進(jìn)程。我試圖向其中一個路由器開啟終端會話，但沒有成功。幸好，每 個核心路由器都有調(diào)解解調(diào)器連接到路由器的通信端口，所以使用Win

10、dows 中的超級終端（HyperTerminal ）程序，就能夠撥號進(jìn)入其中一個路由器的控制臺會話。雖然連控制臺連接的速度也很慢，我還是得以查明：路由器的 CPU使用率達(dá)到了峰值100% CPU使用率最高的進(jìn)程是路由進(jìn)程本身。探測子網(wǎng)是理所當(dāng)然的步驟。探測表明多個源IP地址和目的地IP地址集中于一個 TCP目的地端口 135。這時，全憑 經(jīng)驗的我信心十足地建議網(wǎng)絡(luò)管理員應(yīng)當(dāng)利用ACL封阻每個路由器的 TCP端口 135。我以為，我們可以以后處理停止正常工作的微軟應(yīng)用軟件，因為恢復(fù)網(wǎng)絡(luò)功能極為重要。讓我感到郁 悶的是，封阻該端口后并沒有降低路由器CPU的使用率。路由器是第三層交換設(shè)備，正因為如

11、此，它們通常被稱為第三層交換機(jī)。這意味著，路由器根據(jù)第三層（這里是 IP ）地址來確定數(shù)據(jù)包的目的地。我查明ACL之所以不起作用，原因就是路由器在實施 ACL規(guī)則之前，仍得處理數(shù)據(jù)包的第三層信息。正是這個原因?qū)е侣酚?器CPU的使用率達(dá)到高峰以及隨后的網(wǎng)絡(luò)擁塞。下面介紹為什么有必要深入了解開放系統(tǒng)互連（OSI）參考模型。每個子網(wǎng)分布交換機(jī)都是能夠識別第三層和第四層的企業(yè)交換機(jī)。實際上這意味著，類似ACL的命令可以在這些交換機(jī)上執(zhí)行。對與其中一個路由器相連的所有子網(wǎng)分布交換機(jī)實施封阻TCP端口 135的操作，這可以獲得封阻流量傳輸?shù)铰酚善鞯念A(yù)期效果，從而讓CPU的使用率可以回落到正常水平。第二層交換機(jī)本身不會出現(xiàn)CPU使用率增加的問題。這是由這