很多用户在自行配置OpenVPN客户端后，经常遇到本地DNS没有被VPN隧道覆盖、访问内网域名解析失败、甚至出现DNS泄漏的问题，这时候如果直接修改客户端配置很容易和服务端规则冲突，最稳妥的方式是提前和OpenVPN服务端管理员确认必要的配置信息，再完成本地适配，避免后续出现各类解析异常。
提前和OpenVPN服务端管理员确认DNS推送相关配置信息，可有效规避DNS泄漏、内网域名解析失败等问题
首先要确认服务端是否开启了DNS推送的全局权限
很多中小团队部署的OpenVPN服务端默认是没有开启推送DNS记录的相关参数的，梯子软件管理员可能之前只配置了隧道转发规则，没有在server.conf里写入push相关的DNS配置行。
这时候你首先要和管理员确认的第一个信息，就是服务端是否允许向客户端下发自定义DNS地址，部分运维人员出于安全考虑，会限制客户端自行修改DNS配置，避免用户接入VPN后使用公共DNS请求内网资源，导致解析请求漏出隧道。
如果服务端没有开启全局推送权限，哪怕你在本地客户端配置里强制指定了DNS，也很容易被服务端的防火墙规则拦截，出现解析超时的问题，提前确认这一点可以避免你做很多无用的本地调试工作。
确认需要推送的具体DNS服务器地址和域名匹配规则
不少用户误以为OpenVPN的DNS推送只会下发一两个公共DNS地址，实际上企业场景下的DNS推送通常分为两类，蜜蜂一类是全流量走隧道时使用的全局DNS，另一类是仅针对内网专属域名的分流DNS。
你需要和管理员确认，对方希望推送给客户端的DNS服务器具体是内网部署的私有DNS地址，还是公共DNS，同时要确认是否有指定的自定义域名后缀，所有带这个后缀的域名请求都必须走推送的DNS解析。
很多新手配置的时候容易把DNS填成自己本地常用的地址，结果接入VPN后访问内网业务域名完全无法解析，本质上就是没有拿到管理员提供的正确私有DNS地址，也不知道需要绑定对应的域名搜索后缀。
确认不同客户端系统对应的DNS推送兼容适配要求
Windows、macOS、Linux还有移动设备的安卓、iOS系统，对OpenVPN推送DNS的规则适配逻辑完全不一样，部分旧版本的OpenVPN服务端没有针对不同系统做兼容配置，推送的参数在部分系统上不会生效。
你需要和管理员确认，当前服务端的推送规则是否针对你正在使用的客户端系统做过适配，比如部分Linux发行版默认使用systemd-resolved服务管理DNS，普通的push参数无法直接修改系统DNS，需要管理员额外在配置里追加对应系统的适配指令。
如果管理员没有对应的适配经验，你也可以同步把自己使用的客户端系统版本告知对方，双方配合调整配置，避免出现其他系统下DNS推送正常，唯独你的设备解析异常的问题。
确认DNS推送相关的防泄漏规则配置情况
很多用户担心接入OpenVPN后出现DNS泄漏，本质上是服务端没有配置禁止客户端使用本地原有DNS的规则，部分管理员会在推送DNS的同时，下发规则拦截所有隧道外的DNS请求。
你需要和管理员确认，当前的DNS推送配置是否配套了对应的防火墙拦截规则，蜜蜂会不会出现你本地的原有DNS优先级高于推送DNS，导致部分解析请求绕过VPN隧道的情况。
同时你也要确认，管理员是否允许客户端保留自定义DNS的权限，部分场景下用户需要同时使用本地DNS解析家用局域网的设备域名，这时候就需要和管理员沟通调整规则，不要强制覆盖所有本地DNS配置。
完成以上所有信息的确认之后，你再按照管理员提供的参数修改本地OpenVPN客户端配置，就能最大程度避免DNS推送失效、解析失败、请求漏出之类的常见问题，不需要反复排查找不到故障根源。如果配置后依然出现解析异常，你也可以拿着之前确认过的规则信息和管理员同步本地的系统日志，双方定位故障的效率会提升很多。
