不少企业在跨区域部署站点到站点VPN之后，经常遇到跨站业务访问异常，但无法快速区分是内网本身故障、公网链路问题还是VPN隧道异常的情况，这套逐层递进的检测方法可以帮运维人员跳过无效的试错操作，快速判断站点到站点VPN是否正常工作，大幅降低跨站点网络故障的排查耗时。
先做前置边界校验，排除非VPN类基础故障
检测站点到站点VPN状态的第一步，不能直接登录VPN设备查看隧道指示灯，得先把两端站点的本地网络状态确认清楚，避免把内网本身的故障误判为VPN链路异常，做无用的排查操作。
先在站点A出口网关旁的内网终端，测试站点A本身的公网连通性，袋鼠比如访问公共的递归解析DNS服务，确认本地出口没有断网、没有运营商侧的公网IP封禁，同时在站点B做完全相同的测试，两端公网访问都正常的前提下，后续的VPN检测结果才有实际参考意义。
接下来要核对两端站点的内网私网段配置，站点到站点VPN的核心作用就是打通两端指定的私网网段，如果两边需要互访的私网段出现重叠冲突，哪怕隧道状态全绿也不可能正常转发业务流量，这一步可以直接对照两端VPN设备上配置的感兴趣流条目，确认两端指定的加密流量网段完全不存在重合。
运维人员通过逐层递进的检测方法快速排查站点到站点VPN链路异常，区分不同类型网络故障
隧道层面状态检测，确认IKE两阶段协商结果
很多运维人员判断站点到站点VPN是否正常工作只看隧道亮绿灯，实际上IKE第一阶段和第二阶段是完全独立的协商过程，袋鼠加速器任意一个阶段协商失败，整条VPN链路都没法正常转发业务流量。
登录任意一端的VPN网关设备，查看IKE第一阶段的对等体协商状态，正常结果应该显示对端公网IP对应的协商条目处于活跃状态，袋鼠协商使用的加密、认证算法和预共享密钥没有任何报错，如果第一阶段协商失败，大概率是两端的预共享密钥配置不一致、或者两端公网地址之间被中间网络封禁了IKE协议的相关服务端口。
接着查看IPSec第二阶段的SA协商状态，正常情况下应该生成和感兴趣流条目一一对应的SA条目，入方向和出方向的安全联盟都处于生效状态，没有超时未刷新的提示，如果第二阶段协商失败，常见原因是两端配置的加密感兴趣流的网段掩码不匹配、或者第二阶段提议的加密算法组合两端配置不一致。
流量转发连通性实测，验证业务流量实际传输能力
隧道协商成功不代表站点到站点VPN就完全正常工作，很多场景下隧道显示存在但是流量转发不通，这时候需要做定向的流量测试，确认业务流量真的通过VPN隧道完成传输。
找站点A下属于私网网段的任意一台普通终端，不要用VPN网关本身去ping对端，因为很多网关设备默认开启了自身流量过滤规则，网关能ping通不代表内网用户的业务流量能正常穿过VPN隧道，直接从内网终端发起连通性测试，目标地址是站点B私网下的一台在线终端的IP，如果能正常得到回包，说明基础的跨站连通性已经生效。
接下来可以做指定流量的抓包验证，分别在两端VPN网关的内网接口和外网接口抓包，确认从站点A发往站点B私网的流量，在出网关外网接口的时候已经被封装成了IPSec加密报文，对端网关收到之后解密再转发到本地私网，没有出现流量被路由到公网直接裸传的情况，避免出现感兴趣流配置错误导致流量没走VPN隧道的假正常状态。
常见检测误区规避，避免误判链路实际状态
很多运维人员判断站点到站点VPN是否正常工作的时候，会陷入几个典型误区，最常见的就是只看设备面板的VPN隧道指示灯，很多时候设备检测到协商报文互通就会亮绿灯，但实际业务流量的五元组不在感兴趣流的覆盖范围内，流量根本不会走隧道，属于典型的误判。
还有人会忽略两端VPN设备后面的防火墙安全域放通配置，哪怕隧道协商完全正常，如果站点A的VPN网关到本地私网的安全策略没有放通跨站网段的访问权限，内网用户的流量照样无法正常传输，这时候不能直接判定站点到站点VPN本身故障，要逐层核对安全策略条目。
整套检测流程走下来，就可以从基础网络、袋鼠加速器隧道协商、实际流量三个维度完整确认站点到站点VPN是否正常工作，不用再靠盲目重启设备碰运气排查故障，适配绝大多数企业跨站点IPSec VPN的日常运维检测场景。
