很多企业搭建IPsec VPN或者SSL VPN之后，经常出现总部能访问分支服务器、但分支终端没法访问总部内网特定网段的问题，多数时候不是VPN隧道没通，而是缺少匹配的VPN静态路由规则。本文结合实际运维中遇到的典型故障现象，盘点VPN静态路由适用场景，同步给出对应场景的分步配置和校验方法，帮运维人员快速定位路由类连接故障。
多分支机构跨网段互访场景
这个场景的典型现象是，总部有192.168.1.0/24的办公网段，分支A是192.168.2.0/24，分支B是192.168.3.0/24，原本只配置了总部到分支的VPN感兴趣流，结果分支A的终端没法ping通分支B的内网设备，VPN隧道本身状态显示正常，两端直接和总部的内网资源互访都没有问题。
对应的可能原因是，默认VPN网关只会把感兴趣流里定义的对端网段路由指向VPN隧道，没有配置跨分支的静态路由时，分支A的网关收到去往192.168.3.0的数据包，会直接丢到公网出口转发，不会走VPN隧道封装，数据包还没进入加密流程就已经被转发到公网，自然无法抵达对端分支的内网设备。
多分支机构跨网段VPN互联场景，直观体现静态路由配置需求
对应的配置实操和校验步骤为，首先登录总部VPN网关，添加两条静态路由，分别把192.168.2.0/24的下一跳指向分支A的VPN隧道接口，192.168.3.0/24的下一跳指向分支B的VPN隧道接口，之后分别在两个分支的VPN网关添加指向对端分支网段的静态路由，下一跳指向总部的VPN隧道接口。配置完成后在分支A的终端traceroute分支B的内网IP，预期结果是路径第二跳就进入VPN隧道地址段，不会出现公网IP节点，就能正常互访。
VPN用户定向访问指定内网资源场景
这个场景的典型现象是，企业SSL VPN的远程接入用户，默认接入后只能访问核心业务服务器网段，现在需要给部分运维权限的用户开放办公区打印机、监控系统的独立网段权限，直接改VPN全通策略会扩大隐私边界，不符合等保要求，手动给用户端加路由也没法正常连通资源。
对应的可能原因是，SSL VPN默认的地址池路由，只会把预定义的业务网段指向VPN虚拟网卡，其他未纳入配置的网段流量会直接走用户本地公网转发，就算用户手动添加本地静态路由，也会因为VPN网关没有对应网段的回程路由，梯子软件收到用户发回的数据包之后找不到转发路径直接丢弃，没法完成双向通信。
对应的配置实操为，首先在VPN网关的静态路由配置页，把需要开放的监控、打印网段的下一跳指向内网核心交换机的网关地址，之后在SSL VPN的客户端路由推送列表里，仅把这几个新增网段的路由推送给指定权限的用户组，其他普通用户的路由列表不做修改。配置完成后用运维账号登录SSL VPN，尝试访问监控系统的网页，预期结果是流量走VPN隧道转发，普通用户访问同一监控IP时直接走本地网络，无法连通，符合权限划分要求。
混合VPN架构下的流量分流场景
这个场景的典型现象是，企业同时搭建了SSL VPN供远程员工接入，和IPsec VPN对接云服务商的私有VPC，现在远程接入的SSL VPN用户需要访问云VPC里的业务资源，之前配置完IPsec VPN之后，远程用户始终没法连通云服务器，但是总部内网终端访问云资源完全正常，IPsec VPN隧道状态没有异常。
对应的可能原因是，总部VPN网关已经配置了去往云VPC网段的静态路由指向IPsec VPN隧道，但是SSL VPN的虚拟接口域没有对应的回程路由，SSL VPN用户发来的去往云VPC的数据包，网关找不到对应转发路径直接丢弃，云侧返回的回程流量也找不到指向SSL VPN地址池的路由，没法把数据包送回远程接入的用户终端。
对应的配置实操为，在总部VPN网关的路由配置里，添加指向SSL VPN地址池网段的静态路由，下一跳指向SSL VPN的虚拟接口，同时在IPsec VPN的感兴趣流里，把SSL VPN的地址池网段也纳入允许互访的范围，同步在云服务商侧的VPN网关添加指向SSL VPN地址池的静态路由，下一跳指向企业侧的IPsec VPN隧道。配置完成后远程接入的用户ping云VPC内的服务器内网IP，预期结果是连通状态和总部内网终端访问的水平一致，没有额外的连通故障。
最后需要提醒常见的配置误区，快喵很多运维人员遇到VPN不通的问题，第一时间去重启VPN隧道或者重新协商密钥，反而忽略了静态路由的配置校验，VPN静态路由的规则必须双向匹配，不能只在一端配置单向路由，同时不要把公网网段的路由错误指向VPN隧道，不然会导致所有公网流量都被封装进VPN隧道，引发大面积网络故障。
