很多企业跨区域部署分支站点之后，都会配置站点到站点VPN实现不同办公区的内网资源互访，不少运维人员经常遇到配置完设备显示隧道状态正常，但实际业务访问断断续续甚至完全不通的情况，很难快速判断隧道是不是真的正常工作。本文围绕站点到站点VPN：如何判断是否正常工作的核心排查需求，结合通用边界防火墙、企业级路由设备的常规配置逻辑，梳理从底层隧道协商到上层业务校验的全流程验证方法，帮运维快速定位故障点，避免无效排查。
先确认隧道基础协商状态
很多人判断站点到站点VPN通不通第一反应是直接ping业务服务器地址，其实要先从最基础的协商状态入手排查。登录两端边界设备的VPN配置管理页，找到IPsec隧道的状态统计板块，先查看第一阶段IKE SA的生成状态，如果第一阶段SA不存在，说明两端的预共享密钥、协商加密算法、对端公网地址配置本身就有错误，连密钥交换的基础通道都没有建立成功。
确认第一阶段协商正常之后，再查看第二阶段的IPsec SA状态，正常协商成功的站点到站点VPN隧道，两端设备都会生成双向的SA条目，条目里的子网段要完全匹配之前配置的感兴趣流规则，对应两个站点的内网互访网段。如果只有单向的SA条目，说明两端的感兴趣流匹配规则不对称，要么是某一端漏写了对应的内网子网，要么是源目网段的配置顺序写反了。
跨站点直连网段的连通性验证
很多运维容易跳过这个步骤直接测试上层业务，其实站点到站点VPN的感兴趣流默认覆盖的就是两个站点的内网直连网段，你可以在站点A的内网区域找一台测试终端，配置和站点A直连网段同段的静态地址，不要添加额外的静态路由，直接ping站点B边界设备的内网直连网关，这个测试可以排除中间三层转发的干扰，直接验证隧道的基础转发能力。
这里要注意一个常见的错误操作，不要用两端边界设备的公网地址互ping来判断站点到站点VPN的状态，公网连通只能说明两个站点的边界设备互联网路是通的，完全不能证明站点到站点VPN的隧道已经在转发加密流量。很多时候公网能通但VPN感兴趣流匹配错误，流量根本没走加密隧道，直接从公网绕行，这时候的连通是无效的，完全达不到跨站点内网互访的安全要求。
验证流量是否真的走加密隧道
这一步是很多排查流程的盲区，你可以在站点A的边界防火墙的流量日志板块，筛选源地址属于站点A内网网段、目的地址属于站点B内网网段的流量条目，正常走站点到站点VPN的流量，日志里会标记对应的IPsec隧道名称，同时有对应的加密数据包计数持续增长。
也可以在边界设备上开启公网接口的流量抓包，抓取两个站点边界设备之间的公网链路上的数据包，正常走IPsec VPN的流量都是ESP封装的加密包，不会出现明文的内网源目IP地址。如果抓包直接看到了明文的内网IP数据包，说明流量根本没匹配上VPN加密策略，直接从公网转发了，相当于站点到站点VPN完全没有起到安全防护的作用。
上层业务场景的连通性校验
前面的基础隧道和直连网段验证都通过之后，还要针对企业实际的业务场景做针对性校验，比如跨站点的文件共享访问、内网OA系统登录、分支站点访问总部的数据库服务。有些场景下隧道本身是通的，但两端的内网安全域策略放通不全，也会出现部分业务能通、部分业务完全无法访问的情况。
这里要注意一个非常普遍的排查误区，不要看到设备界面显示隧道状态UP就直接判定站点到站点VPN正常工作，很多设备的隧道UP状态只代表最近一次协商成功，长时间没有流量传输之后，部分设备会自动发起DPD存活探测，如果探测失败隧道会悄无声息断开，没有及时生成告警。这种场景下就需要配置定时的小流量探测任务保活，避免隧道闲置断开影响正常业务。
所有排查步骤走完之后，还要核对两个站点的内网路由配置，确认站点A指向站点B内网网段的下一跳是本地边界防火墙的内网接口，站点B的反向路由配置也完全对应，避免出现路由回指错误导致的流量绕行，确保所有跨站点的内网流量都完全通过加密的站点到站点VPN隧道传输，符合企业的内网访问安全规范。
