很多用户部署OpenVPN后明明在服务端写好了路由推送指令，客户端接入后却发现目标网段的流量根本没走VPN隧道，直接走了本地网关转发，这类故障九成以上都不是路由指令写错，而是没有满足OpenVPN路由推送的前置配置前提，本文从实际运维排查的常见现象出发，逐项梳理必须校验的前置条件，帮你避开配置时的隐性坑。
服务端操作系统的IP转发开关校验
很多新手部署OpenVPN的时候只会照着教程复制配置文件内容，完全忽略了Linux或者Windows服务端系统本身默认是关闭IP转发功能的，这个底层开关不打开，哪怕OpenVPN服务端识别到了推送指令，也没办法处理跨网段的隧道转发流量。
排查的时候先登录OpenVPN服务端，机场推荐Linux环境下先检查/proc/sys/net/ipv4/ip_forward的数值，Windows环境下在注册表或者网络适配器高级设置里查看IP转发状态，确认开关已经设置为开启状态。
这个步骤的预期结果是，系统内核允许不同网卡接口之间的三层流量转发，不会把从隧道网卡收到的跨网段数据包直接丢弃，这是所有路由推送功能生效的最底层基础，一分机场跳过这一步后续所有配置都不会生效。
运维人员登录OpenVPN服务端校验IP转发开关，排查路由推送异常问题
OpenVPN服务端配置的基础路由权限声明
很多教程里的最简OpenVPN配置文件没有打开IP转发相关的配置项，一分机场哪怕系统级的转发开关开了，OpenVPN进程本身也没有权限处理三层路由流量。你需要检查服务端配置文件里有没有写启用于TUN模式的相关声明，要是你用的是TAP模式部署也需要确认桥接转发的相关参数没有被注释。
这里最容易被漏掉的配置项是允许客户端之间互相通行、以及允许推送路由的相关权限声明，部分版本的OpenVPN默认会拒绝服务端主动向客户端推送自定义路由，需要显式写入配置参数放开限制。
这一步校验的预期结果是，OpenVPN进程启动时不会报路由权限相关的警告，日志里可以看到加载了推送路由的相关配置项，没有出现参数不支持的报错提示。
服务端本地网段的反向路由回包配置
很多用户配置完推送客户端走VPN访问内网网段之后，发现内网的业务服务器收到了VPN客户端的请求，回包却直接发给了本地网关，没有走回OpenVPN服务端的隧道网卡，直接导致客户端收不到响应，看起来就像路由推送完全失效。
排查这个问题的时候你需要确认，目标要推送的内网网段的网关设备，已经配置了指向OpenVPN服务端内网地址的静态回程路由，或者OpenVPN服务端本身开启了源地址NAT，把VPN客户端的虚拟地址段的流量做地址转换之后再转发到内网网段。
这里的常见误区是很多人以为只要OpenVPN推了客户端侧的路由就完事了，完全没考虑双向流量的回程路径，哪怕客户端侧的流量全部走隧道，回程路径不对整个通信还是无法建立。
客户端侧的路由接收权限校验
部分桌面端或者移动端的系统，默认不允许第三方VPN应用随意修改系统全局路由表，哪怕OpenVPN客户端收到了服务端发来的路由推送指令，也没有权限把对应的路由条目写入系统路由表，自然也不会生效。
排查的时候你可以先查看OpenVPN客户端的运行日志，确认有没有收到服务端发来的路由推送报文，再去查看当前系统的路由表，有没有对应推送网段的路由条目指向OpenVPN生成的虚拟网卡。如果日志里显示收到了路由推送，但系统路由表里没有对应条目，基本可以判定是客户端的权限限制导致的。
这一步的预期结果是客户端以管理员或者系统授权的权限运行OpenVPN进程，系统路由表中自动生成了服务端推送的所有网段的路由条目，下一跳指向OpenVPN虚拟适配器的地址。
做完以上所有前置条件的校验之后，你再去配置服务端的push路由指令，基本就不会出现路由推送完全不生效的问题，后续如果出现部分网段不通的情况，再针对性排查防火墙规则、网段冲突这类后续问题即可。
