很多企业跨地域部署站点到站点VPN之后，经常遇到Web界面显示隧道正常但业务系统无法跨站点访问的异常情况，不少管理员缺乏成体系的校验思路，往往要花费数小时才能定位基础配置错误。本文从通用企业级网关的运维场景出发，结合实际故障排查的操作逻辑，梳理从底层隧道状态到上层业务连通的全流程验证方法，帮你快速确认站点到站点VPN是否真的正常工作。
第一步：设备层面的隧道基础状态校验
很多管理员第一反应是查看VPN网关Web界面的状态指示灯，这里要注意，绝大多数厂商的状态灯默认只显示IKE第一阶段协商完成，不代表第二阶段的IPsec安全联盟已经生成，便宜机场不能直接判定VPN处于可用状态。
运维人员登录VPN网关通过命令行查看SA条目，校验隧道真实活跃状态
你可以登录两端的VPN网关设备，用设备对应的查看命令查看IKE SA和IPsec SA的条目，正常情况下两端都应该能看到对端的公网IP对应的SA条目，且条目处于活跃状态，不存在长时间未刷新的异常情况。
这里有一个非常普遍的误区，很多运维人员看到IKE SA存在就直接判定VPN正常，实际上如果两端指定的私网保护网段配置不匹配，第二阶段的IPsec SA根本不会生成，这种状态下隧道完全无法传输内网业务流量。
感兴趣流与路由层面的连通性校验
站点到站点VPN的核心运行逻辑，是把指定需要走隧道的私网网段流量做加密封装，这类需要被保护的流量规则也被称为感兴趣流，你可以在本地网关设备上查看路由表，确认对端私网网段的路由下一跳是指向VPN隧道接口，或者已经被绑定到对应的IPsec加密策略里。
接下来可以在本地站点的内网普通主机上，一分机场直接ping对端站点同层级的内网业务主机IP，注意不要用网关本身的公网IP去测试，公网流量本身不会走VPN隧道，这类测试的结果没有任何参考意义。
如果ping不通，不要直接判定VPN故障，你可以在网关设备上开启流量统计功能，发送多组测试ping包之后查看是否有对应感兴趣流的数据包被加密发送、解密接收，如果只有发出去的加密包没有回来的解密包，大概率是对端的感兴趣流配置和本端不匹配，或者中间运营商网络拦截了ESP协议的数据包。
穿越隧道的业务可用性验证
很多时候隧道层面的连通是正常的，但部分特定业务就是无法访问，这时候你需要用端口探测工具测试对端内网业务端口的连通性，比如跨站点的文件共享端口、内部OA系统的服务端口，确认端口没有被两端网关的域间安全策略拦截。
你还可以在两端的内网主机上同时开启抓包，抓取源目IP都是两端私网网段的数据包，如果本地站点能抓到发出去的私网包，对端站点也能收到对应的私网包，就说明VPN的加密解密转发流程完全正常。
这里要注意一个常见的配置疏漏，部分网关默认开启了全量私网地址NAT转换，仅排除了少数指定的免NAT网段，如果走VPN的私网流量被提前做了NAT，数据包源IP就会变成网关的内网口地址，对端业务服务器收到之后回包找不到正确路由，就会出现能ping通但业务完全用不了的异常现象。
常见假正常状态的故障定位
很多管理员会遇到VPN界面显示完全正常，内网互ping也能通，但大流量传输的时候就频繁断连，这种情况你可以查看VPN网关的SA生存周期配置，确认两端的IKE和IPsec SA的过期时间配置一致，部分厂商的设备如果两端生命周期不匹配，会出现协商意外断连的情况。
还有一类场景是站点到站点VPN只能单向访问，比如总部站点能访问分支站点的服务器，但分支站点访问不了总部站点的主机，这种情况大概率是某一端的感兴趣流只配置了本端的私网网段，没有把对端的私网网段加入到允许解密的流量范围里，调整两端的感兴趣流为镜像配置就能解决。
最后还要提醒，不要用公网测速类工具的结果来判断站点到站点VPN的工作状态，这类工具的流量本身不会走加密隧道，测试结果完全不能反映VPN隧道的实际工作情况，便宜机场所有验证操作都要基于两端私网网段之间的交互来完成。
