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

使用Linux工具診斷網(wǎng)絡(luò)問題 如果結(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ù)浣Y(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)，由兩只集線器和一只交換機（幾臺本地服務(wù)器與交換機相連）負(fù)責(zé)分布，一條線路從該交換機連接到因特網(wǎng)，如圖1所示。輕則速度緩慢，重則不穩(wěn)定。局域網(wǎng)性能良好，只是因特網(wǎng)流量受到了影響。 因為這只速率100Mbps的交換機沒有端口鏡像（port mirroring）這項功能，我從自己的網(wǎng)絡(luò)工具包中取出了一只小型集線器，把它插入在100Mbps交換機和ISDN路由器之間，如圖2所示。沒錯，這改變了原有的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，但因為沒有端口鏡像功能端口鏡像功能可以把一個端口上經(jīng)過的所有流量復(fù)制到另一個端口上，所以插入集線器是最好的選擇辦法了。這種辦法有著諸多優(yōu)點，雖然端口鏡像不會顯示物理層錯誤，但我還是通常偏愛端口鏡像功能。 我把Linux嗅探器接到先前插入的集線器，繼續(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)用引起使用量增加，那么也許沒有必要花這筆費用。 我的任務(wù)就是，確定帶寬使用量的增加是由于工作需要、拒絕服務(wù)攻擊還是其他什么因素。該網(wǎng)絡(luò)類似第一個例子，但交換機能夠?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)時屬于第一個大規(guī)模的因特網(wǎng)對等音樂共享服務(wù)：Napster。由于Napster音樂共享不屬于工作計劃的一部分，所以就封阻了該端口，這樣就用不著掏大筆費用升級因特網(wǎng)帶寬了。 第三個例子圍繞名為Slammer蠕蟲的微軟SQL Server 2000和微軟桌面引擎2000漏洞，這個蠕蟲從技術(shù)上來說又叫W32.SQLExp.Worm。賽門鐵克公司對這個漏洞有詳細(xì)介紹，不過當(dāng)時我遇到這個問題時，顯然不知道原因是什么。癥狀類似第一個例子當(dāng)中的ICMP拒絕服務(wù)攻擊，因為因特網(wǎng)連接速度變慢了。不過這個網(wǎng)絡(luò)比較復(fù)雜:局域網(wǎng)由幾個子網(wǎng)組成，這些子網(wǎng)通過路由器互連起來，如圖3所示。 幸好，使用MRTG可以定期收集到有關(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ò)交換機，該交換機通過tcpdump不斷收集統(tǒng)計信息，并且每隔15分鐘，然后通過cron任務(wù)和FTP把結(jié)果轉(zhuǎn)儲到中央服務(wù)器。分析這些日志后發(fā)現(xiàn):通過三個內(nèi)部IP地址的流量占了流量的大部分。 我在嗅探器上運行了iptraf會話，因為局域網(wǎng)管理員以前也加載了這個軟件包。盡管我期望看到針對單個TCP端口出現(xiàn)多次訪問（這是拒絕服務(wù)攻擊的常見特征），但實際情況并非如此。然而，底部的iptraf容器卻在迅速滾屏顯示發(fā)往某個UDP端口：1434的用戶數(shù)據(jù)報協(xié)議（UDP）數(shù)據(jù)包。把三個核心局域網(wǎng)路由器上的這個端口封阻后，拒絕服務(wù)攻擊就不復(fù)存在了。不過，含有受感染機器的三個子網(wǎng)的性能仍相當(dāng)?shù)停@是由于這些被感染機器帶來了很大的網(wǎng)絡(luò)流量。 如果記有精確的網(wǎng)絡(luò)記錄，就有可能把IP地址與交換機端口關(guān)聯(lián)起來、找到合適的端口，并且以邏輯或者物理方式斷開端口。但問題是沒有這樣的記錄。 幸好，網(wǎng)絡(luò)管理員運行了網(wǎng)絡(luò)管理軟件包，可以查詢子網(wǎng)上的所有交換機，確定某個介質(zhì)訪問控制（MAC）地址在何處連接。把MAC地址和IP地址關(guān)聯(lián)起來，這就如同查詢核心路由器的地址解析協(xié)議表這么簡單。 端口確認(rèn)后，被感染的機器處于斷開狀態(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)也是這樣。與第三個例子一樣，也建立了MRTG查詢機制，以監(jiān)控每個路由器的子網(wǎng)流量以及核心路由器的CPU負(fù)載。 查看MRTG的圖示結(jié)果后即可看到正確的穩(wěn)定流量和CPU使用率。MRTG的特點之一就是，如果它無法查詢具有簡單網(wǎng)絡(luò)管理協(xié)議（SNMP）功能的設(shè)備，會在統(tǒng)計信息最后取得的值上顯示一條水平線，不管是什么值。這個例子也是如此。MRTG服務(wù)器工作正常得到了證實。 大多數(shù)企業(yè)核心路由器具有類似Linux中top命令的功能。這個命令實際上顯示了CPU使用率最高的路由器進(jìn)程。我試圖向其中一個路由器開啟終端會話，但沒有成功。幸好，每個核心路由器都有調(diào)解解調(diào)器連接到路由器的通信端口，所以使用Windows中的超級終端（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è)備，正因為如此，它們通常被稱為第三層交換機。這意味著，路由器根據(jù)第三層（這里是IP）地址來確定數(shù)據(jù)包的目的地。我查明：ACL之所以不起作用，原因就是路由器在實施ACL規(guī)則之前，仍得處理數(shù)據(jù)包的第三層信息。正是這個原因?qū)е侣酚善鰿PU的使用率達(dá)到高峰以及隨后的網(wǎng)絡(luò)擁塞。 下面介紹為什么有必要深入了解開放系統(tǒng)互連（OSI）參考模型。每個子網(wǎng)分布交換機都是能夠識別第三層和第四層的企業(yè)交換機。實際上這意味著，類似ACL的命令可以在這些交換機上執(zhí)行。對與其中一個路由器相連的所有子網(wǎng)分布交換機實施封阻TCP端口135的操作，這可以獲得封阻流量傳輸?shù)铰酚善鞯念A(yù)期效果，從而讓CPU的使用率可以回落到正常水平。 第二層交換機本身不會出現(xiàn)CPU使用率增加