很多企业搭建完站点到站点VPN之后，经常遇到网关界面显示隧道连通，但跨站点业务始终无法正常访问的尴尬情况，不少缺乏经验的管理员不知道从哪下手定位问题，往往要等业务侧报障后才能事后排查。本文结合通用企业级VPN网关、防火墙的常规配置逻辑，给出可直接落地的验证方法，帮技术人员快速确认站点到站点VPN的实际运行状态，提前排除隐性故障。
先从VPN隧道基础状态做第一层验证
判断站点到站点VPN是否正常工作的第一步，很多管理员都会先查看防火墙或者VPN网关的管理界面，确认隧道的状态标识，这是最直观的初筛步骤。
运维人员通过多步验证方法快速确认站点到站点VPN的实际运行状态，提前排查隐性故障
通用VPN网关的管理界面里，科学上网站点到站点VPN的隧道状态一般会标注为“已建立”或者“活跃”，但这个状态只能代表两端的IKE协商阶段已经完成，加密通道的基础握手流程没有出错，完全不代表实际的加密转发通道已经能正常传输业务流量，不少新手管理员会在这里踩坑，以为状态灯显示为绿色就等于隧道全功能正常。
跨站点私网地址的连通性测试
跳过界面状态直接做私网地址的连通测试，是验证站点到站点VPN可用性的核心步骤，测试时不要用两端网关的公网接口地址发起测试，要直接调用两端站点下的内网终端私网地址做互访。
比如总部站点的内网业务网段是192.168.1.0/24，分支站点的内网办公网段是10.0.0.0/24，你可以在总部接在内网业务网段里的办公电脑上，关闭本地的VPN客户端之后，直接ping分支站点下的内网服务器私网地址。
如果能收到正常的ping回复，说明两端站点到站点VPN的感兴趣流配置是匹配的，加密策略也没有拦截对应网段的互访流量，这时候隧道的实际转发功能已经初步生效。
要是ping不通，也不要直接判定VPN整体故障，先分别登录两端的VPN网关后台查看流量统计面板，看有没有对应的私网互访流量被匹配到VPN隧道的加密规则里，如果入方向和出方向的加密包计数都没有任何增长，大概率是感兴趣流的本地和对端网段配置写反了。
真实业务流量的传输验证
很多时候ICMP类型的ping包能正常通行，但实际业务用到的TCP或者UDP流量跑不通，这时候站点到站点VPN其实也不算正常工作，你需要用对应业务的服务端口做针对性连通性测试。
比如分支站点的员工要访问总部部署的OA系统，你可以在分支的内网终端上用telnet或者tcping工具，测试总部OA服务器的服务端口是否能正常响应，确认端口连通性没有被VPN两端的域间安全策略拦截。
如果端口测试正常，还可以传输一个小体积的日常业务文件做持续传输测试，确认跨站点的流量不会出现中途断连的情况，排除VPN隧道存在隐性丢包或者间歇性断开的隐藏问题。
常见的判断误区要主动避开
不少管理员会用公网环境下的traceroute命令测试跨站点私网地址，这其实是完全错误的操作，站点到站点VPN的加密流量不会在公网路径上暴露私网地址，公网链路的中间节点自然不会返回对应路由信息，很容易误判隧道出现故障。
还有人只在总部一侧发起连通性测试，忽略反向的流量验证，站点到站点VPN的感兴趣流是两端分别配置的，很容易出现总部能访问分支、但分支访问总部不通的单向连通问题，狗狗必须两端都主动发起测试才能覆盖完整的流量路径。
最后要注意，就算所有手动测试都通过，也要定期查看VPN隧道的运行日志，确认没有出现频繁重协商的情况，避免后续业务高峰期隧道意外断开，影响跨站点的正常业务交互。
