⇒ Debug抓包前请务必查看设备CPU情况,如当前CPU偏高,请谨慎进行抓包操作,最好选择在当前设备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 ⇓
1. 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数据包转发流程(二)
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数据层转发基本信息
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。
(二)IPSecVPN Debug抓包流程
在开始IPSecVPN Debug前先了解下IPSec相关知识及交互过程。
a. IPSec基础介绍
IPSec定义:(英语:Internet Protocol Security,缩写为IPsec),是一个协议包,通过对IP协议的分组进行加密和认证来保护IP协议的网络传输协议族(一些相互关联的协议的集合)。
1. IPSec对等体
IPSec 用于在两个端点之间提供安全的 IP 通信,通信的两个端点被称为 IPSec 对等体。
2. 安全联盟
SA(Security Association)安全联盟定义了 IPSec 通信对等体间将使用哪种摘要和加密算法、什么样的密钥进行数据的安全转换和传输。SA 是单向的,在两个对等体之间的双向通信,至少需要两个 SA。SA 由一个三元组来唯一标识,这个三元组包括安全参数索引 SPI(Security Parameter Index)、目的 IP 地址、安全协议名(AH 或 ESP)。
3. 协商方式
建立 SA 的方式有以下两种:
- 手工方式(manual):建立安全联盟比较复杂,安全联盟所需的全部信息都必须手工配置。但优点是可以不依赖 IKE 而单独实现 IPSec 功能。
- IKE 动态协商(isakmp)方式:建立安全联盟相对简单些,只需要通信对等体间配置好 IKE协商参数,由 IKE 自动协商来创建和维护 SA。
4. 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认证头协议:
- 鉴别头AH:(不提供保密性,只对整个IP数据包提供保护)。
- 无连接数据完整性:通过哈希函数产生的校验来保证。
- 数据源认证:通过计算验证码时加入一个共享密钥来实现。
- 抗重放服务:AH报头中的随机序列号可以防止重放攻击。
ESP封装安全载荷协议:
- 除提供 AH 认证头协议的所有功能之外,还有数据保密和有限的数据流保护,ESP 协议允许对 IP 报文净荷进行加密和认证、只加密或者只认证,ESP 没有对 IP头的内容进行保护。
- 保密服务通过使用密码算法加密 IP 数据包的相关部分来实现。
- 数据流保密由隧道模式下的保密服务提供。
- ESP通常使用DES、3DES、AES等加密算法实现数据加密,使用MD5或SHA1来实现数据完整性认证。
- AH认证头协议,无法在穿越NAT的时候使用,因为AH协议会对IP包头进行校验。ESP协议可以。
7. IPsec提供了两种安全机制:认证和加密
- 认证机制使 IP 通信的数据接收方能够确认数据发送方的真实身份以及数据在传输过程中是否遭篡改。
- 加密机制通过对数据进行加密运算来保证数据的机密性,以防数据在传输过程中被窃听。
b. IPSecVPN协商过程
图注四:IPSecVPN协商过程图解
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第一阶段完成
【第二阶段】
- 在IKE SA协商基础上形成新的KEY;
- 封装方式:AH、ESP;
- 加密方式:DES、3DES、AES…;
- 完整性算法:MD5、SHA-1;
- IPSEC SA:默认1个小时;
- 两端保护子网。
c.2 IPSecVPN协商过程(野蛮模式)
野蛮模式同样包含三个步骤,但仅通过三个包进行传输,标示为aggressive 野蛮模式的三个包交换:
- 第1个交互包发起方建议SA,发起DH交换;
- 第2个交互包接收方接收SA;
- 第3个交互包发起方认证接收方,野蛮模式前两个报文是明文,第三个报文是密文。
d. 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”键也可)
e. 常见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部分。
3. 其他类型Debug操作简要介绍
⇒以下仅列出Debug关键调试步骤,具体需要注意的事项请参考数据和IPSecVPN Debug部分内容。
⇒该部分内容需谨慎使用,请在山石工程师的指导下操作, 不建议用户直接使用 Debug。
(一)StoneOS Route 排障调试
SG-6000# debug dp route //开启 route debug 功能
SG-6000# show logging debug //查看debug调试输出信息
(二)StoneOS NAT 排障调试
SG-6000# show snat resource //查看设备当前 NAT 资源占用率
SG-6000# show dnat server //查看设备当前监控的 server 状态
SG-6000# show session src-ip / dst-ip //查看 NAT 转换地址是否正确
SG-6000# debug dp nat //开启NAT debug 功能
SG-6000# show logging debug //查看debug调试输出信息
(三)StoneOS Policy 排障调试
SG-6000# show policy all //显示设备中所有的安全策略(包括WebUI上添加的NBC策略)
SG-6000# show policy hit-count //查看Policy命中计数
SG-6000# debug dp policy lookup //查看当前流量所匹配的策略ID
SG-6000# show logging debug //查看debug调试输出信息
(四)StoneOS DHCP 排障调试
SG-6000# show dhcp-server pool //查看配置的 DHCP 地址池
SG-6000# show dhcp-server statistics //查看 DHCP 接收和发送报文
SG-6000# show dhcp-server binding //查看 DHCP client 分配的 IP、 MAC 和租约情况
SG-6000# show logging event //查看 DHCP 地址分配的日志
SG-6000# debug dhcpd server //查看 dhcp server 的 debug 信息
SG-6000# debug dhcpd relay //查看 dhcp-relay 的 debug 信息
SG-6000# show logging debug //查看debug调试输出信息
(五)StoneOS AAA、Web-Auth、SNMP、LDAP 排障调试
SG-6000# show auth-user //查看已认证的用户
SG-6000# show aaa-server //查看已配置的 AAA server
SG-6000# show user aaa-server //查看某个具体 AAA server 上同步或配置的用户
SG-6000# show webauth //查看那 web-auth 的配置
SG-6000# show snmp-server //查看 SNMP 的配置
SG-6000# debug aaa //查看 local、 radius 和 ldap 认证时的 debug 信息
SG-6000# debug webauth //查看 webauth debug 信息
SG-6000# debug snmpd //查看 snmp 进程收发包情况
SG-6000# show logging debug //查看debug调试输出信息
注:
1. 如果网管软件无法通过 SNMP 监控设备,那么先尝试用 mibbrowser 连接防火墙并读取信息。
2. 如果设备无法通过 LDAP 读取 windows AD 上的用户,那么先尝试用 ldapbrowser 。
(六)StoneOS HA 排障调试
SG-6000# show version //查看两台HA设备版本、硬件型号和license一致
SG-6000# show ha group 0 //查看HA主备Group信息
SG-6000# show ha link status //查看HA心跳线信息
SG-6000# show ha flow statistics //查看HA主备包转发情况
SG-6000# show ha protocol statistic //查看两台HA设备心跳包接受和发送情况
SG-6000# show ha sync statistic //查看HA设备同步情况
SG-6000# show interface //查看HA接口MAC是否为VMAC
SG-6000# show ha cluster //查看两台设备的HA cluster是否一致
SG-6000# show session generic //查看session同步状况(在两台设备上同时执行并进行对比)
SG-6000# debug ha //查看HA状态机、协商情况和文件同步情况
SG-6000# show logging debug //查看debug调试输出信息
注:
1. 查看上下游交换机或路由器的MAC和端口学习情况。
2. 抓包分析免费ARP的发送情况。
(七)StoneOS SCVPN 排障调试
【Client端软件】
- 通过https访问防火墙的管理接口的4433端口(可配),通过认证后,点击客户端软件下载,点击连接触发启动客户端软件并进行scvpn连接。
【Server(防火墙)端】
- 接受客户端连接;
- 为客户端分配IP地址、DNS 服务器地址和WINS服务器地址;
- 进行客户端用户的认证与授权;
- 进行客户端主机的安全检测;
- 对IPSec数据进行加密与转发。
Control Plane(控制连接)
- 采用标准ssl连接,使用私有协议格式进行tunnel相关参数协商,认证数据交互等。
Data Plane(数据转发)
- 采用Ipsec tunnel进行数据加/解密,(解)封装,keepalive。
SCVPN的数据通道固定采用IPSec Tunnel模式,封装数据采用ESP,而且必定Over NATT(默认4433通过CLI“scvpn-udp-port port-number”可配)。
SG-6000# show tunnel scvpn [scvpn-instance-name] //显示SCVPN实例信息
SG-6000# show scvpn session <name> //查看https访问防火墙的状态信息
SG-6000# show scvpn client <scvpn name> user <username> //查看某user拨入信息
SG-6000# show auth-user //查看scvpn是否已经通过了认证阶段
SG-6000# show session tunnel //查看是否生成IPSec数据tunnel session
获取更多信息打开以下debug:
SG-6000# debug scvpn {error|event|filter|packet|per-ip|timers} //CP中SCVPN协商控制信息,建议逐项开启
SG-6000# debug scvpn filter //设置SCVPN过滤条件,若此开关无意打开或IP设置不对,可能导致会丢掉大量信息,通过“show sslvpn-filter”可查看
SG-6000# debug dp tunnel //DP中tunnel数据信息
SG-6000# debug dp ipsec //DP中IPSsec数据信息
SG-6000# show logging debug //查看debug调试输出信息
如果以上信息不能发现问题,需要抓取更多flow的信息:
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过滤条件)
SG-6000# debug dp basic //debug 开关,查看数据包基本处理流程(务必先执行第一条过滤命令,否则debug所有数据包会造成CPU高或卡死)
SG-6000# debug dp snoop //查看StoneOS数据层转发基本信息
SG-6000# debug self //查看StoneOS自身数据包转发情况
SG-6000# show logging debug //查看debug调试输出信息
注意:推荐开启” debug dp basic+self+filter”,但dp basic信息在实际网络环境下会比较多,一定要看是否我们关心的有用信息被冲掉,注意dp filter的设置,设置不当会导致抓不到我们关心的信息,最好抓取一份不包含”dp basic+self+filter”的基本VPN相关debug信息,一份两者都有的。
(八)StoneOS L2TP 排障调试
SG-6000# show tunnel l2tp <name> //查看L2TP配置信息
SG-6000# show l2tp tunnel <name> //查看L2TP网络服务器tunnel创建信息
SG-6000# show l2tp client tunnel-name <name> [<cr>, user <name>] //查看L2TP在线用户拨入信息
SG-6000# show l2tp pool <name> statistics //查看CP L2TP address pool的使用情况
SG-6000# show session tunnel //查看L2TP tunnel session信息
SG-6000# debug L2TP //CP协商信息
SG-6000# debug dp l2tp //DP信息
SG-6000# debug dp tunnel //DP信息
SG-6000# debug dp filter src-ip x.x.x.x src-port xx dst-ip x.x.x.x dst-port xx //设置debug过滤条件 源IP 源端口 目的IP 目的端口(可任选其中一项或多项作为debug过滤条件)
SG-6000# debug dp basic //debug 开关,查看数据包基本处理流程(务必先执行第一条过滤命令,否则debug所有数据包会造成CPU高或卡死)
SG-6000# debug dp snoop //查看StoneOS数据层转发基本信息
SG-6000# debug self //查看StoneOS自身数据包转发情况
SG-6000# show logging debug //查看debug调试输出信息
(九)StoneOS GRE 排障调试
SG-6000# show tunnel gre //查看GRE配置信息
SG-6000# show session tunnel //查看是否成功创建gre tunnel session
注:如果以上信息都没有问题,并排查对接设备无异常,可进行debug
SG-6000# debug dp gre //开启GRE debug 功能
SG-6000# show logging debug //查看debug调试输出信息
注:如果无明显error或者packet drop等信息,请继续按以下操作:
SG-6000# debug dp filter src-ip x.x.x.x src-port xx dst-ip x.x.x.x dst-port xx //设置debug过滤条件 源IP 源端口 目的IP 目的端口(可任选其中一项或多项作为debug过滤条件)
SG-6000# debug dp basic //debug 开关,查看数据包基本处理流程(务必先执行第一条过滤命令,否则debug所有数据包会造成CPU高或卡死)
SG-6000# debug dp snoop //查看StoneOS数据层转发基本信息
SG-6000# debug self //查看StoneOS自身数据包转发情况
SG-6000# show logging debug //查看debug调试输出信息
4. 补充说明
- 除以上介绍的Debug调试类型外,还有其他多种情况、场景以及相应故障排错手段,当StoneOS Debug手段在问题处理上较为局限的情况下,可考虑使用防火墙镜像流量(Mirror,Wireshark)、在线抓包(Capture)等手段或工具进一步分析定位问题。
- 本手册内容待后续保持更新。