第1章 Sniffer軟件簡介
概述
Sniffer軟件是NAI公司推出的功能強大的協議分析軟件。本文針對用Sniffer Pro網絡分析器進行故障解決。利用Sniffer Pro 網絡分析器的強大功能和特徵，解決網絡問題，將介紹一套合理的故障解決方法。
與Netxray比較，Sniffer支持的協議更豐富，例如PPPOE協議等在Netxray並不支持，在Sniffer上能夠進行快速解碼分析。Netxray不能在Windows 2000和Windows XP上正常運行，Sniffer Pro 4.6可以運行在各種Windows平臺上。
Sniffer軟件比較大，運行時需要的計算機內存比較大，否則運行比較慢，這也是它與Netxray相比的一個缺點。
功能簡介
下面列出了Sniffer軟件的一些功能介紹，其功能的詳細介紹可以參考Sniffer的在線幫助。
捕獲網絡流量進行詳細分析
利用專家分析系統診斷問題
實時監控網絡活動
收集網絡利用率和錯誤等
在進行流量捕獲之前首先選擇網絡適配器，確定從計算機的哪個網絡適配器上接收數據。位置：File->select settings
選擇網絡適配器後才能正常工作。該軟件安裝在Windows 98操作系統上，Sniffer可以選擇撥號適配器對窄帶撥號進行操作。如果安裝了EnterNet500等PPPOE軟件還可以選擇虛擬出的PPPOE網卡。對於安裝在Windows 2000/XP上則無上述功能，這和操作系統有關。
本文將對報文的捕獲幾網絡性能監視等功能進行詳細的介紹。下圖爲在軟件中快捷鍵的位置。
第2章 報文捕獲解析
2.1 捕獲面板
報文捕獲功能可以在報文捕獲面板中進行完成，如下是捕獲面板的功能圖：圖中顯示的是處於開始狀態的面板
2.2 捕獲過程報文統計
在捕獲過程中可以通過查看下面面板查看捕獲報文的數量和緩衝區的利用率。
2.3 捕獲報文查看
Sniffer軟件提供了強大的分析能力和解碼功能。如下圖所示，對於捕獲的報文提供了一個Expert專家分析系統進行分析，還有解碼選項及圖形和表格的統計信息。
專家分析
專家分分析系統提供了一個只能的分析平臺，對網絡上的流量進行了一些分析對於分析出的診斷結果可以查看在線幫助獲得。
在下圖中顯示出在網絡中WINS查詢失敗的次數及TCP重傳的次數統計等內容，可以方便了解網絡中高層協議出現故障的可能點。
對於某項統計分析可以通過用鼠標雙擊此條記錄可以查看詳細統計信息且對於每一項都可以通過查看幫助來了解起產生的原因。
解碼分析
下圖是對捕獲報文進行解碼的顯示，通常分爲三部分，目前大部分此類軟件結構都採用這種結構顯示。對於解碼主要要求分析人員對協議比較熟悉，這樣才能看懂解析出來的報文。使用該軟件是很簡單的事情，要能夠利用軟件解碼分析來解決問題關鍵是要對各種層次的協議瞭解的比較透徹。工具軟件只是提供一個輔助的手段。因涉及的內容太多，這裏不對協議進行過多講解，請參閱其他相關資料。
對於MAC地址，Snffier軟件進行了頭部的替換，如00e0fc開頭的就替換成Huawei，這樣有利於瞭解網絡上各種相關設備的製造廠商信息。
功能是按照過濾器設置的過濾規則進行數據的捕獲或顯示。在菜單上的位置分別爲 Capture->Define Filter和Display->Define Filter。
過濾器可以根據物理地址或IP地址和協議選擇進行組合篩選。
統計分析
對於Matrix，Host Table，Portocol Dist. Statistics等提供了豐富的按照地址，協議等內容做了豐富的組合統計，比較簡單，可以通過操作很快掌握這裏就不再詳細介紹了。
2.4 設置捕獲條件
基本捕獲條件
基本的捕獲條件有兩種：
1、鏈路層捕獲，按源MAC和目的MAC地址進行捕獲，輸入方式爲十六進制連續輸入，如：00E0FC123456。
2、IP層捕獲，按源IP和目的IP進行捕獲。輸入方式爲點間隔方式，如：10.107.1.1。如果選擇IP層捕獲條件則ARP等報文將被過濾掉。
高級捕獲條件
在“Advance”頁面下，你可以編輯你的協議捕獲條件，如圖：
高級捕獲條件編輯圖
在協議選擇樹中你可以選擇你需要捕獲的協議條件，如果什麼都不選，則表示忽略該條件，捕獲所有協議。
在捕獲幀長度條件下，你可以捕獲，等於、小於、大於某個值的報文。
在錯誤幀是否捕獲欄，你可以選擇當網絡上有如下錯誤時是否捕獲。
在保存過濾規則條件按鈕“Profiles”，你可以將你當前設置的過濾規則，進行保存，在捕獲主面板中，你可以選擇你保存的捕獲條件。
任意捕獲條件
在Data Pattern下，你可以編輯任意捕獲條件，如下圖：
用這種方法可以實現複雜的報文過濾，但很多時候是得不償失，有時截獲的報文本就不多，還不如自己看看來得快。
第3章 報文放送
3.1 編輯報文發送
Sniffer軟件報文發送功能就比較弱，如下是發送的主面板圖：
發送前，你需要先編輯報文發送的內容。點擊發送報文編輯按鈕。可得到如下的報文編輯窗口：
首先要指定數據幀發送的長度，然後從鏈路層開始，一個一個將報文填充完成，如果是NetXray支持可以解析的協議，從“Decode”頁面中，可看見解析後的直觀表示。
3.2 捕獲編輯報文發送
將捕獲到的報文直接轉換成發送報文，然後修修改改可也。如下是一個捕獲報文後的報文查看窗口：
選中某個捕獲的報文，用鼠標右鍵激活菜單，選擇“Send Current Packet”，這時你就會發現，該報文的內容已經被原封不動的送到“發送編輯窗口”中了。這時，你在修修改改，就比你全部填充報文省事多了。
發送模式有兩種：連續發送和定量發送。可以設置發送間隔，如果爲0，則以最快的速度進行發送。
第4章 網絡監視功能
網絡監視功能能夠時刻監視網絡統計，網絡上資源的利用率，並能夠監視網絡流量的異常狀況，這裏只介紹一下Dashbord和ART，其他功能可以參看在線幫助，或直接使用即可，比較簡單。
4.1 Dashbord
Dashbord可以監控網絡的利用率，流量及錯誤報文等內容。通過應用軟件可以清楚看到此功能。
4.2 Application Response Time (ART)
Application Response Time (ART) 是可以監視TCP/UDP應用層程序在客戶端和服務器響應時間，如HTTP,FTP,DNS等應用。
對與TCP/UDP響應時間的計算方法如下
TCP For each socket, ART stores the sequence numbers for packets sent by the client and waits for the corresponding ACK packets from the server. It then measures the time difference between the packet with the stored sequence number and the packet with the ACK to arrive at the response time.
UDP For each socket, ART measures the time between packets going from a client to a server and the next packet going from the server to the client.
第5章 數據報文解碼詳解
本章主要對：數據報文分層、以太報文結構、IP協議、ARP協議、PPPOE協議、Radius協議等的解碼分析做了簡單的描述，目的在於介紹Sniffer軟件在協議分析中的功能作用並通過解碼分析對協議進一步瞭解。對其其他協議讀者可以通過協議文檔和Sniffer捕獲的報文對比分析。
5.1 數據報文分層
如下圖所示，對於四層網絡結構，其不同層次完成不通功能。每一層次有衆多協議組成。
如上圖所示在Sniffer的解碼錶中分別對每一個層次協議進行解碼分析。鏈路層對應“DLC”；網絡層對應“IP”；傳輸層對應“UDP”；應用層對對應的是“NETB”等高層協議。Sniffer可以針對衆多協議進行詳細結構化解碼分析。並利用樹形結構良好的表現出來。
5.2 以太報文結構
EthernetII以太網幀結構
Ethernet_II以太網幀類型報文結構爲：目的MAC地址（6bytes）＋源MAC地址＋（6bytes）上層協議類型（2bytes）＋數據字段（46-1500bytes)＋校驗（4bytes）。
Sniffer會在捕獲報文的時候自動記錄捕獲的時間，在解碼顯示時顯示出來，在分析問題時提供了很好的時間記錄。
源目的MAC地址在解碼框中可以將前3字節代表廠商的字段翻譯出來，方便定位問題，例如網絡上2臺設備IP地址設置衝突，可以通過解碼翻譯出廠商信息方便的將故障設備找到，如00e0fc爲華爲，010042爲Cisco等等。如果需要查看詳細的MAC地址用鼠標在解碼框中點擊此MAC地址，在下面的表格中會突出顯示該地址的16進制編碼。
IP網絡來說Ethertype字段承載的時上層協議的類型主要包括0x800爲IP協議，0x806爲ARP協議。
IEEE802.3以太網報文結構
上圖爲IEEE802.3SNAP幀結構，與EthernetII不通點是目的和源地址後面的字段代表的不是上層協議類型而是報文長度。並多了LLC子層。
5.3 IP協議
IP報文結構爲IP協議頭＋載荷，其中對IP協議頭部的分析，時分析IP報文的主要內容之一，關於IP報文詳細信息請參考相關資料。這裏給出了IP協議頭部的一個結構。
版本：4——IPv4
首部長度：單位爲4字節，最大60字節
TOS：IP優先級字段
總長度：單位字節，最大65535字節
標識：IP報文標識字段
標誌：佔3比特，只用到低位的兩個比特
MF（More Fragment）
MF=1，後面還有分片的數據包
MF=0，分片數據包的最後一個
DF（Don't Fragment）
DF=1，不允許分片
DF=0，允許分片
段偏移：分片後的分組在原分組中的相對位置，總共13比特，單位爲8字節
壽命：TTL（Time To Live）丟棄TTL=0的報文
協議：攜帶的是何種協議報文
1 ：ICMP
6 ：TCP
17：UDP
89：OSPF
頭部檢驗和：對IP協議首部的校驗和
源IP地址：IP報文的源地址
目的IP地址：IP報文的目的地址
上圖爲Sniffer對IP協議首部的解碼分析結構，和IP首部各個字段相對應，並給出了各個字段值所表示含義的英文解釋。如上圖報文協議（Protocol）字段的編碼爲0x11，通過Sniffer解碼分析轉換爲十進制的17，代表UDP協議。其他字段的解碼含義可以與此類似，只要對協議理解的比較清楚對解碼內容的理解將會變的很容易。
5.4 ARP協議
以下爲ARP報文結構
ARP分組具有如下的一些字段：
HTYPE（硬件類型）。這是一個16比特字段，用來定義運行ARP的網絡的類型。每一個局域網基於其類型被指派給一個整數。例如，以太網是類型1。ARP可使用在任何網絡上。
PTYPE（協議類型）。這是一個16比特字段，用來定義協議的類型。例如，對IPv4協議，這個字段的值是0800。ARP可用於任何高層協議。
HLEN（硬件長度）。這是一個8比特字段，用來定義以字節爲單位的物理地址的長度。例如，對以太網這個值是6。
PLEN（協議長度）。這是一個8比特字段，用來定義以字節爲單位的邏輯地址的長度。例如，對IPv4協議這個值是4。
OPER（操作）。這是一個16比特字段，用來定義分組的類型。已定義了兩種類型：ARP請求（1），ARP回答（2）。
SHA（發送站硬件地址）。這是一個可變長度字段，用來定義發送站的物理地址的長度。例如，對以太網這個字段是6字節長。
SPA（發送站協議地址）。這是一個可變長度字段，用來定義發送站的邏輯（例如，IP）地址的長度。對於IP協議，這個字段是4字節長。
THA（目標硬件地址）。這是一個可變長度字段，用來定義目標的物理地址的長度。例如，對以太網這個字段是6字節長。對於ARP請求報文，這個字段是全0，因爲發送站不知道目標的物理地址。
TPA（目標協議地址）。這是一個可變長度字段，用來定義目標的邏輯地址（例如，IP地址）的長度。對於IPv4協議，這個字段是4字節長。
上面爲通過Sniffer解碼的ARP請求和應答報文的結構。
5.5 PPPOE協議
PPPOE簡介
簡單來說我們可能把PPPOE報文分成兩大塊，一大塊是PPPOE的數據報頭，另一塊則是PPPOE的淨載荷（數據域），對於PPPOE報文數據域中的內容會隨着會話過程的進行而不斷改變。下圖爲PPPOE的報文的格式：
數據報文最開始的4位爲版本域，協議中給出了明確的規定，這個域的內容填充0x01。
緊接在版本域後的4位是類型域，協議中同樣規定，這個域的內容填充爲0x01。
代碼域佔用1個字節，對於PPPOE 的不同階段這個域內的內容也是不一樣的。
會話ID點用2個字節，當訪問集中器還未分配唯一的會話ID給用戶主機的話，則該域內的內容必須填充爲0x0000，一旦主機獲取了會話ID後，那麼在後續的所有報文中該域必須填充那個唯一的會話ID值。
長度域爲2個字節，用來指示PPPOE數據報文中淨載荷的長度。
數據域，有時也稱之爲淨載荷域，在PPPOE的不同階段該域內的數據內容會有很大的不同。在PPPOE的發現階段時，該域內會填充一些Tag（標記）；而在PPPOE的會話階段，該域則攜帶的是PPP的報文。
捕獲報文測試用例圖
如圖所示，Radius Server IP地址爲172.16.20.76。PPPOE用戶Radius報文交互過程分析如下。
上圖爲PPPOE從發現階段到PPP LCP協商，認證IPCP協商階段和PPPOE會話階段交互過程。
PPPOE發現階段，PADI報文，Sniffer解碼結構如下所示。
PPPOE會話階段，Sniffer解碼結構如下所示。
5.6 Radius協議
Radius報文簡介
標準Radius協議包結構
圖9 Radius包格式
Code：包類型；1字節；指示RADIUS包的類型。
1 Access- request 認證請求
2 Access- accept 認證響應
3 Access- reject 認證拒絕
4 Accounting-request 計費請求
5 Accounting-response 計費響應
*11 Access-challenge 認證挑戰
Identifier： 包標識；1字節，取值範圍爲0 ～255；用於匹配請求包和響應包，同一組請求包和響應包的Identifier應相同。
Length： 包長度；2字節；整個包中所有域的長度。
Authenticator：16 字節長；用於驗證RADIUS服務器傳回來的請求以及密碼隱藏算法上。
該驗證字分爲兩種：
1、請求驗證字---Request Authenticator
用在請求報文中,必須爲全局唯一的隨機值。
2、響應驗證字---Response Authenticator
用在響應報文中，用於鑑別響應報文的合法性。
響應驗證字＝MD5(Code+ID+Length+請求驗證字+Attributes+Key)
Attributes：屬性
圖10 屬性格式
屬性域是TLV結構編碼。
測試用例圖
下圖爲用戶端PPPOE，Radius Server和BAS交互的認證上線和下線的過程。
報文1：BAS請求Radius Server認證報文。
報文2：Radius Server迴應BAS認證通過報文。
報文3：BAS計費請求報文。
報文4：Radius Server計費響應報文。
報文5：BAS計費結束報文。
報文6：Radius Server計費結束響應報文。
從中可以看出對於報文請求和響應是通過IP地址+Radius 協議域中ID號進行配對識別的。
上圖顯示了BAS發起的Radius認證請求（Code＝1）報文的結構。Radius報文是承載在UPD協議之上的，這裏我沒不關注上層報文的結構。
下圖爲PPPOE CHAP認證過程的Radius認證請求報文和PPPOE中CHAP認證的Challenge報文。通過比較可以方便看出BAS發出的Challenge值爲“26fe8768341de68a72a1276771e1c1ca”與PPPOE中CHAP認證過程中BAS發給PPPOE用戶的Challenge值是一致的。
下圖爲PPPOE用戶發爲BAS的經過CHAP加密後的用戶密碼和BAS發給Radius Server中認證請求報文用戶祕密屬性域的比較。可以看出在Radius 認證過程中，BAS設備將Challenge屬性和用戶加密後的密碼發給Radius進行驗證。
通過比較可以清楚瞭解協議各字段含義相互關係，爲問題處理提供有效的手段。
下面爲PPPOE用戶Radius認證的Sniffer捕獲的報文。
