立足網絡層 輕松排除網絡故障
下面將列舉兩個基于網絡層的網絡故障分析案例。
分析工具：科來網絡分析系統6.0專家版(當然大家也可以用類似的工具)
一、巧用TTL值診斷網絡故障
1、簡介
TTL，全稱是Time To Live，中文名為“生存時間”，它是IP報頭中一個非常重要的參數。通過TTL的值，我們可以判斷出當前網絡IP層的工作狀況。
TTL告訴網絡中的路由器數據包在網絡中的時間是否太長而應被丟棄，TTL的最初設想是確定一個時間范圍，超過此時間就把包丟棄。由于數據包每經過一個路由器時，TTL值都會至少被路由器減1，所以TTL值通常表示包在被丟棄前還能最多經過的路由器個數。當TTL值為0時，路由器丟棄該數據包，并發送一個ICMP報文給數據包的最初發送者。
有很多原因會導致數據包在一定時間內不能被傳遞到目的地。例如，不正確的路由表配置可能導致數據包的無限循環，而解決方法就是在一段時間后丟棄這個數據包，然后給發送者發送一個報文，由發送者決定是否重發該數據包。當網絡出現這種情況時，數據包就會在路由表中配置錯誤的路由器處重復發送，每發送一次，TTL值減1，直到TTL為0時路由器丟棄該數據包，造成網絡中數據傳輸錯誤。
操作系統和傳輸協議不同，對應TTL的默認值也不同。圖1列出了常見操作系統通過TCP和UDP協議傳輸時的TTL默認值。(圖1)
2、查看數據包的TTL值并分析傳輸故障
網絡中的網絡設備，其內部都是由操作系統進行處理的(有些硬件設備將系統預裝在了硬件芯片里面)，在網絡遇到傳輸故障時，我們可以使用網絡檢測軟件，結合上表的信息對網絡中流通的數據包進行檢測，查看數據包的TTL值，以確定故障是否由錯誤的路由等原因引起。圖2是使用科來網絡分析系統5.0查看一個數據包TTL值的情況。(圖2)
圖中的生存時間(TTL)是247，結合圖1，確定出這個數據包在從源端(這里是61.139.2.69)到目的端(這里是192.168.10.44)共經歷了255-247=8個路由器，且在傳輸過程中未出現故障。
注意：
1.確定數據包在網絡中經歷了多少個路由器，可用數據包源端設備的TTL默認值減去捕獲到的數據包TTL值;
2.在不知道數據包源端設備的默認TTL時，一般用大于捕獲數據包的TTL，且最接近這個TTL的默認值。
3.TTL字段長1個字節，所以TTL的最大值255;
通過查看數據包的TTL，可以確定網絡傳輸是否正常。如果捕獲到的數據包的TTL值過小，則表示網絡中很可能存在傳輸故障，應及時檢查網絡中三層設備的路由表配置，以及各主機上的路由表信息。#p#
二、利用TCP標記分析故障
1、TCP標記簡介
TCP，全稱Transfer Control Protocol，中文名為傳輸控制協議;它工作在OSI的傳輸層，提供面向連接的可靠傳輸服務。
在TCP的報頭中，有一個TCP標記字段，這個字段用來指出當前這個數據包的用途。TCP連接標記字段長6比特，共有6種不同的標記，在一個TCP連接中可能會使用其中的多個標記。這6種標記是：
(1).緊急(Urgent，簡稱URG)：通知對方主機該TCP數據包中包含有緊急數據;
(2).確認(Acknowledgement,簡稱ACK)：用來確認接收到對方主機的TCP數據包;
(3).急迫(Push，簡稱PSH)：通知對方主機立即將該數據包送往上層協議;
(4).重置(Reset，簡稱RST)：表示此TCP連接已被對方主機重新啟動;
(5).同步(Synchronization，簡稱SYN)：用來建立和對方主機的TCP連接;
(6).終止(Finish，簡稱FIN)：用來關閉TCP連接。
不同數據包中的TCP 標記可能相同，也可能不同，通過數據包的解碼，可以知道當前數據包正在進行的操作及其作用。如TCP三次握手的第一步會將同步位置為1;第二步會同時將確認位和同步位置為1;第三步會將確認位置為1。根據TCP標記的特性，我們可以利用它分析網絡中常見的網絡應用故障。
2、利用TCP標記分析網絡故障
當遇到目標主機的某TCP服務不能訪問時，我們可以通過對其訪問的過程進行抓包分析，從而找出不能訪問的原因，下面我們用科來網絡分析系統6.0，以分析Telnet為例說明分析的方法。
圖3是在Windows客戶端(客戶端主機名為lw)上使用Telnet命令訪問其他主機的情況。從圖3的返回結果可知，兩臺主機的Telnet服務都不能正常訪問，但我們無法確定不能訪問的原因，是因為網絡不通，還是這臺主機沒有提供Telnet服務。(圖3)
注意：
(1).這里使用的Telnet命令是在假定目標服務器使用默認的端口配置，即Telnet服務器端口是TCP 23;
(2).可能有些用戶想到使用Ping命令測試網絡的連通性，但由于承載Ping命令的ICMP協議可以導致一些非法攻擊，對網絡的安全會造成一定的威脅，使得某些ISP廠商或者網絡管理員都在他們的三層設備處禁用了ICMP協議的轉發。在這種情況下，使用Ping命令便無法準確測試主機的連通性。
圖4是在WINDOWS客戶端使用Telnet命令訪問192.168.2.10主機時，科來網絡分析系統6.0捕獲到的數據包信息。(圖4)
從圖4可知，使用Telnet命令訪問192.168.2.10主機時，兩主機間共有三個數據包通信，仔細查看數據包及其解碼，發現三個數據包都是從客戶端發往192.168.2.10主機的，三個數據包的確認號都是0，且都將TCP標記中的同步位置1，表明三個數據包都是TCP三次握手的第一步，即TCP同步數據包。沒有從192.168.2.10發往客戶端的數據包，說明此時客戶端與192.168.2.10主機在物理鏈路上不通，可能是網絡中沒有IP地址為192.168.2.10這臺機器，或者這臺機器沒有開機。#p#
圖5是在WINDOWS客戶端使用Telnet命令訪問192.168.2.100主機時，科來網絡分析系統6.0捕獲到的數據包信息。(圖5)
從圖5可知，使用Telnet命令訪問192.168.2.100主機時，兩主機間共有6個數據包通信，仔細查看數據包及其解碼，發現1,3,5這三個數據包是從客戶端發往192.168.2.100主機的，這三個數據包的確認號是0，TCP標記是同步位置1，表明三個數據包都是TCP三次握手的第一步，即TCP同步數據包。2,4,6這三個數據包是從192.168.2.100主機發往客戶端的，這三個數據包的確認號是確認號2643478089，TCP標記是確認位和重置位同時置1，表示這三個數據包都是192.168.2.100對客戶端的確認數據包，同時它拒絕了客戶端的建立連接的TCP同步請求，告訴客戶端當前主機(這里是192.168.2.100)沒有打開客戶端請求的服務，并中斷這個連接。
注意：我們發現在圖4和圖5中，客戶端都向服務器(這里是192.168.2.10和192.168.2.100)發送了三次相同的TCP SYN請求，這是為什么呢?其實這是TCP的協議規定造成的，當客戶端使用TCP SYN向服務器發起三方握手的第一步后，如果沒有收到服務器的SYN/ACK響應，就會在等待一段時間后再次嘗試對服務器進行連接，如果連接三次后仍然失敗，則不會再重復此操作，所以我們在圖中看到了三次完全一樣的TCP SYN數據包。
通過對上面兩種情況的抓包分析，我們可知道，192.168.2.10主機不能訪問的原因是兩臺主機之間的物理鏈路不通，可能是不存在192.168.2.10這臺機器，或者192.168.2.10處于關機狀態等。而192.168.2.100不能訪問的原因是192.168.2.100這臺機器沒有提供客戶端請求的Telnet服務，即沒有打開TCP 23端口。
總結
當然，筆者列舉的兩個應用案例只是個案。其實這種方法適用于中所有的TCP服務，用戶在遇到不能訪問某服務器(各種TCP應用的服務器)時，便可使用這種方法對數據包進行跟蹤分析，幫助用戶對故障進行排查。這樣，管理員從網絡層把握網絡故障，就能夠不受故障表象的影響，從而盡快排除故障，利于提高工作效率。
【編輯推薦】
