第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進行驗證。
通過比較可以清楚了解協定各字段含義互相關系，為問題處理提供有效的手段。