很多企业运维在配置OpenVPN路由推送时经常遇到客户端拿到路由条目却无法访问目标内网段的问题，大多是没有提前满足OpenVPN路由推送：配置前提的要求，跳过前置检查直接写推送规则，最后排查故障要耗费数倍时间。本文结合常见的CentOS服务端、Windows客户端的部署场景，梳理所有必须提前确认的核心前提，帮你避开路由推送的常见坑。
服务端内核转发功能的基础开启要求
很多新手刚装完OpenVPN就直接在server.conf里写推送规则，完全没开内核的IP转发，这是路由推送失效的第一高发原因。
运维人员在OpenVPN服务端操作，提前校验内核转发等路由推送前置条件
你可以直接登录OpenVPN部署的Linux服务器，执行sysctl net.ipv4.ip_forward命令，如果返回值是0，梯子说明转发功能完全关闭，哪怕配置了推送规则，服务端收到客户端发往目标内网的数据包也会直接丢弃。
这里要注意不要只改sysctl.conf里的参数就重启服务，部分云服务器的安全组默认会禁止转发类流量，你需要在云服务商后台确认弹性网卡的转发校验状态已经关闭，否则内核转发开了也无法正常跨网转发数据包。
OpenVPN服务端自身的网段路由可达性校验
很多人误以为只要写了push "route 192.168.3.0 255.255.255.0"这条规则，客户端就能访问这个网段，实际上OpenVPN服务端本身必须先知道怎么去往这个目标内网段，梯子否则推送的路由就是无效的。
你可以在OpenVPN服务端上直接ping目标内网段里的任意一台在线业务服务器的IP，如果ping不通，说明当前OpenVPN服务器本身还没有配置到目标网段的静态路由，你需要先在服务器的路由表里添加指向内网核心交换机的回程路由，确认连通之后再做推送配置。
这里要注意如果OpenVPN服务端是双网卡部署，一张接公网一张接内网，不要把内网网卡的默认网关设置成公网出口的地址，否则内网回程流量会直接发去公网，哪怕你加了静态路由也会出现路由冲突。
推送网段和OpenVPN虚拟网段的无冲突校验
OpenVPN默认的虚拟客户端网段通常是10.8.0.0/24，如果你要推送的内网网段和这个虚拟网段，或者和客户端本地的局域网网段出现重叠，哪怕路由推送成功，客户端也会出现路由寻址混乱的问题。
你可以提前整理三类网段清单，蜂窝分别是OpenVPN虚拟服务端网段、所有要推送的内网业务网段、常见客户端本地家用/办公局域网的默认网段，把这三类网段全部做比对，确认没有任何重叠之后再写推送规则。
很多运维容易忽略客户端本地网段的冲突场景，比如部分远程办公用户家里的路由器默认网段就是192.168.1.0/24，如果你要推送的企业内网刚好也是这个网段，用户连上VPN之后就会直接无法访问家里的路由器，同时企业内网的流量也会寻址错误，这种情况你要么调整企业内网的网段规划，要么换用不重叠的网段做NAT映射。
防火墙规则的放行前置配置
不少运维配置完推送规则之后，能看到客户端已经拿到了推送的路由条目，但访问内网服务器直接超时，大多是没有提前配置OpenVPN服务端的iptables或者firewalld的NAT转发规则。
你需要提前在服务端配置SNAT规则，把所有从OpenVPN虚拟网卡出来、发往目标内网段的数据包，源地址转换成OpenVPN服务端的内网网卡地址，这样内网业务服务器返回流量才能正确回到OpenVPN服务器，不会直接走自己的默认网关发去其他地方。
最后你还要在OpenVPN的配置文件里确认没有设置client-to-client之外的多余路由过滤规则，也没有配置push的路由条目被客户端的本地防火墙拦截，你可以在Windows客户端执行route print命令，确认推送的路由条目已经出现在系统路由表中，下一跳指向OpenVPN的虚拟网卡网关，就说明所有前置条件全部满足，可以正常测试内网访问了。
