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

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

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

3、探測(cè)：只要使用基本的tcpdump-i-n命令。因?yàn)槲蚁Ｍ麊栴}屬于某一種類型的數(shù)據(jù)包，與數(shù)據(jù)包里面實(shí)際所含內(nèi)容沒有關(guān)系。我猜對(duì)了，因?yàn)橛涗浀娜胝緮?shù)據(jù)包幾乎全都是來自不同IP地址的因特網(wǎng)控制消息協(xié)議（ICMP）回應(yīng)請(qǐng)求。打電話給因特網(wǎng)服務(wù)提供商（ISP）要求封阻入站ICMP回應(yīng)請(qǐng)求后，問題馬上得到了解決。Napster耗用帶寬第二個(gè)例子與因特網(wǎng)帶寬使用量增加有關(guān)，但還不至于發(fā)展到導(dǎo)致不穩(wěn)定性的地步。當(dāng)時(shí)因特網(wǎng)帶寬的使用量接近了需要帶寬升級(jí)的地步。單單添加帶寬來解決這類問題似乎是項(xiàng)合理的措施，但是如果與用戶工作毫無關(guān)系的某個(gè)應(yīng)用引起使用量增加，那么也許沒有必要花這筆費(fèi)用。我的任務(wù)就是，確定帶寬使用

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

5、享不屬于工作計(jì)劃的一部分，所以就圭寸阻了該端口，這樣就用不著掏大筆費(fèi)用升級(jí)因特網(wǎng)帶寬了。第三個(gè)例子圍繞名為Slammer蠕蟲的微軟SQLServer2000和微軟桌面引擎2000漏洞，這個(gè)蠕蟲從技術(shù)上來說又叫賽門鐵克公司對(duì)這個(gè)漏洞有詳細(xì)介紹，不過當(dāng)時(shí)我遇到這個(gè)問題時(shí)，顯然不知道原因是什么。癥狀類似第一個(gè)例子當(dāng)中的ICMP拒絕服務(wù)攻擊，因?yàn)橐蛱鼐W(wǎng)連接速度變慢了。不過這個(gè)網(wǎng)絡(luò)比較復(fù)雜：局域網(wǎng)由幾個(gè)子網(wǎng)組成，這些子網(wǎng)通過路由器互連起來，如圖3所示。幸好，使用MRT刮以定期收集到有關(guān)每個(gè)子網(wǎng)的流量模式的基準(zhǔn)統(tǒng)計(jì)信息，因而可以了解正常流量應(yīng)當(dāng)是什么樣的歷史信息。我們立即發(fā)現(xiàn)，其中三個(gè)子網(wǎng)的入站流量（來自

6、子網(wǎng)本身）比正常情況大得多。直覺告訴我，問題就出現(xiàn)在這些子網(wǎng)上。不過，因?yàn)槭艿接绊懙氖且蛱鼐W(wǎng)連接，所以在網(wǎng)絡(luò)邊界進(jìn)行探測(cè)再度成了合理的步驟。網(wǎng)絡(luò)管理員在網(wǎng)絡(luò)邊界處安裝了Linux嗅探器，與邊界相連的是100Mbps速率的邊界網(wǎng)絡(luò)交換機(jī)，該交換機(jī)通過tcpdump不斷收集統(tǒng)計(jì)信息，并且每隔15分鐘，然后通過cron任務(wù)和FTP把結(jié)果轉(zhuǎn)儲(chǔ)到中央服務(wù)器。分析這些日志后發(fā)現(xiàn)：通過三個(gè)內(nèi)部IP地址的流量占了流量的大部分。我在嗅探器上運(yùn)行了iptraf會(huì)話，因?yàn)榫钟蚓W(wǎng)管理員以前也加載了這個(gè)軟件包。盡管我期望看到針對(duì)單個(gè)TCP端口出現(xiàn)多次訪問（這是拒絕服務(wù)攻擊的常見特征），但實(shí)際情況并非如此。然而，底部的i

7、ptraf容器卻在迅速滾屏顯示發(fā)往某個(gè)UDP端口：1434的用戶數(shù)據(jù)報(bào)協(xié)議（UDP數(shù)據(jù)包。把三個(gè)核心局域網(wǎng)路由器上的這個(gè)端口封阻后，拒絕服務(wù)攻擊就不復(fù)存在了。不過，含有受感染機(jī)器的三個(gè)子網(wǎng)的性能仍相當(dāng)?shù)?，這是由于這些被感染機(jī)器帶來了很大的網(wǎng)絡(luò)流量。如果記有精確的網(wǎng)絡(luò)記錄，就有可能把IP地址與交換機(jī)端口關(guān)聯(lián)起來、找到合適的端口，并且以邏輯或者物理方式斷開端口。但問題是沒有這樣的記錄。幸好，網(wǎng)絡(luò)管理員運(yùn)行了網(wǎng)絡(luò)管理軟件包，可以查詢子網(wǎng)上的所有交換機(jī)，確定某個(gè)介質(zhì)訪問控制（MAC地址在何處連接。把MAC地址和IP地址關(guān)聯(lián)起來，這就如同查詢核心路由器的地址解析協(xié)議表這么簡(jiǎn)單。端口確認(rèn)后，被感染的機(jī)器處

