不少用户在部署OpenVPN服务后，经常遇到连接VPN后域名解析依然走本地运营商链路、出现DNS泄露的问题，排查下来大多不是推送指令写错，而是没有满足OpenVPN DNS推送配置的前置要求，很多前期准备环节的疏漏会直接导致配置完全不生效，本文就把全链路的前提校验要点和实操准备步骤汇总，帮大家避开常见的配置坑。
运维人员正在逐项核对OpenVPN DNS推送配置的各项前置准备要求
操作系统层面的路由规则兼容前提
首先要确认OpenVPN服务端和客户端运行的系统，是否支持自动覆盖DNS解析优先级的路由钩子，比如Debian/Ubuntu系的新版本Linux系统，默认用systemd-resolved接管了resolv.conf文件，直接修改这个文件写入DNS地址是无效的，OpenVPN自带的update-resolv-conf脚本需要适配这套解析服务的规则，才能正常写入推送的DNS地址。
Windows系统下需要确认OpenVPN客户端运行时的账户权限，必须拿到系统网络配置的修改权限，普通用户权限启动的客户端，没有改写系统网卡DNS列表的权限，就算服务端配置了推送指令，客户端也会直接忽略这条配置，不会给出明确的报错提示。
macOS系统下还要提前确认系统版本对应的OpenVPN客户端适配规则，机场梯子部分旧版本的客户端没有适配苹果系统的网络配置守护进程，就算拿到管理员权限，也没法把推送的DNS地址写入虚拟网卡的配置项里。
OpenVPN服务端核心配置项的前置校验要求
很多人以为只要在server.conf里加push "dhcp-option DNS 8.8.8.8"就完成了OpenVPN DNS推送配置，实际上这行指令生效的前提是服务端已经正确配置了虚拟子网的DHCP分配规则，不能和推送的DNS地址所在网段产生冲突，否则客户端会判定收到的DHCP选项非法，直接丢弃这条配置。
还要提前确认服务端没有开启冲突的自定义路由重定向规则，比如之前配置过强制所有流量走VPN的redirect-gateway指令，要确认这条指令和DNS推送的优先级适配，机场梯子如果只推送DNS不重定向网关，部分系统会默认优先使用物理网卡的DNS服务器，导致推送规则不生效。
客户端侧网络环境的前置排查要点
如果客户端本身的物理网卡已经被运营商或者企业内网配置了强制DNS锁定，比如部分校园网、机场推荐企业办公网环境下会把网卡的DNS设置成不可修改的组策略，这种情况下OpenVPN的DNS推送配置本身是无法覆盖系统级的锁定规则的，需要先解除本地的组策略限制才能继续调试。
还要检查客户端本地有没有安装第三方DNS代理工具，比如各类本地DNS缓存加速软件、广告过滤类的本地DNS服务，这类工具会拦截系统的DNS修改请求，所有解析请求都优先走工具自身预设的服务器，OpenVPN推送的DNS配置不会作用到这类第三方进程上。
配置完成后的初步验证逻辑与常见误区
很多用户验证DNS推送是否生效的时候，只看浏览器打开的IP查询网站显示的DNS地址，这个结果是不准的，部分网站会自己内置DNS探测逻辑，优先读取浏览器的预解析缓存，正确的验证方式是断开VPN之后清空本地DNS缓存，再连接VPN之后用系统自带的nslookup或者dig工具查询测试域名的返回服务器地址。
还要注意一个常见误区，就是不要把DNS推送和全局流量代理的效果混为一谈，就算OpenVPN DNS推送配置完全生效，也只能保证系统默认的解析请求走指定的DNS服务器，如果你本地的应用程序硬编码了其他DNS服务器的地址，还是会出现解析请求绕过VPN虚拟网卡的情况。
如果调试过程中发现推送配置始终不生效，可以先查看OpenVPN客户端的运行日志，日志里会明确标注收到的推送指令列表，以及系统拒绝修改DNS配置的具体报错原因，不需要上来就反复修改服务端的配置文件，先从日志里的报错定位对应的前置条件缺失项，就能快速解决大部分配置不生效的问题。
