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

1、使用 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 地址的專用子

2、網(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)點，雖然

3、端口鏡像 不會顯示物理層錯誤，但我還是通常偏愛端口鏡像功能。我把 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)帶寬的使用量接近 了需要帶寬升級的地步。單單添

4、加帶寬來解決這類問題似乎 是項合理的措施，但是如果與用戶工作毫無關(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ù)?TCP 端口 6699 的流量很大。在路由器端通過訪問控制

5、列表（ 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)連接速度

6、變慢了。 不過這個網(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 分鐘，然后通過 cr

7、on 任務(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ò)流 量。

8、如果記有精確的網(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)帶寬處

9、于滿負(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ù)器工作正常得到了

10、證實。大多數(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 目的地

11、端口： 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ū)е侣酚善?CPU 的使用率達(dá)到高 峰以及隨后的網(wǎng)絡(luò)擁塞。下面介紹為什么有必要深入了解開放系統(tǒng)互連（ OSI ） 參考模型。每個子網(wǎng)分布交換機都是能夠識別第三層和第四 層的企業(yè)交換機。實際上這意味著，類似 ACL 的命令可以 在這些交換機上執(zhí)行。對與其中一個路由器相連的所有子網(wǎng) 分布交換機實施封阻 TCP 端口 135 的操作，這可以獲得封阻 流量傳輸?shù)铰酚善鞯念A(yù)期效果， 從而讓 CPU 的使用率可以回 落到正常水平。第二層交換機本身不會出現(xiàn) CPU 使用率增加的問題。