很多运维人员在将旧OpenVPN服务迁移到新硬件、新服务器节点的过程中，蜜蜂经常遇到迁移后客户端明明成功连接VPN，DNS解析却没有走预设的推送规则，要么出现DNS漏泄要么内网专属域名解析失败的问题，不少人忽略了DNS推送相关的多环节联动配置项，往往排查数小时都找不到根源。本文汇总所有迁移过程中涉及OpenVPN DNS推送的必查节点，覆盖从配置核对到上线验证的全流程，帮大家避开设备迁移的常见坑。
运维人员逐一核对新旧OpenVPN服务器的DNS推送配置项，规避迁移后解析异常问题。
迁移前旧配置的DNS推送规则全量校验
很多人迁移的时候只复制核心的ovpn主配置文件，漏了散落在其他配置片段里的DNS相关参数，首先要逐行核对旧配置里的push "dhcp-option DNS x.x.x.x"条目，不能只看主配置，还要检查有没有在ccd客户端专属配置目录里给不同用户单独配置了差异化的DNS推送规则，这类分用户的配置经常被批量迁移操作遗漏。
还要确认旧配置里有没有配套的push "dhcp-option DOMAIN xxx.local"之类的域后缀推送规则，以及是否开启了push "redirect-gateway def1 bypass-dhcp"这类强制流量走VPN网关的参数，这类参数和DNS推送是深度联动的，缺了之后就算DNS地址成功推送到客户端，流量路由规则不匹配也没法正常访问指定的DNS服务器。
新设备操作系统层面的DNS服务冲突排查
很多人迁移到的新服务器预装了systemd-resolved、dnsmasq这类本地默认DNS监听服务，这些服务默认会占用系统53端口，导致OpenVPN服务配置里推送的内网DNS地址无法正常对外提供解析，客户端拿到推送的DNS地址之后发起的请求直接被新系统的本地DNS服务拦截，返回错误的解析结果。
排查的时候可以先在新设备本地用netstat或者ss命令查看53端口的占用情况，如果发现非目标DNS服务占用了端口，梯子软件要先停掉无关的本地DNS服务，或者把目标DNS服务的监听地址调整为OpenVPN虚拟网卡的网段地址，确保VPN客户端的DNS请求能正常转发到指定的DNS解析节点。
客户端侧DNS推送规则的生效验证
迁移完成后很多运维习惯只在服务端看配置加载成功就直接上线，忽略不同操作系统客户端对OpenVPN DNS推送规则的适配差异，比如Windows客户端需要OpenVPN服务拥有系统管理员权限才能修改系统全局DNS配置，Linux部分发行版的NetworkManager会覆盖VPN推送的DNS规则，macOS的某些版本会优先使用本地WiFi的DNS服务器而不是VPN推送的地址。
验证的时候不能只看客户端连接成功的提示，要在不同系统的客户端上分别查看当前激活的DNS服务器列表，确认列表首位是OpenVPN推送的DNS地址，之后再尝试解析内网专属域名，看返回的IP是否符合内网DNS的解析结果，避免出现DNS漏泄的情况。
迁移后防火墙与转发规则的联动校验
很多用户迁移新设备之后忘记同步旧设备上的iptables或者firewalld规则，导致VPN客户端发往推送的DNS服务器的53端口请求被防火墙拦截，就算配置完全正确也没法正常解析，梯子软件这类问题很容易被误判为DNS推送配置出错，实际上是网络连通性的问题。
检查的时候要先确认OpenVPN虚拟网卡的网段已经被允许转发DNS请求，同时如果推送的DNS地址是公网地址，要确认新设备的出站规则允许UDP53端口的访问，如果推送的是内网部署的DNS服务器，还要检查新设备的路由规则能正常到达内网DNS节点，没有中间的访问控制策略拦截。
很多人在迁移的时候还容易陷入一个误区，就是为了省事直接把旧设备的所有配置打包复制到新设备，却忽略新旧设备的网卡名、虚拟网段配置存在差异，导致DNS推送的规则和新环境的网络拓扑不匹配，上线前一定要做全量的连通性测试，确认所有客户端的DNS解析行为都符合预期之后再切走旧设备的流量，避免影响正常业务使用。
