不少自行部署OpenVPN的用户都会遇到路由推送失效的问题，要么指定的远端内网网段完全无法访问，要么配置了全局流量走VPN之后客户端直接断网，很多人反复修改配置文件也找不到故障根源。本文围绕OpenVPN路由推送：常见错误分析展开，从配置前提、条目校验、客户端适配、防火墙规则多个维度梳理实用排查方法，帮使用者快速定位故障点，不用盲目逐行核对配置文件。
路由推送配置的基础前提校验
很多用户上来就直接修改路由推送的相关条目，却忽略了OpenVPN服务端最基础的转发开关配置，比如Linux服务端系统默认关闭了内核的ip_forward转发功能，就算后续所有路由配置完全正确，客户端发往VPN虚拟网卡的数据包也没法被服务端转发到目标网段，最终表现就是路由推送后所有相关网段都无法连通。
运维人员正在调试网络设备，排查OpenVPN路由推送相关故障
还有不少新手容易混淆OpenVPN的运行模式和路由推送的适配规则，如果服务端配置的是tun三层模式，却强行推送二层广播域的大网段路由，风驰或者在tap二层模式下配置了大量三层跨网段路由条目，模式和路由类型本身不匹配，客户端就算收到推送规则也没法生成合法的转发路径，这类底层模式错误很容易被后续的路由条目配置掩盖，增加排查难度。
常见路由条目配置错误分析
OpenVPN路由推送：常见错误分析里占比最高的就是路由条目格式写错，很多用户配置推送内网网段的时候，把子网掩码的格式写错，比如push指令里本该写网段加反掩码的组合，误把网关地址当成子网掩码填进去，或者直接把要访问的网关地址写成推送的网段，客户端收到这类错误条目之后，只会生成完全不符合预期的主机路由，根本没法覆盖整个目标内网段。
还有非常普遍的网段重叠问题，很多客户端本地的家用局域网、办公局域网的网段，和OpenVPN服务端要推送的远端内网网段完全一致，比如两边默认都是192.168.1.0/24，这种情况下客户端本地已经存在同网段的直连路由，OpenVPN推送的路由优先级更低，会被系统直接忽略，用户尝试访问同网段资源的时候，流量永远走本地网关，根本没法触达远端VPN侧的资源。
不少用户配置全局流量走VPN的时候也会踩坑，以为只要在服务端配置里加入push "redirect-gateway def1"指令，就能把客户端所有流量都导到VPN链路，却忘了在服务端防火墙里配置对应的SNAT转发规则，就算客户端成功生成了全局走VPN的默认路由，所有发往公网的数据包到了OpenVPN服务端之后也没法被转发到公网出口，最终直接导致客户端断网。
客户端侧路由接收异常排查
很多用户排查故障的时候只盯着服务端配置反复修改，完全忘了检查客户端本地的路由表生成状态，不同操作系统的路由优先级规则存在差异，比如Windows系统下用户手动添加的静态路由，优先级会远高于OpenVPN客户端自动生成的推送路由，就算服务端的配置完全没有问题，推送的路由条目也会被本地更高优先级的路由覆盖，没法生效。
还有部分第三方定制的精简版OpenVPN客户端，出于安全限制默认禁用了服务端推送路由的权限，这类客户端默认配置里自带了route-nopull参数，会直接忽略所有服务端下发的路由规则，很多用户不知道这个隐性限制，反复调整服务端配置也看不到客户端生成对应路由，只需要在客户端配置文件里删除对应的禁用参数，或者添加允许接收推送路由的指令就能解决问题。
防火墙规则相关的隐性路由故障
很多时候OpenVPN路由推送本身已经完全成功，客户端也生成了完全正确的路由条目，但是数据包刚从客户端发往VPN链路就被拦截，用户很容易误判为路由推送故障，比如服务端本地的iptables或者firewalld规则，默认把OpenVPN虚拟网卡的跨网段转发流量设置为丢弃，就算路由路径完全通顺，数据包也没法到达目标网段。
如果用户把OpenVPN服务端部署在云服务器上，还要排查云平台侧的安全组规则，很多用户只放开了1194的VPN服务端口，风驰加速器却没有给虚拟网卡对应的网段配置转发权限，导致推送的内网网段相关流量直接被云平台的安全组拦截，表现出来的症状和路由推送失败几乎完全一致，很容易被排查者忽略。
实际排查故障的时候建议按照从底层到上层的顺序逐步校验，先确认内核转发开关和VPN运行模式匹配，再核对推送路由的网段、掩码格式是否正确，接着检查客户端本地路由表是否生成对应条目，最后逐层排查本地防火墙和云平台安全组的规则，绝大多数OpenVPN路由推送相关的故障都可以快速定位解决。