8、于斷開狀態(tài)，直到問題解決后再讓它們連接到網(wǎng)絡(luò)上，因而恢復(fù)了網(wǎng)絡(luò)運(yùn)作。核心路由器被感染確認(rèn)及解決第四個(gè)例子中的問題相當(dāng)困難。問題不是在于漏洞類型，也不在于生成流量的數(shù)量；實(shí)際上，流量不像前幾個(gè)例子那樣讓因特網(wǎng)帶寬處于滿負(fù)荷狀態(tài)。區(qū)別在于，核心網(wǎng)絡(luò)路由器的感染方式。網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)類似第三個(gè)例子。問題不僅僅表現(xiàn)為因特網(wǎng)連接速度緩慢，還表現(xiàn)為子網(wǎng)之間的連接速度也很慢，就連以物理和邏輯方式與同一路由器相連接的那些子網(wǎng)也是這樣。與第三個(gè)例子一樣，也建立了MRTC查詢機(jī)制，以監(jiān)控每個(gè)路由器的子網(wǎng)流量以及核心路由器的CPU負(fù)載。查看MRTG勺圖示結(jié)果后即可看到正確的穩(wěn)定流量和CPU使用率。MRTG勺特點(diǎn)之一就是

9、，如果它無法查詢具有簡(jiǎn)單網(wǎng)絡(luò)管理協(xié)議（SNMP功能的設(shè)備，會(huì)在統(tǒng)計(jì)信息最后取得的值上顯示一條水平線，不管是什么值。這個(gè)例子也是如此。MRTG艮務(wù)器工作正常得到了證實(shí)。大多數(shù)企業(yè)核心路由器具有類似Linux中top命令的功能。這個(gè)命令實(shí)際上顯示了CPU使用率最高的路由器進(jìn)程。我試圖向其中一個(gè)路由器開啟終端會(huì)話，但沒有成功。幸好，每個(gè)核心路由器都有調(diào)解解調(diào)器連接到路由器的通信端口，所以使用Windows中的超級(jí)終端（HyperTerminal）程序，就能夠撥號(hào)進(jìn)入其中一個(gè)路由器的控制臺(tái)會(huì)話。雖然連控制臺(tái)連接的速度也很慢，我還是得以查明：路由器的CPU使用率達(dá)到了峰值：100%CPU使用率最高的進(jìn)程

10、是路由進(jìn)程本身。探測(cè)子網(wǎng)是理所當(dāng)然的步驟。探測(cè)表明多個(gè)源IP地址和目的地IP地址集中于一個(gè)TCP目的地端口：135。這時(shí)，全憑經(jīng)驗(yàn)的我信心十足地建議：網(wǎng)絡(luò)管理員應(yīng)當(dāng)利用ACL封阻每個(gè)路由器的TCP端口135。我以為，我們可以以后處理停止正常工作的微軟應(yīng)用軟件，因?yàn)榛謴?fù)網(wǎng)絡(luò)功能極為重要。讓我感到郁悶的是，封阻該端口后并沒有降低路由器CPU的使用率。路由器是第三層交換設(shè)備，正因?yàn)槿绱?，它們通常被稱為第三層交換機(jī)。這意味著，路由器根據(jù)第三層（這里是IP）地址來確定數(shù)據(jù)包的目的地。我查明：ACL之所以不起作用，原因就是路由器在實(shí)施ACL規(guī)則之前，仍得處理數(shù)據(jù)包的第三層信息。正是這個(gè)原因?qū)е侣酚善鰿PU的使用率達(dá)到高峰以及隨后的網(wǎng)絡(luò)擁塞。下面介紹為什么有必要深入了解開放系統(tǒng)互連（OSI）參考模型。每個(gè)子網(wǎng)分布交換機(jī)都是能夠識(shí)別第三層和第四層的企業(yè)交換機(jī)。實(shí)際上這意味著，類似ACL的命令可以在這些交換機(jī)上執(zhí)行。對(duì)與其中一個(gè)路由器相連的所有子網(wǎng)分布交換機(jī)實(shí)施圭寸阻TCP端口135的操作，這可以獲得圭寸阻流量傳輸?shù)铰酚善鞯念A(yù)期效果，從而讓CPU的使用率可以回落到正常水平。第二層交換機(jī)本身不會(huì)出現(xiàn)CPU使用率增加的