不少企业部署站点到站点VPN之后，经常遇到业务侧反馈跨站点内网访问异常，却不知道从哪里下手排查，甚至把普通内网路由故障当成VPN本身的问题。本文从实际运维的落地流程出发，一步步教你判断站点到站点VPN是否正常工作，避开常见的排查误区，不用反复试错就能定位核心卡点。
站点到站点VPN连通性检查的前置前提
在开始检查VPN本身的状态之前，首先要确认两端VPN网关的基础公网连通性正常，你可以从本地网关的公网出口发起测试，确认能正常访问对端网关的公网接口地址，没有运营商层面的拦截或者中间链路的大面积中断。如果两端公网本身都无法正常通信，后续所有VPN协商流程都不可能正常触发，不需要急着修改VPN配置。
同时还要确认两端VPN设备的系统运行状态正常，没有出现CPU、内存资源占满，或者VPN相关进程意外退出的情况，不少老旧设备在长时间高负载运行之后，会出现VPN进程假死的状态，表面上配置都正确，实际完全无法发起协商。
运维人员按标准化流程分步校验站点到站点VPN的连通性状态，快速定位故障卡点
第一阶段IKE协商状态校验
站点到站点VPN的第一阶段是两端网关完成身份认证、协商共享加密参数的过程，这个阶段没有正常完成的话，后续所有加密隧道都无法建立。你可以登录两端的VPN网关管理后台，查看IKE安全联盟（SA）的条目列表，如果能找到对端公网IP对应的SA条目，且状态标记为活跃，就说明第一阶段协商已经成功完成。
这里有个非常常见的误区，很多运维人员以为公网能ping通对端网关，科学上网IKE协商就一定能成功，实际上部分运营商或者中间公网防火墙会拦截IKE协议用到的UDP端口，哪怕ICMP流量完全正常，也会导致协商一直卡在发起状态，这时候需要单独确认两端的对应UDP端口是双向可达的。
第二阶段IPSec SA状态校验
IKE协商成功之后，才会进入第二阶段的IPSec SA协商，这个阶段的核心作用是为两端需要加密传输的私网网段生成对应的加密转发规则。你在网关后台查看IPSec SA条目时，要确认之前在感兴趣流里定义的所有两端私网网段组合，都能找到对应的活跃SA条目，没有缺失或者异常超时的标记。
很多部分连通的故障都出现在这个环节，比如一端的感兴趣流写了总部所有私网网段，另一端的分支网关只写了部分业务服务器的网段，就会出现部分跨站点资源能正常访问，其他资源完全不通的情况，不少运维这时候误以为VPN整体故障，星驰反复调整加密参数，实际上只需要对齐两端的感兴趣流规则就能解决问题。
跨VPN私网业务连通性实测
协商状态全部正常之后，还不能直接判定站点到站点VPN完全正常工作，你需要从一端私网内的普通终端发起测试，直接访问对端私网的终端IP或者业务地址，而不是直接用VPN网关本身发起测试。不少网关的本地出站策略做了限制，网关自身发起的ICMP流量会直接走公网出口，不会进入VPN隧道，网关能ping通对端私网，不代表内网用户的流量也能正常走隧道转发。
除了基础的ICMP连通性测试之外，还要模拟真实业务场景做TCP层面的访问测试，比如跨站点访问内网共享文件夹、内部业务管理系统，星驰确认大流量传输场景下没有异常丢包或者连接中断的情况，部分场景下小数据包能正常传输，但是大流量分片会触发隧道转发异常，这类问题只靠ping测试完全发现不了。
常见的连通性误判场景
很多新手运维会犯的错误，是用终端能不能访问公网来判断站点到站点VPN的工作状态，实际上站点到站点VPN的作用只是转发预先定义好的跨站点私网流量，普通用户的公网访问流量还是走本地的互联网出口，两者的转发路径完全独立，完全不能用公网访问状态来判断VPN隧道的健康度。
还有一类非常容易混淆的场景，VPN隧道本身的协商和转发状态全部正常，但是其中一端的内网三层交换机上，没有配置指向对端私网网段的静态路由，没有把对应流量转发给VPN网关，看起来像是VPN不通，实际上是内网路由配置的问题，遇到这类情况不要盲目修改VPN参数，先逐跳追踪内网流量的转发路径，排除内网层面的故障之后再调整VPN配置。
日常运维过程中，可以定期查看VPN的SA存活状态，不用等业务侧报障再临时排查，科学上网提前发现协商异常的苗头，就能避免大部分站点到站点VPN的连通性故障，也能减少很多不必要的配置试错成本。
