很多企业跨区域部署办公系统、共享业务数据的时候都会用到站点到站点VPN，把不同物理位置的局域网打通成同一个私域网络，不少运维人员配置完之后经常不确定隧道是不是真的生效，有没有出现看似连通实际业务走公网的隐性故障，本文就结合实际运维场景里的通用检测步骤，从底层隧道状态到上层业务连通逐层拆解，帮你准确判断站点到站点VPN是否正常工作。
配置完站点到站点VPN后，可优先在两端网关侧查看IKE协商状态确认隧道基础连通性。
VPN网关层面的隧道状态校验
所有站点到站点VPN的检测都要从两端的VPN网关设备入手，不管是企业级防火墙、专用VPN网关还是云厂商的VPN网关控制台，都能直接查看隧道的协商状态，这是判断站点到站点VPN是否正常工作的第一步基础依据。
正常情况下IPsec类的站点到站点VPN会先后完成IKE一阶段和二阶段的协商，两个阶段都显示“已建立”或者“活动”状态才是隧道基础协商成功，橘子VPN如果其中任意一个阶段显示协商失败，说明两端的预共享密钥、感兴趣流匹配规则、加密算法集配置大概率存在不匹配的问题，这时候还没到上层连通的检测环节。
这里要注意一个常见误区，不少运维看到隧道显示UP就直接判定VPN正常，实际上部分场景下隧道协商成功但感兴趣流的反向路由配置错误，还是会出现单向不通的问题，不能只看网关状态就直接下最终结论。
跨站点私网地址的直连连通性测试
隧道状态确认正常之后，接下来要跳过两端的公网网关，直接用两个站点局域网内的终端做私网地址的连通测试，这是验证站点到站点VPN转发逻辑是否生效的核心环节。
比如北京站点的私网网段是192.168.1.0/24，上海站点的私网网段是192.168.2.0/24，你可以在北京站点找一台关闭了公网出口的终端，直接ping上海站点私网内的一台服务器的内网地址，如果能得到正常的ICMP回包，说明私网层面的跨站转发已经走通了VPN隧道。
这一步要特意排除终端本身的公网路由干扰，不少终端同时配了公网网卡和远程访问VPN客户端路由，很容易把跨站私网的流量错导向公网，得到的ping通结果其实是走了公网的映射地址，根本没有走站点到站点的加密隧道。
流量路径的加密属性校验
连通性测试通过之后，还要进一步确认流量确实是走了加密的VPN隧道，橘子而不是两端私网之间有其他冗余的公网专线打通，出现了VPN闲置的情况，这也是判断站点到站点VPN是否正常工作的关键校验点。
你可以在任意一端的VPN网关的流量统计页面，查看对应感兴趣流的加密报文计数，当你在两个站点的终端之间传输大文件的时候，加密报文的数量应该同步上涨，和你传输的流量规模匹配，这就说明流量确实被网关加密后通过VPN隧道转发。
也可以在网关的出口镜像端口抓包，正常走站点到站点VPN的公网侧报文都是ESP或者AH协议的加密报文，不会出现明文的私网地址封装，如果你在公网侧抓到了源目都是两端私网地址的明文报文，说明流量根本没有进入VPN加密流程。
上层业务的跨站访问验证
底层网络校验都完成之后，最后还要结合企业的实际业务场景做验证，毕竟部分场景下VPN隧道的MTU值配置不合理，会出现小报文能通、大业务报文直接丢包的隐性故障，这类故障光靠ping测试完全无法发现。
比如跨站点的文件共享服务、内部OA系统、数据库同步服务，都要模拟日常办公的正常操作流程做全流程测试，确认所有业务交互都能正常完成，没有卡顿或者中断的情况，符合日常使用的体验要求。
这里要注意，单次测试业务正常也不能完全排除偶发的隧道重连故障，你可以在不同的时间段重复测试几次，确认隧道的稳定性符合日常使用要求。
整个检测流程走完，就能完整确认站点到站点VPN的工作状态，避免出现看似连通实际业务裸奔走公网的安全风险，也能快速定位大部分常见的配置类故障，不用再靠主观感受判断VPN的运行状态。
