很多用户在部署OpenVPN实现跨网段内网访问的场景时，往往直接在服务端配置文件里添加路由推送语句，最后要么客户端完全收不到下发的路由条目，要么路由显示正常但实际访问内网全丢包，飞鸟VPN甚至出现客户端本地公网访问直接中断的问题。这类故障九成以上都不是配置语句写错了，而是没有提前完成OpenVPN路由推送：配置前提的全量校验，跳过前置步骤直接改配置很容易引发连锁的网络异常。
操作系统层面的转发功能前置校验
大部分Linux发行版默认是关闭内核IPv4转发功能的，这是OpenVPN路由推送：配置前提里最基础也最容易被忽略的步骤，就算你后续所有配置都完全正确，内核不开启转发的情况下，服务端收到客户端发来的跨网段数据包会直接丢弃，根本无法转发到目标内网设备。
如果是在Windows Server环境下部署OpenVPN服务端，也不能只安装完OpenVPN程序就直接修改配置，必须手动开启系统自带的路由和远程访问服务，飞鸟让操作系统具备三层转发能力，否则推送出去的路由在客户端看起来状态正常，实际所有跨网段请求都会在服务端被拦截。
运维人员正在OpenVPN服务端侧校验系统三层转发功能，排查路由推送前置故障
使用云服务器部署OpenVPN的用户还要额外校验云平台的安全组规则，很多云服务商默认的安全组策略会禁止不同网卡之间的转发流量，就算系统层面已经开启转发，公网网卡收到的内网回包也会被安全组拦截，这类底层网络限制不在OpenVPN配置的覆盖范围内，必须提前手动调整放行。
OpenVPN服务端核心配置的前置合规要求
OpenVPN路由推送：配置前提里还包含服务端拓扑模式的校验，要实现稳定的多网段路由推送，必须提前在服务端配置里开启topology subnet的子网拓扑模式，如果使用默认的旧式拓扑模式，推送大段连续内网路由时很容易出现地址冲突，客户端生成的路由条目优先级会出现异常，部分网段的访问请求会被导去错误的网卡。
还要提前检查服务端配置里的iroute反向路由规则有没有冲突，很多用户之前为了给特定客户端分配固定专属网段，手动添加过自定义的iroute规则，后续要推送全量内网路由的时候没有清理旧的冗余规则，会导致服务端路由表内部出现条目冲突，最后推送出去的路由只有部分网段能正常生效。
配置路由推送之前还要提前比对虚拟网卡网段和要推送的内网网段，确认二者不存在地址重叠，比如OpenVPN默认的tun虚拟网卡网段是10.8.0.0/24，如果要推送的内网网段恰好也覆盖了10.8.0.0段，飞鸟客户端收到路由之后会直接把虚拟网卡的通信流量导去内网，刚连上VPN就会直接断开连接。
客户端侧路由接收的前置适配要求
Windows平台的OpenVPN客户端默认只有管理员权限才能往系统路由表里写入新条目，如果用户平时习惯用普通用户权限启动客户端，就算服务端的OpenVPN路由推送：配置前提全部满足，下发的路由也无法写入系统路由表，只会在客户端日志里留下权限不足的报错，很多新手用户不会主动查日志，完全找不到故障根源。
macOS和Linux平台的客户端还要提前检查系统是否存在自定义的策略路由规则，不少用户之前为了部署代理服务手动添加过自定义路由优先级规则，这类规则的优先级远高于OpenVPN客户端自动生成的路由，就算推送的路由条目已经正常写入系统路由表，实际访问目标网段时还是会走默认的公网网关，完全达不到预期的转发效果。
常见配置前提误区排查
很多用户误以为只要在配置文件里添加push "route 目标网段 子网掩码"语句就等于完成了路由推送，实际上如果OpenVPN服务端本身的内网网卡都没有配置指向目标网段的静态路由，就算把路由条目推送给客户端，服务端也不知道把客户端发来的数据包转发到哪个下一跳地址，最后所有请求都会被直接丢弃。
还有部分用户为了实现所有流量都走VPN通道，直接推送0.0.0.0/0的全局默认路由，但是没有提前配置服务端内网网卡的NAT转发规则，最后客户端连上VPN之后所有公网请求都没法正常转发，直接出现断网的问题，连基础的DNS解析请求都无法完成。
完成所有OpenVPN路由推送：配置前提的校验之后，建议先单条推送小网段的测试路由做验证，确认客户端可以正常访问对应网段的内网设备之后，再批量添加其他待推送的路由条目，飞鸟避免一次性推送大量错误路由，导致客户端本地的网络规则出现冲突，影响用户的正常使用。
