很多使用OpenVPN搭建远程办公隧道的运维人员，经常会遇到连接VPN后本地DNS仍走公网链路、内网私有域名解析失败的问题，部分旧版本OpenVPN还会出现推送规则不兼容、配置指令不生效的异常。本文结合常见的CentOS服务端、Windows桌面客户端的实际部署场景，拆解DNS推送的正确设置逻辑，以及合规的版本升级检查方法，帮使用者避开多数常见配置误区。
OpenVPN DNS推送的配置前提
要实现DNS推送规则正常生效，首先得确认服务端和客户端的配置文件都开启了非强制的推送接收权限，一分机场很多新手只在服务端添加推送指令，忽略客户端侧的限制设置，比如部分企业预装的终端安全软件会默认锁定本地DNS列表，这时候就算服务端配置完全正确，推送规则也会被直接拦截。
配置前还要先区分当前隧道运行的是TUN还是TAP模式，TUN三层模式下DNS推送是作用于虚拟网卡的解析优先级，仅匹配走隧道的流量对应的解析请求，TAP二层模式下推送的DNS会直接覆盖本地局域网的原有DNS列表，两种模式的配置逻辑差异较大，确认模式后再调整后续参数，能减少很多不必要的排障步骤。
OpenVPN服务端DNS推送的标准配置步骤
在OpenVPN服务端的server.conf配置文件里，不要直接用公网公共DNS作为唯一推送值，要先把企业内网的域控DNS放在推送列表的最前面，后面再追加公共DNS作为兜底，这样内网域名会优先走内网DNS解析，公网域名也不会出现解析失败的问题。
运维人员在机房调试OpenVPN服务端配置，排查DNS推送异常问题
还要追加两条配套的推送指令，分别是指定内网根域的搜索列表指令，以及触发客户端系统主动注册推送DNS的指令，前者让客户端输入不带后缀的内网主机名也能正常解析，后者避免Windows系统的旧DNS缓存没刷新导致解析滞后的问题。
所有配置修改完成后不要直接重启服务，先在终端执行配置预校验命令，确认没有语法错误之后再重启OpenVPN服务，避免配置写错导致整个隧道服务直接宕机，影响所有远程用户的接入。
客户端侧DNS推送生效的验证方法
Windows客户端连接隧道之后，不要直接从系统网络连接面板里看DNS地址，一元机场官网要打开命令提示符执行ipconfig /all命令，找到OpenVPN生成的虚拟网卡条目，查看DNS服务器列表里有没有出现你在服务端推送的内网DNS地址。
接下来执行nslookup命令测试内网私有域名，比如企业内部的OA系统、文件服务器域名，看返回的解析IP是不是内网段的服务器地址，如果返回的是公网IP，就说明DNS推送没有生效，大概率是客户端本地物理网卡的DNS优先级设置比虚拟网卡更高。
OpenVPN版本升级检查的实操方法
很多DNS推送规则不生效的问题，本质是客户端或者服务端的OpenVPN版本太旧，低于2.4版本的OpenVPN原生不支持部分dhcp-option的扩展参数，旧版本在Windows 10以上系统里经常出现推送规则被系统安全机制拦截的问题。
检查版本的时候，服务端直接在SSH终端执行版本查询命令即可，客户端要在图形界面的帮助菜单里找到关于选项查看实际运行的版本号，不要直接从桌面图标属性里看版本号，部分绿色免安装的客户端图标属性里的版本信息，和实际运行的二进制文件版本并不一致。
升级版本的时候不要直接跨大版本升级，要先从低版本迭代到中间稳定版本，确认所有现有隧道配置正常运行之后，再升级到最新的稳定版本，跨大版本直接升级可能出现原有加密套件不兼容的问题，导致所有隧道无法建立连接。
升级完成之后，要重新做一次DNS推送的验证测试，确认新版本没有改动原有推送逻辑，避免升级后原本正常的解析规则突然失效，影响远程办公用户的正常访问。
