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

1、使用Linux工具診斷網(wǎng)絡(luò)問(wèn)題 如果結(jié)合使用Linux發(fā)行版Fedora Core和開放源代碼軟件包 libpcap、tcpdump、iptraf以及多路由器流量圖示器（MRTG），就可以為查明網(wǎng)絡(luò)問(wèn)題產(chǎn)生的根源提供有價(jià)值的信息。 連接速度慢 在第一個(gè)例子中，一個(gè)小型網(wǎng)絡(luò)使用384Kbps速率的ISDN連接至因特網(wǎng)，其問(wèn)題在為網(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)單：通過(guò)網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）協(xié)議轉(zhuǎn)換成單一公共IP地址的專用子網(wǎng)，由兩只集線器和一只交換機(jī)（幾臺(tái)本地服務(wù)器

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

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

4、用。 我的任務(wù)就是，確定帶寬使用量的增加是由于工作需要、拒絕服務(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的流量很大。在路由器端通過(guò)訪問(wèn)控制列表（ACL）封阻該端口，就可以讓網(wǎng)絡(luò)流量模式恢復(fù)正常。 進(jìn)一步研究后發(fā)現(xiàn)，使用這個(gè)端口的是當(dāng)時(shí)屬于第一個(gè)大規(guī)模的因特網(wǎng)對(duì)等音樂(lè)共享服務(wù)：Na

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

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

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

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

9、CPU負(fù)載。 查看MRTG的圖示結(jié)果后即可看到正確的穩(wěn)定流量和CPU使用率。MRTG的特點(diǎn)之一就是，如果它無(wú)法查詢具有簡(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ì)話，但沒(méi)有成功。幸好，每個(gè)核心路由器都有調(diào)解解調(diào)器連接到路由器的通信端口，所以使用Windows中的超級(jí)終端（HyperTerminal）程序，就能夠撥號(hào)進(jìn)入其中一個(gè)路由器的控制臺(tái)會(huì)話。 雖然

10、連控制臺(tái)連接的速度也很慢，我還是得以查明:路由器的CPU使用率達(dá)到了峰值：100%。CPU使用率最高的進(jìn)程是路由進(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ò)功能極為重要。讓我感到郁悶的是，封阻該端口后并沒(méi)有降低路由器CPU的使用率。 路由器是第三層交換設(shè)備，正因?yàn)槿绱?，它們通常被稱為第三層交換機(jī)。這意味著，路由器根據(jù)第三層（這里是IP）地址來(lái)確定數(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使用率增加