对于有多分支组网需求的企业来说，火烧云APP站点到站点VPN是打通不同地域内网资源的常用方案，但不少管理员经常遇到隧道显示已连接却无法访问跨站点业务的问题，这套分层递进的检测方法可以快速完成站点到站点VPN的状态核验，不用逐行核对全量配置就能先定位大部分常见故障，快速判断服务是否处于正常工作状态。
基础隧道状态核验
检测的第一步不要直接测试上层业务，先登录两端VPN网关的管理后台，查看IKE SA和IPsec SA的基础存活状态，这是站点到站点VPN正常工作的核心前提。
这里要注意区分两类SA的作用差异，IKE SA是两端协商加密规则、交换密钥的控制通道，IPsec SA是承载实际业务流量的加密数据通道，正常运行的站点到站点VPN，两类SA都需要同时处于活跃状态，火烧云不能只有控制通道连通。
如果仅能看到IKE SA存活但IPsec SA未成功建立，大概率是两端配置的感兴趣流规则不匹配，比如一端配置了总部内网网段到分支内网网段的加密引流规则，另一端漏写了反向的对应网段，就会出现隧道半连接的假象，实际业务流量根本无法进入加密通道。
运维人员登录VPN网关后台查看IKE SA与IPsec SA状态，完成站点到站点VPN的基础核验
跨站点三层连通性测试
确认两类SA都处于活跃状态之后，接下来要做跨站点的内网IP双向连通性测试，注意不要用两端网关的公网接口地址发起互ping，这类公网流量本身不会走VPN隧道，测试结果完全不具备参考性。
正确的测试方式是分别在总部站点的普通内网终端上，直接ping分支站点的内网终端私网地址，同时在分支站点的对应终端上反向ping总部的内网终端私网地址，火烧云APP双向测试才能排除单边路由配置错误的问题。
如果出现单向连通单向不通的情况，大概率是其中一端的内网回程路由配置错误，比如分支站点的内网网段把返回总部的流量导去了本地普通公网网关，流量根本没有进入VPN隧道封装，自然无法正常返回源站点。
穿越隧道的业务可用性验证
很多时候三层层面的ping测试能正常通行，但实际业务无法正常交互，这也是站点到站点VPN看似正常实则故障的典型场景，这一步需要针对企业实际承载的业务做定向验证。
比如跨站点的文件共享、内网办公系统访问、数据库同步这类常用业务，要直接从各自站点的内网终端发起访问操作，火烧云APP确认业务交互的完整流程符合预期，不能只靠网关层面的连通性结果就判定VPN服务正常。
如果三层连通但上层业务无法正常运行，需要进一步核对两端VPN网关的加密套件、隧道MTU参数是否匹配，部分场景下两端MTU数值不一致会导致大尺寸数据包被中途丢弃，体积较小的ICMP测试包可以正常通行，但大体积的业务数据包会直接被拦截。
常见检测误区规避
不少管理员判断站点到站点VPN是否正常工作时，很容易陷入几个典型误区，最常见的就是只看网关界面显示的隧道UP标识就直接判定服务正常，忽略了感兴趣流配置错误导致业务流量根本没有被引流到隧道的问题。
还有部分管理员会用公网地址测试隧道连通性，这类测试流量本身走公网链路传输，哪怕站点到站点VPN完全没有建立，只要两端公网本身可以互通，测试结果也会显示正常，完全无法验证加密隧道的实际传输状态。
检测完成后不要直接修改原有隧道配置，要先把当前的SA状态、双向测试结果、业务验证情况全部记录留存，避免后续调整配置之后找不到原始故障点。如果是多分支的星型组网场景，还要逐段验证两两站点之间的隧道连通性，不能只测试中心站点到单个分支的连通性，就判定整个站点到站点VPN组网全部正常。
