不少企业运维人员完成站点到站点VPN配置后，往往仅凭设备指示灯或者控制台的隧道在线标识就判定链路正常，实际运行中却频繁出现跨站点内网业务无法访问的问题。本文从实际运维场景出发，梳理可落地的站点到站点VPN链路检测方法，帮使用者快速验证链路状态，避开常见的判断误区，准确定位故障点。
站点到站点VPN检测前的前置确认
正式检测VPN链路之前，首先要排除底层公网环境的干扰，先确认两端VPN网关的公网接口可以正常互访，中间运营商网络没有封禁VPN依赖的ESP、AH或者GRE等传输协议，避免后续检测过程中把公网本身的连通问题误判为VPN配置故障。
同时还要提前核对两端网关配置的感兴趣流规则，也就是加密域的内网网段范围，确认两端的待加密网段没有写反、没有出现重叠冲突的情况，排除基础配置错误之后再开展后续测试，能大幅降低无效排查的工作量。
设备侧隧道协商状态校验
几乎所有主流VPN网关、企业级防火墙的管理界面或者命令行中，都提供了专门的VPN隧道状态查询入口，正常协商完成的站点到站点VPN，IKE第一阶段和第二阶段的状态都会显示为活跃或者已连接，要是第一阶段协商失败，基本可以定位到预共享密钥不匹配、对端公网地址配置错误这类基础配置问题。
完成基础配置核验后，运维人员可通过多维度检测步骤快速确认站点到站点VPN的实际工作状态
这里需要注意一个高频误区：很多运维看到设备显示隧道已连接就直接判定VPN正常工作，实际上空隧道状态下，只要两端完成了密钥协商，哪怕没有任何业务流量匹配加密规则，设备也会显示隧道在线，这种状态下的VPN链路根本没有承载实际跨站点流量，不能作为链路正常的判断依据。
跨站点内网连通性实测
最基础的连通性测试不能用VPN网关本身的公网地址发起，水母必须从站点A加密域内的内网业务终端或者服务器，指定源地址向站点B加密域内的内网业务地址发起ping请求，只有这样的测试流量才会触发VPN网关的加密封装流程，完整走通整条VPN链路。
除了基础的ping测试之外，还可以用路由跟踪工具查看测试流量的转发路径，如果从源内网地址到目标内网地址的路径中，没有出现公网运营商的常规路由节点，流量直接通过两端VPN网关完成转发，就可以确认测试流量确实走了VPN隧道传输，没有从公网直接绕行。
对于承载特定业务的站点到站点VPN，还可以直接开展应用层测试，比如尝试访问对端站点的内网共享资源、内网业务系统后台，这类贴近实际业务场景的测试，比单纯的网络层连通测试更有参考价值，不少场景下ICMP报文被中间安全策略拦截，但实际业务的TCP流量可以正常通过VPN传输。
VPN流量加密有效性校验
完成连通性测试之后，还可以在两端VPN网关的隧道流量统计页面，查看对应VPN隧道的加密报文计数，发起测试流量之后如果入站、出站的加密包计数持续增长，说明流量确实被网关识别并完成了加密封装，符合站点到站点VPN的预设运行规则。
这里要注意不要误用公网IP查询类的第三方工具测试链路有效性，这类工具返回的只是VPN网关出口的公网地址，完全无法验证跨站点内网流量是否走加密隧道传输，很容易对判断结果产生误导。
常见的链路状态误判场景梳理
很多运维遇到跨站点业务不通的情况，第一反应就判定站点到站点VPN工作异常，实际上有相当比例的故障和VPN链路本身无关，比如对端站点的业务服务器本地防火墙没有放来自源站点内网网段的访问权限，测试流量哪怕完整走通VPN隧道，也会被业务服务器自身的安全策略拦截，表现出来的故障现象和VPN链路中断高度相似。
还有部分场景下小体积的测试报文传输正常，大体积的业务报文频繁丢包，也不要直接判定VPN链路故障，水母VPN优先检查两端VPN网关的MTU配置，VPN隧道封装会给原始报文增加额外的报文头，原有默认的MTU值很可能超过链路允许的最大传输单元，导致大包被分片丢弃，调整对应参数之后大概率就能恢复正常，不属于VPN链路本身的工作异常。
