1. Debug抓包説明
⇒ Debug抓包前請務必查看設備CPU情況，如當前CPU偏高（參考值：≥50%），請謹慎進行抓包操作，最好選擇在當前設備CPU值偏低、業務低峯期進行Debug，查看設備CPU具體命令：SG-6000# show cpu detail (含歷史CPU)。
⇒ Debug抓包後請務必關閉設備所有已開啓的Debug，防止影響設備CPU等運行情況，關閉Debug方式：
① 命令行下：SG-6000# undebug all。
② 命令行下：長按或者按2下“Esc”鍵，提示 “The debug function for all modules is disabled” 表示所有已開啓的 debug 均已關閉。
StoneOS 數據包(DP) Debug ⇓
IPSecVPN Debug ⇓
其他類型 Debug ⇓
- 系統調試功能可以幫助用户對錯誤進行診斷和定位。安全網關的各種協議和功能基本上都具有相應的調試功能。默認情況下，所有協議和功能的系統調試功能都是關閉的。用户只可以通過設備命令行對系統調試功能進行配置。
- Debug 操作有一定風險，尤其是設備流量大的時候開啓 debug 會導致 CPU 高，請謹慎操作。 請在山石工程師的指導下操作， 不建議用户直接使用 debug。
- 此文中 StoneOS 默認指防火牆。
2. 常見Debug抓包流程
（一）數據包(DP) Debug 抓包流程
a. Debug抓包前建議先了解下StoneOS數據包基礎轉發流程(非二層)：
圖注一：StoneOS數據包基礎轉發流程圖(非二層)
b. StoneOS數據包基礎轉發流程(非二層)具體如下：
-
識別數據包的邏輯入接口，可能是一般無標籤接口，也可能是子接口。從而確定數據包的源安全域。
-
StoneOS 對數據包進行合法性檢查。如果源安全域配置了攻擊防護功能，系統會在這一步同時進行攻擊防護功能檢查。
-
會話查詢。如果該數據包屬於某個已建立會話，則跳過 4 到 10，直接進行第 11 步。
-
目的 NAT（DNAT）操作。如果能夠查找到相匹配的 DNAT 規則，則為包做 DNAT 標記。因為路由查詢需要 DNAT 轉換的 IP 地址，所以先進行 DNAT 操作。
*如果系統配置靜態一對一BNAT規則，那麼先查找匹配的BNAT規則。數據包匹配了BNAT規則之後，按照 BNAT 的設定進行處理，不再查找普通的 DNAT 規則。 -
路由查詢。 StoneOS 的路由查詢順序從前到後依次為：策略路由（PBR） >源接口路由（SIBR） >源路由（SBR） >目的路由（DBR） >ISP 路由。
此時，系統得到了數據包的邏輯出接口和目的安全域。 -
源 NAT（SNAT）操作。如果能夠查找到相匹配的 SNAT 規則，則為包做 SNAT 標記。 *如果系統配置靜態一對一 BNAT 規則，那麼先查找匹配的 BNAT 規則。 數據包匹配了 BNAT規則之後，按照 BNAT 的設定進行處理，不再查找普通的 DNAT 規則。
-
下一跳 VR 查詢。如果下一跳為 VR，則繼續查看指定的下一跳 VR 是否超出最大 VR 數限制（當前版本系統僅允許數據包最多通過 3 個 VR），如果超過則丟棄數據包，如果未超過，返回 4；如果下一跳不是 VR，則繼續進行下一步策略查詢。
-
安全策略查詢。系統根據數據包的源安全域、目的安全域、源 IP 地址和端口號、目的 IP 地址和端口號以及協議，查找策略規則。如果找不到匹配的策略規則，則丟棄數據包；如果找到匹配的策略規則，則根據規則指定的行為進行處理，分別是：
· 允許（Permit）：允許數據包通過。
· 拒絕（Deny）：拒絕數據包通過。
· 隧道（Tunnel）：將數據包轉發到指定的隧道。
· 是否來自隧道（Fromtunnel）：檢查數據包是否來自指定的隧道，如果是，則允許通過，如果不是，則丟棄。
· Web 認證（WebAuth）： 對符合條件的流量進行 Web 認證。 -
第一次應用類型識別。系統根據策略規則中配置的端口號和服務，嘗試識別應用類型。
-
會話建立。
-
如果需要，進行第二次應用類型識別。根據數據包的內容和流量行為再次對應用類型進行精確識別。
-
應用層行為控制。根據確定的應用類型，系統將在此執行配置的 Profile 和 ALG 功能。
-
根據會話中記錄的信息，例如 NAT 標記等，執行相應的處理操作。
-
將數據包轉發到出接口。
c. 舉例説明：
圖注二：StoneOS實際Debug數據包轉發流程（一）
圖注三：StoneOS實際Debug數據包轉發流程（二）
Top⇑
d. Debug操作步驟
【以下紅色部分為一般debug操作步驟(必須)】
SG-6000# show cpu detail //查看設備當前CPU情況（如偏高，不建議debug）
SG-6000(config)# logging debug on //打開 debug log
SG-6000(config)# logging debug to buffer //記錄 log 到 buffer
SG-6000(config)# no logging debug to console //不記錄 log 到 console
SG-6000# debug dp filter src-ip x.x.x.x src-port xx dst-ip x.x.x.x dst-port xx proto xxx //設置debug過濾條件 源IP 源端口 目的IP 目的端口 協議（可任選其中一項或多項作為debug過濾條件）
注：關於debug過濾條件説明，如果調試過程中需要查看雙向數據包，即來回數據包轉發情況，需要設置兩條debug過濾條件，如常見情況第一條源目地址、端口為發送數據包方向，第二條源目地址、端口反過來寫即為反向數據包(回包)，當然特殊情況下請以實際環境問題為準。
例一：抓ICMP 協議ping包 SG-6000# debug dp filter src-ip 192.168.1.1 dst-ip 192.168.100.233 proto icmp //抓包內容限制源目地址、協議
例二：只抓ip地址報文 SG-6000# debug dp filter dst-ip 192.168.100.233 )
SG-6000# show dp filter 或 show dp-filter //查看已設置的debug過濾條件（建議設置完過濾條件後，即查看已設置過濾條件，防止因debug過濾條件誤設導致抓包出錯）
SG-6000# undebug dp filter id xx //清除已設置的debug過濾條件
SG-6000# debug dp basic //debug 開關，查看數據包基本處理流程（務必先執行第一條過濾命令，否則debug所有數據包會造成CPU高或卡死）
SG-6000# debug dp snoop //查看StoneOS數據層轉發基本信息（該功能可以看到數據包頭部的信息，比如TCP 頭部SYN/ACK/FIN/RST 等標誌，序列號，二層MAC 地址等等。）
SG-6000# debug dp drop //查看StoneOS數據層丟棄基本信息
SG-6000# debug dp error //查看StoneOS錯誤的數據包
SG-6000# debug self //查看StoneOS自身數據包轉發情況
SG-6000# show debug //查看已開啓的debug功能（建議設置完debug功能後，即查看已開啓的debug功能，防止因debug功能誤設導致抓包出錯）
SG-6000# clear logging debug //清除debug緩存
清除debug緩存後，立馬進行故障節點訪問，即觸發數據流，以便在防火牆抓取相應數據包轉發信息（若防火牆抓不到相應數據包，如提示“Info: There is no logging message”，則表示相應流量可能沒到達防火牆，或者debug過濾條件、功能開關有誤，請以實際情況為準，並進行檢查）
SG-6000# show logging debug //查看debug輸出信息，即StoneOS數據包轉發情況
SG-6000# show logging debug | {include|begin|begin2|exclude|redirect} Packet/Drop/RST/err等 //可通過管道符“|”來過濾目標信息，如“SG-6000#show logging debug | include Packet”可直接查看數據包來回轉發情況。
注：如需要記錄相應debug輸出信息，請使用帶有“記錄日誌”功能的命令行軟件，具體請參考其軟件使用説明。
SG-6000# undebug all //抓包完畢，關閉debug功能（長按或者按2下“Esc”鍵也可）
注意：使用Debug請注意設備CPU使用情況和所抓取報文的數據量，不可以在沒有過濾條件的情況下進行Debug。e. 常見Debug故障調試信息示例(StoneOS數據包)
① “No policy matches, default ===DENY===”
沒有能匹配上的策略，需要確認策略配置是否正常。
“policy id xx matches: ===DENY===”
匹配上了拒絕策略，需要確認策略配置是否正常。
② “Policy xx matches, ===OUTTUNNEL===
Dropped: Can't find policy/policy denied. Abort!!”
匹配上 VPN 策略，但走了錯誤的隧道，需要檢查是否開啓了 check-id。
③ “flow0's tunnel id (0) invalid.
Dropped: Failed to create session”
需要檢查 VPN 配置，常見原因為隧道接口綁定 VPN 實例時配置的網關與路由配置的網關不一致（或一個配置了另一個未配置）。
④ “The to-self service is not registered”
不應該發到防火牆自身的報文被 drop，需要確認配置是否正常（例如 DNAT 沒有成功匹配等）。
⑤ “Chash insert fail
Failed to install the following session”
會話衝突導致會話創建失敗，建議查詢已有會話 flow 看是否存在衝突情況， 常見原因如需要創建會話的 flow0 和已有會話的 flow1 相同， zone 也相同時，就會衝突。
⑥ “Dropped: Arp get fail”
ARP 信息獲取失敗，需要進一步排查 ARP 報文的收發情況，可能需結合鏡像抓包等方式排查。如果顯示的是 Arp get fail, ip:0.0.0.0，説明可能是由於同一應用不同端口設備收到報文的源 MAC 不同等原因，需要重新請求 ARP，而接口又關閉了逆向路由導致，可嘗試開啓逆向路由測試。
⑦ “Dropped: Dst mac is not interface's mac, drop packet”
目的 MAC 非接口 MAC 而被 drop，需要先確認報文是否為相關報文。如果是，那麼需要排查上聯設備的 ARP 學習情況，本端視情況可開啓免費 ARP 再測試。
⑧ “Dropped: Address spoof detected!!
Dropped: No reverse route, drop the packet”
字面意思為檢測到地址欺騙 drop 報文，常見於查詢逆向路由時查找到的回包出接口與正向報文入接口不在同一安全域，此時 debug 就會看到這樣的信息。需要檢查配置文件確認路由配置是否正常。一般關閉逆向路由可規避，但關閉逆向路由可能造成其他問題，需要結合用户實際需求給出最優建議。
“Get the reverse route: out interface's zone is not the zone of i_if of packet,drop the packet
Dropped: No reverse route, drop the packet”
此 debug 信息與上面類似，常見原因大體相同，需要檢查配置文件。
⑨ “Hit invalid session, drop packet”
報文五元組命中了被拆除的會話被 drop，通常是由於之前有會話被拆除後還未經過 3 秒老化時間。
⑩ “Dropped: TCP 1st packet should not be RST or FIN”
TCP 首包不能為 RST 或 FIN 包，關閉相關檢查可以規避。
⑪ “There is not enough resource
Dropped: SNAT error, dropped”
SNAT 資源不足，需要檢查 SNAT 資源狀態，對於開啓了端口擴展的情況，需要確認是否有pool 資源已用完。
⑫ “Dropped: The interface of dst mac is same as the src if”
目的 MAC 對應的出接口與入接口一致，一般發生在透明模式環境中，設備認為該報文不應該被轉發到設備因此丟棄，需要結合客户拓撲看是否正常。
⑬ “Received unreachable embedded icmp, invalidate sesstion”
設備接收到 ICMP 不可達報文並拆除了會話，可能導致後續業務報文被 drop，配置 icmpunreachable-session-keep 可規避。
⑭ “Dropped: TTL is too small”
TTL 過低，可能是設備收到報文的 TTL 就已經是 1，也可能是存在環路，需要結合拓撲及完整 debug 分析。
⑮ “iQoS process: QoS engine first pipe xxx（管道名） enqueue pak failed, drop it”
報文被 iQoS 阻斷。
⑯ “block pak for session xxxx（session ID） new app-id xxx（應用名）”
由於應用識別功能識別出流量實際應用，應用發生變化， session rematch 時匹配到拒絕策略/默認拒絕動作導致報文被 drop。
Top⇑
（二）IPSecVPN Debug抓包流程
在開始IPSecVPN Debug前先了解下IPSec相關知識及交互過程。
a. IPSec基礎介紹
IPSec定義：（英語：Internet Protocol Security，縮寫為IPsec），是一個協議包，通過對IP協議的分組進行加密和認證來保護IP協議的網絡傳輸協議族（一些相互關聯的協議的集合）。
- IPSec對等體
IPSec 用於在兩個端點之間提供安全的 IP 通信，通信的兩個端點被稱為 IPSec 對等體。 - 安全聯盟
SA（Security Association）安全聯盟是要建立IPSec隧道的通信雙方對隧道參數的約定，包括隧道兩端的IP地址、隧道採用的驗證方式、驗證算法、驗證密鑰、加密算法、加密密鑰、共享密鑰以及生存週期等一系列參數。
SA 是單向的，在兩個對等體之間的雙向通信，至少需要兩個 SA。SA 由一個三元組來唯一標識，這個三元組包括安全參數索引 SPI（Security Parameter Index）、目的 IP 地址、安全協議名（AH 或 ESP）。 - 協商方式
建立 SA 的方式有以下兩種：
手工方式（manual）：建立安全聯盟比較複雜，安全聯盟所需的全部信息都必須手工配置。但優點是可以不依賴 IKE 而單獨實現 IPSec 功能。
IKE 動態協商（isakmp）方式：建立安全聯盟相對簡單些，只需要通信對等體間配置好 IKE協商參數，由 IKE 自動協商來創建和維護 SA。 - IPSec封裝模式
圖注四：IPSec協議封裝包
隧道模式。在隧道模式下，AH 或 ESP 插在原始 IP 頭之前，另外生成一個新 IP 頭放到 AH或 ESP 之前。
圖注五：隧道模式示意圖
傳輸模式。在傳輸模式下，AH 或 ESP 被插入到 IP 頭之後但在傳輸層協議之前。
圖注六：傳輸模式示意圖
隧道模式生成新的包頭安全性比傳輸模式高，但隧道模式比傳輸模式佔用帶寬更多。
- IPSec使用的認證算法和加密算法
認證算法IPSec可以使用三種認證算法：
MD5（Message Digest 5）：MD5 通過輸入任意長度的消息，產生 128bit 的消息摘要。
SHA-1（Secure Hash Algorithm）：SHA-1 通過輸入長度小於 2 的 64 次方比特的消息，產生 160bit 的消息摘要。
SHA-2：SHA-2 算法相對於 SHA-1 加密數據位數有所上升，安全性能要遠遠高於SHA-1。
加密算法
加密算法實現主要通過對稱密鑰系統，它使用相同的密鑰對數據進行加密和解密。
IPSec使用以下三種加密算法：
DES：使用 56bit 的密鑰對一個 64bit 的明文塊進行加密。
3DES：使用三個 56bit 的 DES 密鑰（共 168bit 密鑰）對明文進行加密。
AES：使用 128bit、192bit 或 256bit 密鑰長度的 AES 算法對明文進行加密。
- 通信保護協議
AH認證頭協議：
協議號51。
定義於RFC 2402。
鑑別頭AH：（不提供保密性，只對整個IP數據包提供保護）。
無連接數據完整性：通過哈希函數產生的校驗來保證。
數據源認證：通過計算驗證碼時加入一個共享密鑰來實現。
抗重放服務：AH報頭中的隨機序列號可以防止重放攻擊。
可以用於隧道和傳輸兩種模式中。
使用MD5/SHA-1。
提供如下的功能：
數據完整性；
數據源認證；
Anti-replay服務。
圖注七：Tunnel模式下的AH包
ESP封裝安全載荷協議：
協議號50。
定義於RFC 2406。
除提供 AH 認證頭協議的所有功能之外，還有數據保密和有限的數據流保護，ESP 協議允許對 IP 報文淨荷進行加密和認證、只加密或者只認證，ESP 沒有對 IP頭的內容進行保護。
保密服務通過使用密碼算法加密 IP 數據包的相關部分來實現。
數據流保密由隧道模式下的保密服務提供。
ESP通常使用DES、3DES、AES等加密算法實現數據加密，使用MD5或SHA1來實現數據完整性認證。
AH認證頭協議，無法在穿越NAT的時候使用，因為AH協議會對IP包頭進行校驗。ESP協議可以。
可以用於隧道和傳輸兩種模式中。
提供如下的功能：
數據完整性；
數據保密性；
數據源認證；
Anti-replay服務。
圖注八：Tunnel模式下的ESP包
- IPsec提供了兩種安全機制：認證和加密
認證機制使 IP 通信的數據接收方能夠確認數據發送方的真實身份以及數據在傳輸過程中是否遭篡改。
加密機制通過對數據進行加密運算來保證數據的機密性，以防數據在傳輸過程中被竊聽。
b.1 IPSecVPN協商過程
圖注九：IPSecVPN協商過程圖解
b.2 主模式與野蠻模式對比
IKEv1建立IKESA的過程定義了主模式（Main Mode）和野蠻模式（Aggressive Mode）兩種交換模式。
主模式包含三次雙向交換，用到了六條信息：
消息①和②用於協商算法；
消息③和④用於密鑰信息交換，DH算法；
消息⑤和⑥用於身份和認證信息交換。
野蠻模式只用到三條信息：
前兩條消息①和②用於協商提議，消息③用於響應方認證發起方。
圖注十：主模式與野蠻模式報文對比
野蠻模式協商比主模式協商更快。主模式需要交互6個消息，野蠻模式只需要交互3個消息。
主模式協商比野蠻模式協商更嚴謹、更安全。因為主模式在5、6個消息中對ID信息進行了加密。而野蠻模式受到交換次數的限制，ID信息在1、2個消息中以明文的方式發送給對端。即主模式對對端身份進行了保護，而野蠻模式則沒有。
兩種模式在確定預共享的方式不同。主模式只能基於IP地址來確定預共享密鑰。而野蠻模式是基於ID信息（主機名和IP地址）來確定預共享密鑰。
c.1 IPSecVPN協商過程(主模式)
【第一階段】
（1）主模式包交換解析(第一組報文)
第一階段第一組報文1和2的主要任務：
加密算法
散列算法
DH組
認證方式
密鑰有效期
完成以上內容的協商
注意：第一階段協商的策略不是真正用來加密兩端互通的私網流量的策略，只用在第一階段後面兩組報文的使用上和第二階段的協商過程中，第二階段重新協商的策略才是真正加密流量的。
ISAKMP數據包通過UDP傳輸的，源目端口都是500。穿越NAT時用UDP 4500。
（2）主模式包交換解析(第二組報文)
IKE Phase 1 (Main Mode): Sending Message 3 and 4兩部分內容要互相交換：Key Exchange和Nonce Payload：
Key exchange data是雙方共同要告訴對方的。
Nonce(隨機產生非常大的數字)是雙方接下來驗證需要的原材料之一。第二組的主要任務就是要交換雙方的共享信息，產生一個密鑰。
（3）主模式包交換解析(第三組報文)
預共享密鑰認證：
IKE Phase 1(Main Mode): Sending Message 5
把Hash_l通過SKEYID_e進加密發送
IKE Phase 1 (Main Mode): Sending Message 6
把Hash_R通過SKEYID_e進加密發送
最後一組發送完畢後，使用SKEYID_e解密對方發送的數據，裏面有原始數據ID_R和哈希值Hash_R，使用接收到的ID_R按照PRFE函數進行哈希，比較接收到的哈希值和自己產生的哈希值是否相等。
Hash_R ? = Self Hash_R
相等即可建立ISAKMP SA，IKE第一階段完成。
【第二階段】
（1）第1個包：
在IKE SA協商基礎上形成新的KEY；
封裝方式：AH、ESP；
加密方式：DES、3DES、AES...；
完整性算法：MD5、SHA-1；
IPSEC SA：默認1個小時；
兩端保護子網。
（2）第2個包：包主要是接收端查看本地有沒有一個IPSec SA策略與發起方的一樣，如果有，並且認證成功，感興趣流協商成功，那麼接收端會把協商成功的IPSec SA策略發給發起端，同時也會把自己的認證KEY發給發啓端來進行雙向認證。
（3）第3個包：包主要是發起端對接收端發來的第二個包進行確認，協商成功進行業務訪問。
c.2 IPSecVPN協商過程(野蠻模式)
野蠻模式同樣包含三個步驟，但僅通過三個包進行傳輸，標示為aggressive 野蠻模式的三個包交換：
第1個交互包發起方建議SA，發起DH交換；
第2個交互包接收方接收SA；
第3個交互包發起方認證接收方，野蠻模式前兩個報文是明文，第三個報文是密文。
d. IPSecVPN高級設置
d.1 IPSecVPN中NAT穿越(NAT-T)
在非NAT環境中，IPSec協商使用UDP 500端口進行協商。而VPN設備（私網出口地址)如果在NAT設備內部，NAT不會對ESP進行端口轉換，此時需要NAT-T技術在ESP封裝和外層IP報頭之間插入8個字節的UDP報頭，端口號為UDP 4500。
d.2 IPSecVPN Proxy-ID
Proxy ID（代理ID，即感興趣流）用於在兩個VPN端對端間交換策略，代表着需要獲得安全服務的數據包，通常指兩端內網地址，定義的地址必須對稱。
若無填寫，採用策略模式則需要在創建策略時填寫對稱的地址，即本地的源地址子網與對端的目的地址子網相同。
Proxy ID 常用於本端 Hillstone，對端第三方設備的場景。
Proxy ID 錯誤配置是 VPN 建立最常見的錯誤。
Top⇑
e. Debug操作步驟
【以下紅色部分為一般debug操作步驟(必須)】
SG-6000# show cpu detail //查看設備當前CPU情況（如偏高，不建議debug）
SG-6000# show isakmp peer <一階段名稱> //查看IPSecVPN一階段配置信息
SG-6000# show tunnel ipsec auto <二階段名稱> //查看IPSecVPN二階段配置信息
SG-6000# debug vpn filter ip x.x.x.x //設置 debug vpn 過濾條件，此ip為IPSec對端出口/公網地址，建議配置，以便精準抓取報文
SG-6000# show vpn-filter //查看已設置的 debug vpn 過濾條件
SG-6000# undebug vpn filter ip x.x.x.x //清除已設置的debug vpn 過濾條件
SG-6000# debug vpn //開啓 debug vpn 功能
SG-6000# show isakmp sa //查看IPSec一階段協商結果
SG-6000# show ipsec sa //查看IPSec二階段協商結果
SG-6000# clear ipsec sa <id> //清除IPSec二階段協商結果，以重新協商並觸發流量，若存在多條IPSec情況下，請設置對應SA id
SG-6000# clear isakmp sa <ip> //清除IPSec一階段協商結果，以重新協商並觸發流量，若存在多條IPSec情況下，請設置IPSec對端出口/公網地址
注：可查看相關IPSec會話（show session <源目地址，源目端口一般為500或4500>），必要時可清除相應會話，待IPSec重新發起協商時再建立會話。
SG-6000# clear logging debug //清除debug緩存
SG-6000# show logging debug //查看debug輸出信息，即IPSecVPN協商過程
SG-6000# undebug all //抓包完畢，關閉debug功能（長按或者按2下“Esc”鍵也可）f. 常見IPSecVPN Debug故障調試信息示例
① “invalid payload or failed to malloc buffer（pre-share key may mismatch）”
預共享密鑰不一致，建議重新配置預共享密鑰。
② “failed to get sainfo”
最常見原因為階段二代理 ID 配置不一致，建議檢查兩端配置，如果有多對代理 ID，需要分別對應。
③ “HASH(1) mismatch”
HASH 算法， HMAC 密鑰或協商包載荷信息不一致，檢查配置後仍有此報錯，需提交研發詳細分析。
④ “No suitable proposals found”
兩端 proposal 不一致，需要對比兩端配置。
⑤ “DPD: remote peer xxxx（對端 IP 和端口） seems to be dead”
dpd 超時，需要排查兩端出口其他設備轉發是否正常，如果確認無問題，可能為運營商問題。
⑥ “phase 1 (aggressive mode): gateway ceshi can work as initiator only”
雙方都是發起段可能出現這個報錯。
更多 IPSecVPN Debug 故障調試報錯信息請見《IPSecVPN Debug(抓包)故障調試彙總》
説明：以上為IPSecVPN隧道協商過程的Debug操作，若IPSec隧道建立成功，但兩端內網數據無法通信，可進行數據包（DP）Debug，具體請見前段內容數據包Debug部分。
更多Hillstone debug類型操作步驟和注意事項請見：https://kb.hillstonenet.com/c...
