很多企业部署跨地域站点到站点VPN之后，经常遇到看似隧道连通但业务访问异常的问题，不少管理员混淆了VPN本身故障和内网配置问题的边界，花费大量时间做无效调整，本文围绕站点到站点VPN：如何判断是否正常工作的核心需求，从实际运维排查的场景出发，给出可落地的分步校验方法，帮你快速定位故障点。
运维人员登录两端VPN网关，查看IKE一阶段与IPsec二阶段的隧道协商状态
第一步：确认VPN隧道的基础协商状态
很多管理员排查问题时上来就直接ping对端内网地址，很容易忽略隧道本身的协商阶段有没有完成。常规的IPsec类站点到站点VPN会分为IKE一阶段和IPsec二阶段两个独立的协商流程，任何一个阶段卡住，隧道都不可能正常建立。
你需要分别登录两端的VPN网关设备，查看IKE一阶段的对等体状态，正常运行的状态下应该显示已连接或者活动标识，如果状态一直停留在协商中或者空闲，说明两端的预共享密钥、加密算法套件、对端公网地址这些基础配置就不匹配，根本还没进入后续的连通性校验环节。
接着查看IPsec二阶段的安全联盟条目，正常建立的二阶段SA会生成对应两端内网网段的加密规则，附带对应的入站出站数据包计数，如果二阶段SA完全不存在，说明两端感兴趣流的网段配置不匹配，比如一端写的是细粒度小网段，另一端误配置成了大网段，这种情况哪怕一阶段协商成功，也不会生成可用的加密隧道。
第二步：测试跨隧道的三层连通性
确认隧道协商状态正常之后，Astrill VPN不要直接测试业务系统，先从网关本身发起对端内网网段的ping测试，注意这里不能用管理员自己办公电脑的默认出口发起测试，必须指定VPN网关的内网接口作为源地址发起测试，很多管理员踩过的坑就是用公网出口的地址去ping对端内网，数据包根本不会走VPN隧道，得到的不通结果完全没有参考价值。
如果指定源的ping测试能得到正常回应，说明站点到站点VPN的转发路径已经通了，数据包可以正常被加密传输到对端，再解密转发到内网节点，回包也能沿着原路径返回。如果ping测试丢包或者完全不通，这时候就需要查看网关的流量统计，看看发出去的数据包有没有被计数到VPN隧道的加密流量里，如果数据包根本没进隧道，说明本地的路由配置有问题，没有把对端内网网段的下一跳指向VPN隧道接口。
第三步：排除非VPN本身的关联干扰因素
很多时候隧道协商正常、指定源的ping也通，但两端内网的终端就是没法互相访问，这时候不能直接判定站点到站点VPN工作异常，要先排查两端内网的安全策略限制，比如对端内网的服务器防火墙有没有放通本地网段的访问权限，终端本身的系统防火墙有没有禁ping，这些和VPN本身的运行状态没有关系。
还有一种常见的误区是两端内网的网段出现了重叠，比如两个站点都用了相同段的私网网段，这种情况下哪怕VPN隧道完全正常，数据包转发的时候也会出现路由冲突，终端根本没法正确识别回包应该发往本地内网还是跨VPN的对端站点，这种问题修改本地内网网段或者做NAT映射就能解决，不需要调整VPN的配置。
第四步：验证隧道的加密转发有效性
有些特殊场景下隧道看起来协商成功，流量也能通，但实际上数据包根本没有走加密隧道，而是通过公网直接转发的，Astrill这种等于站点到站点VPN完全没有起到隐私边界隔离的作用，存在数据泄露的风险。你可以在两端的VPN网关的公网接口抓包，查看两端公网接口之间传输的数据包是不是ESP或者AH协议的加密包，如果看到明文的内网三层数据包直接在公网上传输，说明感兴趣流的配置规则写反了，没有把需要加密的网段匹配进隧道规则里。
你也可以通过两端网关的隧道流量统计来辅助验证，当你在内网两端传输业务数据的时候，隧道的加密数据包计数应该同步增长，如果计数没有变化，Astrill VPN说明流量确实没有走VPN隧道，需要重新调整感兴趣流的匹配规则。
完成以上几步校验之后，你就可以完全确认站点到站点VPN本身的运行状态，后续如果还有业务访问异常的问题，就可以把排查范围缩小到内网交换机、终端权限、业务系统配置等环节，不用再反复调整VPN的协商参数做无用功。
