很多企业跨区域部署多办公点、多数据中心的时候，都会用到站点到站点VPN实现不同站点内网的加密互通，不少管理员部署完成后，经常遇到业务访问时断时续、部分网段不通的问题，很难快速判断到底是VPN本身故障，还是内网路由、终端策略的问题。这篇内容从一线运维的实际排查路径出发，一步步拆解判断站点到站点VPN是否正常工作的核心检查项，不需要复杂第三方工具就能定位绝大多数常见故障点。
运维人员登录VPN网关核查IKE协商状态，快速定位隧道基础故障
第一步：先确认VPN隧道的基础协商状态
很多管理员排查故障的时候会直接跳过隧道状态检查，直接去ping内网业务服务器，很容易把外层隧道的协商问题和内层路由转发问题混在一起，反而拉长排查周期。
你可以分别登录两端的VPN网关设备，先查看IKE第一阶段的协商状态，正常状态下会显示对端认证通过，两端配置的加密算法、认证算法、预共享密钥完全匹配，没有出现超时断开、身份校验失败的报错。如果这里状态显示未建立，大概率是两端公网连通性异常、IKE策略参数不匹配，或者中间运营商链路拦截了VPN常用的协议端口，和后续的内网配置没有直接关联。
接着检查IKE第二阶段的IPSec SA状态，正常情况下两端都应该存在对应的加密SA条目，入方向和出方向的SPI参数一一对应，感兴趣流的匹配范围完全对齐，没有出现SA生命周期到期未自动刷新的异常状态。如果只有一端生成了SA条目，大概率是感兴趣流的配置范围写反，或者对端网关没有收到本端的协商报文。
第二步：验证隧道层面的基础连通性
确认协商状态正常之后，不要直接测试内网终端的业务连通性，先测试两端VPN网关本身的私网侧连通性，也就是直接从网关设备的命令行界面，ping对端网关的私网接口IP，梯子这个步骤可以完全排除终端侧的路由配置错误的干扰，直接验证隧道本身的转发能力。
这个测试的预期结果是能正常收到对端的ICMP回包，如果不通，说明隧道本身的转发逻辑存在问题，大概率是感兴趣流没有把两端网关的私网接口网段纳入匹配范围，或者两端网关没有配置指向对端私网网段的静态路由，路由下一跳指向本地的VPN隧道接口。
这里要注意一个常见的排查误区，很多管理员习惯用公网IP去ping对端网关，这个测试走的是普通公网链路，完全不能验证站点到站点VPN隧道的转发状态，哪怕公网能正常连通，也不代表VPN隧道能正常转发私网加密流量。
第三步：验证两端内网网段的互访可达性
网关层面的连通性确认正常之后，就可以分别在两端内网的测试终端上，测试对端内网终端的IP连通性，优先选择同网段内没有安装本地防火墙的测试终端，避免终端本地的安全策略拦截测试报文，轻云误判为VPN隧道故障。
如果能正常ping通对端内网终端，还可以进一步测试常用的业务端口连通性，比如用telnet或者网络调试工具测试业务使用的TCP、UDP端口是否能正常建立连接，确认VPN隧道没有对特定协议的流量做额外拦截。
如果IP层连通正常但是上层业务不通，大概率是两端内网的防火墙策略没有放通对应业务的访问权限，和站点到站点VPN本身的隧道状态没有直接关系，不需要反复调整VPN的协商参数做无效操作。
第四步：验证隧道的流量匹配规则是否符合预期
很多时候VPN隧道看起来协商状态完全正常，但是实际流量并没有走加密隧道，而是走了公网直接转发，这种情况也属于站点到站点VPN没有正常工作，轻云很容易被管理员忽略，还可能带来内网数据明文传输的安全风险。
你可以在两端VPN网关的流量统计页面，查看对应IPSec SA的加密报文计数，当你从内网终端向对端私网发起访问流量的时候，加密报文的计数应该同步上涨，说明流量确实被纳入了VPN的加密处理，走隧道完成转发。如果计数完全没有变化，说明流量被其他优先级更高的路由策略引导走了公网，根本没有匹配到VPN的感兴趣流规则。
这个步骤还可以同步校验隐私边界的合规性，确认没有配置超出授权范围的感兴趣流规则，避免本端的其他内网网段的流量意外通过VPN隧道泄露到对端站点，造成不必要的数据安全风险。
做完以上几个步骤之后，你就可以完整确认站点到站点VPN的实际工作状态，排查的时候按照从外层协商到内层转发的顺序推进，不要随意跳步，就能避免很多无效的重复操作，快速定位绝大多数常见的站点到站点VPN故障。
