山石网科Hillstone Debug(抓包)故障调试指南

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数据包基础转发流程(非二层)具体如下：

1. 识别数据包的逻辑入接口，可能是一般无标签接口，也可能是子接口。从而确定数据包的源安全域。
2. StoneOS 对数据包进行合法性检查。如果源安全域配置了攻击防护功能，系统会在这一步同时进行攻击防护功能检查。
3. 会话查询。如果该数据包属于某个已建立会话，则跳过 4 到 10，直接进行第 11 步。
4. 目的 NAT（DNAT）操作。如果能够查找到相匹配的 DNAT 规则，则为包做 DNAT 标记。因为路由查询需要 DNAT 转换的 IP 地址，所以先进行 DNAT 操作。
   *如果系统配置静态一对一BNAT规则，那么先查找匹配的BNAT规则。数据包匹配了BNAT规则之后，按照 BNAT 的设定进行处理，不再查找普通的 DNAT 规则。
5. 路由查询。 StoneOS 的路由查询顺序从前到后依次为：策略路由（PBR） >源接口路由（SIBR） >源路由（SBR） >目的路由（DBR） >ISP 路由。
   此时，系统得到了数据包的逻辑出接口和目的安全域。
6. 源 NAT（SNAT）操作。如果能够查找到相匹配的 SNAT 规则，则为包做 SNAT 标记。 *如果系统配置静态一对一 BNAT 规则，那么先查找匹配的 BNAT 规则。 数据包匹配了 BNAT规则之后，按照 BNAT 的设定进行处理，不再查找普通的 DNAT 规则。
7. 下一跳 VR 查询。如果下一跳为 VR，则继续查看指定的下一跳 VR 是否超出最大 VR 数限制（当前版本系统仅允许数据包最多通过 3 个 VR），如果超过则丢弃数据包，如果未超过，返回 4；如果下一跳不是 VR，则继续进行下一步策略查询。
8. 安全策略查询。系统根据数据包的源安全域、目的安全域、源 IP 地址和端口号、目的 IP 地址和端口号以及协议，查找策略规则。如果找不到匹配的策略规则，则丢弃数据包；如果找到匹配的策略规则，则根据规则指定的行为进行处理，分别是：
   · 允许（Permit）：允许数据包通过。
   · 拒绝（Deny）：拒绝数据包通过。
   · 隧道（Tunnel）：将数据包转发到指定的隧道。
   · 是否来自隧道（Fromtunnel）：检查数据包是否来自指定的隧道，如果是，则允许通过，如果不是，则丢弃。
   · Web 认证（WebAuth）： 对符合条件的流量进行 Web 认证。
9. 第一次应用类型识别。系统根据策略规则中配置的端口号和服务，尝试识别应用类型。
10. 会话建立。
11. 如果需要，进行第二次应用类型识别。根据数据包的内容和流量行为再次对应用类型进行精确识别。
12. 应用层行为控制。根据确定的应用类型，系统将在此执行配置的 Profile 和 ALG 功能。
13. 根据会话中记录的信息，例如 NAT 标记等，执行相应的处理操作。
14. 将数据包转发到出接口。

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协议的网络传输协议族（一些相互关联的协议的集合）。

1. IPSec对等体

• IPSec 用于在两个端点之间提供安全的 IP 通信，通信的两个端点被称为 IPSec 对等体。

2. 安全联盟

• SA（Security Association）安全联盟是要建立IPSec隧道的通信双方对隧道参数的约定，包括隧道两端的IP地址、隧道采用的验证方式、验证算法、验证密钥、加密算法、加密密钥、共享密钥以及生存周期等一系列参数。
• SA 是单向的，在两个对等体之间的双向通信，至少需要两个 SA。SA 由一个三元组来唯一标识，这个三元组包括安全参数索引 SPI（Security Parameter Index）、目的 IP 地址、安全协议名（AH 或 ESP）。

3. 协商方式

建立 SA 的方式有以下两种：

• 手工方式（manual）：建立安全联盟比较复杂，安全联盟所需的全部信息都必须手工配置。但优点是可以不依赖 IKE 而单独实现 IPSec 功能。
• IKE 动态协商（isakmp）方式：建立安全联盟相对简单些，只需要通信对等体间配置好 IKE协商参数，由 IKE 自动协商来创建和维护 SA。

4. IPSec封装模式

图注四：IPSec协议封装包

• 隧道模式。在隧道模式下，AH 或 ESP 插在原始 IP 头之前，另外生成一个新 IP 头放到 AH或 ESP 之前。

图注五：隧道模式示意图

• 传输模式。在传输模式下，AH 或 ESP 被插入到 IP 头之后但在传输层协议之前。

图注六：传输模式示意图

• 隧道模式生成新的包头安全性比传输模式高，但隧道模式比传输模式占用带宽更多。

5. 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 算法对明文进行加密。

6. 通信保护协议

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包

7. 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部分。

Top⇑

☛ 更多防火墙安全网关其他类型Debug抓包及配置和常见问题 ☚