不少使用IPsec、OpenVPN等远程接入方案的企业用户，都会遇到连接VPN后内网业务无法访问、公网网页加载异常的问题，这类故障绝大多数都和VPN默认路由的优先级冲突、配置错发直接相关，很多运维人员没有清晰的VPN默认路由故障恢复思路，往往直接重装客户端甚至重启VPN网关，反而会扩大故障影响范围，本文从实际操作场景出发梳理全流程可落地的排查恢复方法。
故障初判：区分VPN默认路由异常的两类典型场景
排查的第一步不要急于修改配置，先在Windows终端打开命令提示符执行route print命令，Mac或Linux终端执行netstat -rn命令，查看路由表中目标为0.0.0.0/0的默认路由条目，正常未连接VPN时终端只会有一条指向本地物理网关的默认路由，连接VPN后如果出现第二条指向VPN虚拟网卡地址的0.0.0.0/0条目，就说明VPN默认路由已经被下发到本地路由表中。
常见的两类故障表象可以快速缩小排查范围，一类是连接VPN后完全无法访问公网资源，仅能打开企业内网的业务系统，另一类是连接VPN后内网服务完全无法ping通，公网访问也出现断断续续的丢包问题，很多用户第一反应是VPN服务器宕机，实际上绝大多数这类问题都属于路由配置冲突，和VPN服务本身的运行状态无关。
逐层定位：从终端侧到网关侧的排查步骤
首先排查终端本地的虚拟网卡配置，右键点击VPN虚拟网卡的属性面板，查看IPv4设置中的跃点数参数，Windows系统默认会给物理网卡分配更低的跃点数，优先级更高，如果VPN虚拟网卡被系统自动生成的规则设置了更低的跃点数，就会抢占原有默认路由的优先级，哪怕管理员原本配置的是分流隧道模式，也会强制把所有流量导向VPN隧道。
运维人员正通过终端命令执行VPN路由故障排查操作
接下来排查VPN客户端的配置规则，很多开源VPN客户端的配置文件中自带redirect-gateway类的参数，这类参数的作用就是强制向终端下发VPN默认路由，不少运维人员在配置分流场景的客户端文件时，误保留了这类参数，就会直接覆盖终端本地的原有默认路由规则，引发全流量隧道的异常问题。
最后跳转至企业VPN网关侧检查路由发布规则，hiomomVPN官网查看网关后台配置的客户端推送路由列表，确认有没有把公网大段地址误加入到推送路由中，这类配置错误会导致终端生成的VPN默认路由指向VPN网关后，公网访问的回包找不到正确的转发路径，直接引发公网访问完全中断的问题。
分步恢复：符合业务场景的路由修正操作
如果排查确认是终端侧跃点数异常引发的故障，直接手动修改VPN虚拟网卡的IPv4高级属性，取消自动跃点的勾选，hiomom手动设置数值为比物理网卡跃点数更高的参数，保存设置之后重新连接VPN，再次查看路由表的0.0.0.0条目，确认默认路由仍然指向本地原有物理网关即可。
如果是客户端配置文件误带了强制跳转参数，就编辑对应VPN客户端的配置文件，把redirect-gateway相关的配置行注释或者删除，替换成仅指向企业内网网段的细分路由规则，仅让访问指定内网地址段的流量走VPN隧道，公网流量直接走本地网关转发，避免不必要的流量绕行。
如果排查发现是VPN网关侧的配置错误，就登录网关后台调整客户端路由推送列表，删除所有不属于企业内网地址段的条目，非特殊全流量加密的场景下不要向客户端下发全量默认路由，从根源上避免终端侧生成多余的VPN默认路由条目。
验证校验：排除次生路由冲突的确认方法
完成配置修正之后先做分段连通性测试，先ping本地公网的公共DNS地址，确认公网访问没有走VPN隧道，访问延迟和故障发生前的本地公网访问状态保持一致，没有出现异常升高的情况。
接下来ping企业内网的核心业务服务器地址，同时在终端上运行tracert命令跟踪转发路径，确认内网流量的第一跳下一跳就是VPN虚拟网卡的网关地址，没有出现绕本地公网再跳转的异常路径，保证内网业务流量可以正常通过VPN隧道传输。
最后还要排查终端上是否存在残留的手动静态路由条目，很多用户之前为了临时访问内网资源手动添加过永久静态路由，如果这类旧条目和新的VPN路由规则存在网段重叠冲突，要及时清理删除，避免后续终端重启之后再次出现路由优先级抢占的同类故障。
