很多企业运维人员在配置IPsec或者SSL VPN的时候，经常遇到内网资源访问走公网、VPN隧道流量绕远、跨站点互访不通的问题，大半都和VPN路由优先级配置错误有关，本文结合华为AR系列路由器、深信服SSL VPN网关这类常见企业设备的实际部署场景，梳理高频错误的根因、排查步骤和验证方法，帮运维快速定位故障。
静态路由优先级数值配置倒置错误
很多新手运维刚接触路由优先级规则的时候，会混淆不同路由协议的默认优先级数值，比如华为设备里静态路由默认优先级是60，IPsec VPN生成的动态策略路由默认优先级是60，要是手动写了指向VPN隧道口的静态路由，反而把优先级数值设得比60大，系统就会优先选普通公网静态路由，根本不会把流量送进VPN隧道。
企业运维人员现场调试路由器，排查VPN路由优先级相关配置故障
这个错误的典型场景是分支站点配置总部VPN对接后，分支员工访问总部服务器走公网链路，触发安全设备拦截还泄露业务数据，完全达不到VPN加密传输的预期。排查的时候可以直接在设备特权模式下执行display ip routing-table命令，查看目标内网网段的路由条目下一跳，科学上网如果下一跳是公网网关而不是VPN虚拟隧道接口，基本就可以定位是优先级数值设反了。
修正的时候要注意，指向VPN隧道的路由优先级数值必须小于普通公网静态路由的数值，调整后要清空设备路由表的缓存条目，再用客户端访问目标内网地址，在VPN网关上查看流量统计，确认对应流量已经匹配到VPN加密策略。
策略路由和全局路由的优先级冲突错误
不少部署了多出口VPN网关的企业，会同时配置基于源地址的策略路由，指定特定部门的流量走VPN隧道，但是配置的时候忘了调整策略路由的调用顺序，系统默认优先匹配全局普通路由，导致策略路由完全不生效。
这类错误常见于同时部署了SSL VPN远程办公和IPsec站点到站点VPN的混合场景，远程接入的用户访问内网资源的时候，流量先匹配了网关默认的公网路由，直接被转发到公网，根本没有进入SSL VPN的虚拟转发实例。排查的时候要先进入VPN网关的策略路由配置界面，检查策略路由的生效优先级是否高于全局普通路由，部分厂商设备默认策略路由的优先级低于全局路由，需要手动调整调用顺序。
验证的时候可以在远程接入的SSL VPN客户端上tracert总部内网服务器地址，看第一跳是不是指向VPN网关的虚拟内网接口，如果第一跳直接跳到公网节点，就说明策略路由的优先级配置没有生效，调整后再追踪路由，路径应该全程走VPN隧道的虚拟转发节点。
双VPN场景下路由优先级叠加冲突错误
部分大型分支机构会同时配置两条VPN链路，一条是主用的运营商专线IPsec VPN，一条是备用的公网SSL VPN，运维为了做冗余，手动给两条VPN的路由都设置了相同的优先级，导致系统路由震荡，流量一会走主隧道一会走备隧道，业务频繁断连。
这类错误的核心误区是误以为同优先级的路由会自动做负载分担，但VPN隧道本身不支持等价路由的负载分担，同优先级的不同VPN路由条目会导致系统反复刷新路由表，部分流量直接被丢弃。排查的时候可以在设备上查看路由表的更新日志，如果短时间内同一网段的下一跳反复切换，基本就可以定位是双VPN路由优先级配置冲突。
修正的时候要把主用VPN对应的路由优先级数值设置得更低，备用VPN的路由优先级数值设置得更高，主隧道正常运行的时候系统只会选主用路由，主隧道故障后备用路由才会自动上浮，切换过程不会出现路由震荡。调整后可以手动断开主VPN链路，快连vpn确认流量自动切换到备用VPN链路，恢复主链路后流量自动切回主隧道，就说明配置符合预期。
虚拟转发实例路由优先级继承错误
很多企业VPN网关会用VRF虚拟转发实例把VPN用户的路由和公网用户的路由完全隔离，但是配置的时候忘了给VRF实例单独配置路由优先级，直接继承了全局路由的优先级规则，导致VPN实例内的路由条目优先级低于全局路由，跨VRF互访的时候流量直接溢出到公网。
这类错误的隐蔽性很强，常规的路由表排查如果只看全局路由表，根本发现不了VRF实例里的配置问题，只有当VPN用户需要访问公网资源的时候，才会出现访问不通或者流量泄露的问题。排查的时候要单独进入对应VPN的VRF视图，查看VRF内的路由优先级配置参数，确认VRF内指向VPN隧道的路由优先级高于VRF内的公网路由优先级。
验证的时候可以用VPN接入的客户端同时访问内网业务系统和公网普通网站，内网访问的流量走VPN隧道加密，公网访问的流量走指定的出口，没有出现路由跳转异常的情况，就说明配置已经修正完成。
