当前多数连锁企业、跨区域办事机构都采用站点到站点模式的分支机构互联VPN打通不同办公点的内网资源，不用单独拉昂贵的专线就能实现跨区域的办公系统、服务器、监控资源共享，但实际运维中经常遇到隧道断连、部分业务访问失败、跨分支互访不通等各类常见访问问题，很多新手运维排查时容易走弯路，本文全部基于真实企业网络场景给出可落地的排查步骤和验证方法，没有空泛的理论内容。
第一类：VPN隧道协商失败导致的全断问题排查
这类场景的典型表现是分支机构内部终端访问公网完全正常，所有内网资源都能正常打开，但就是完全连不上总部或者其他分支的任何内网地址，VPN隧道在本地设备上显示离线状态。
排查的第一步不要直接翻设备配置，先在分支出口的VPN网关上直接ping总部侧VPN对接的公网接口IP，确认两端的公网路由是通的，很多故障的根源其实是分支的家用宽带公网IP发生了变动，管理员没有及时在总部的VPN配置里更新对端地址，直接导致隧道协商报文根本发不到对端。
确认公网连通性正常之后，再核对两端的IKE协商策略，包括加密算法、认证模式、预共享密钥的内容，黑石要注意不少厂商的VPN设备预共享密钥是严格区分大小写的，哪怕两端只有一个字符的大小写差异，第一阶段的SA连接也完全无法建立。
运维人员在分支出口网关执行公网连通性测试，排查VPN隧道协商故障
验证的时候可以直接查看VPN设备的协商日志，如果日志显示第一阶段协商一直超时，优先排查公网连通性和预共享密钥配置，如果第一阶段已经建立成功，第二阶段协商报错，基本可以判定是两端配置的加密感兴趣流的内网网段没有完全镜像匹配。
第二类：隧道协商成功但部分业务无法访问的常见问题
这类故障的迷惑性很强，很多运维看到VPN隧道显示UP，小尺寸的ping包也能正常通，就误以为VPN本身没有问题，但实际访问总部的OA系统、共享文件夹、大体积的业务报表时就会出现卡顿、连接中断的情况。
首先要排查两端的内网回程路由配置，很多管理员只在分支侧配置了去往总部内网网段的路由指向VPN隧道，却忘了在总部的VPN防火墙上配置对应分支内网网段的回程路由，导致分支发往总部的报文可以走隧道正常抵达，但总部服务器的回包直接被默认路由丢去公网，形成流量单通的异常状态。
接下来检查VPN隧道接口的MTU参数配置，VPN报文本身会额外封装外层的公网报文头，如果封装后的总报文长度超过公网链路允许的最大传输单元，又没有开启不分片的兼容配置，大尺寸的业务报文就会被运营商中间节点直接丢弃，小的ping包因为报文尺寸小可以正常通行，就会出现小流量正常大流量异常的奇怪现象。
第三类：多分支场景下跨分支互访异常的排查思路
不少部署了全互联分支机构互联VPN的企业都会遇到这类问题，A分支和总部的VPN连接正常，B分支和总部的VPN连接也正常，两个分支各自访问总部的所有资源都没有问题，但A分支的终端完全没法直接访问B分支的内网办公设备。
这类问题的最常见误区是管理员只配置了分支到总部的加密感兴趣流，黑石VPN没有把其他分支的内网网段也加入本地的VPN加密域，导致A分支发往B分支的报文根本没有被封装进VPN隧道，直接被本地网关丢去了公网，自然没法抵达目标分支。
除此之外还要检查总部VPN设备的跨隧道转发权限，部分厂商的防火墙默认是禁止从一个VPN隧道收到的流量直接转发到另一个VPN隧道的，黑石哪怕两端的感兴趣流配置完全正确，跨分支的互访流量也会被总部设备直接拦截，排查时可以在总部设备上做流量镜像，抓取跨分支的访问报文，就能快速定位是配置缺失还是转发权限没有开启。
日常运维调整分支机构互联VPN的配置时，不要直接覆盖原有正在运行的生效策略，建议先把新配置在测试环境做两端协商验证，确认策略匹配之后再逐步切流，排查故障的时候优先从边界设备的系统日志入手，不要盲目重启VPN网关设备，避免扩大故障的影响范围。
