IPSEC VPN

隧道已建立，
业务为什么不通？

Chayven · 2026 年 10 月 12 日 · 技术说明

隧道状态与业务可达性，是两个需要分别验证的问题。看到 IKE 会话已建立之后，还要确认对应的 IPSec SA、流量选择与实际数据是否按预期经过隧道。本文是技术说明，不是客户案例。

1. 分开观察协商与数据

IKE 的状态用于检查密钥协商关系，IPSec SA 则对应数据保护。某个 IKE 会话存在，并不能单独证明目标业务匹配了正确的 IPSec SA。先确认需要检查的对端和业务流量，避免看错会话。

! Cisco IOS / ASA 示意；按平台版本核实
show crypto ikev2 sa
show crypto ipsec sa

在发起一次已授权的业务测试前后，比较对应 SA 的 encaps 与 decaps 计数变化。它们分别提供封装和解封装方向的数据线索。单向增长提示应进一步检查对端、路径及匹配情况；不能仅根据一个计数器就确定唯一故障原因。

! 虚构实验输出，只演示观察方向
测试前：encaps 120 / decaps 118
测试后：encaps 125 / decaps 118

检查源端到目标网络的路由、双端流量选择范围、NAT 的实际结果及防火墙放行策略。确认回程也有正确路径。不同设备的路由型和策略型 VPN 配置方式不同，应该以对应平台文档和实际命中状态为依据。

先使用只读状态和计数器收集证据。生产环境开启 debug 可能增加负载并产生包含敏感信息的输出，应单独评估、限制范围与持续时间。本文不提供一键修改或清空 SA 的操作，避免排障本身造成业务中断。

把“隧道 UP”当作一个观察结果，再用实际业务流量证明数据面是否工作。