不少企业部署站点到站点VPN之后，经常遇到设备面板显示隧道已连接，但两端内网的业务系统始终无法互访的问题，很多管理员缺乏系统化的检测思路，要么反复调整配置浪费大量时间，要么误判VPN正常工作留下数据泄露的隐患。本文结合常见企业级防火墙、VPN网关的实际操作逻辑，给出分层落地的检测方法，不需要复杂的第三方工具就能快速判断站点到站点VPN是否正常工作，覆盖从隧道底层协商到上层业务连通的全验证环节。
边界网关的隧道基础状态校验
绝大多数站点到站点VPN都承载在企业出口防火墙或者专用VPN网关上，很多管理员上来就直接拿内网终端做ping测试，其实第一步必须先确认隧道本身的协商状态，比如主流企业级防火墙的IPsec隧道管理页面中，会直接标注对端网关的协商状态标记，如果显示协商失败、未建立，后续所有内网连通性测试都没有实际参考意义。
这里要注意区分IKE一阶段和二阶段的运行状态，很多新手看到一阶段SA显示活跃就误以为VPN已经连通，实际上如果二阶段的加密策略、感兴趣流匹配规则不匹配，两端的加密业务流量根本无法被正常封装转发，必须确认两个阶段的SA都处于活跃状态，且两端配置的感兴趣流保护网段完全对应，没有出现本端、对端网段写反的低级错误。
跨隧道的直连网段连通性验证
确认隧道基础状态正常之后，不要直接测试内网业务服务器，优先调用两端网关自身的命令行工具，用网关的内网接口地址做源地址发起ping测试，比如总部VPN网关的内网接口地址是192.168.1.1，分支VPN网关的内网接口地址是192.168.2.1，从总部网关的命令行里指定源地址为192.168.1.1去ping分支网关的192.168.2.1，这个测试可以直接排除终端本地防火墙、终端路由配置错误的干扰，直接验证VPN隧道的核心转发链路是否通畅。
如果这个层级的测试都失败，大概率是感兴趣流的配置存在疏漏，或者两端网关的公网出口之间存在运营商端口、协议拦截，导致封装后的VPN报文无法正常传输，这时候不需要去排查终端侧的规则，先回到VPN隧道的感兴趣流匹配条目、外网连通性配置做逐一核对即可。
终端侧的端到端业务连通校验
网关层面的连通性验证通过之后，就可以使用两端内网的普通终端做端到端测试，比如用总部的办公电脑去访问分支的文件服务器地址，同时在终端上执行路由跟踪操作，确认流量路径在经过本端内网网关之后，直接进入VPN转发节点，如果路径里出现了公网的第三方路由节点，就说明互访流量根本没有走VPN隧道，是直接从公网转发的，站点到站点VPN的配置没有实际生效。
很多场景下终端ping对端内网地址能通，但实际业务系统无法访问，这时候要针对性测试业务对应的传输端口，比如分支要访问总部的OA系统使用的是自定义端口，就可以用端口探测工具验证这个端口的连通性，部分企业的VPN默认配置下会拦截超过标准长度的大报文，小尺寸的ping包可以正常传输，但业务产生的大MTU报文被中途丢弃，就会出现看似连通实际业务不可用的假象。
常见误判场景的排查确认
很多管理员会犯的典型错误是只看VPN设备的状态指示灯或者管理页面的“已连接”标记，就直接判定站点到站点VPN正常工作，实际上部分设备的隧道保活机制存在缺陷，状态显示SA活跃但实际加密流量已经中断，这时候必须持续传输几分钟真实业务流量，确认隧道不会出现频繁断连重协商的异常情况。
还有一种高频误区是测试的时候用了公网地址访问对端业务，误以为流量走了VPN隧道，实际上很多企业的业务服务器本身配置了公网端口映射，就算VPN链路完全中断，也能从公网直接访问服务，这种测试完全不能验证站点到站点VPN的工作状态，正式验证前可以临时关闭两端的公网业务映射规则，确保访问业务的流量只能走VPN加密链路。
最后还要核对VPN的流量边界配置，站点到站点VPN的核心作用是为指定的两个内网互访流量建立专属加密通道，不要把普通用户访问公网的流量也纳入感兴趣流的匹配范围，不然会出现分支所有用户上网流量都绕经总部出口的异常情况，确认只有预设的内网互访流量走加密隧道，其余流量正常走本地出口，才算是站点到站点VPN的配置完全符合预期。
