明确适用的协议与系统范围
OpenVPN 的 DNS 推送功能主要依赖于服务端配置文件中的 push 指令，该指令仅对使用 OpenVPN 协议连接的客户端有效。不同操作系统客户端（如 Linux、Windows、macOS）解析推送 DNS 的方式略有差异，Linux 通常由 openvpn 进程直接修改 resolv.conf 或通过 systemd-resolved 管理，而 Windows 和 macOS 客户端则可能通过本地网络接口代理或 TAP 适配器生效。在配置前，务必确认服务端使用的 OpenVPN 版本支持动态推送选项，以及客户端是否启用了 dhcp-option 或 redirect-gateway 相关的配套设置，避免因为协议版本不兼容导致 DNS 请求被默认网关劫持而非指定 DNS。
检查现有网络配置与备份
在修改任何服务端配置之前，必须对当前环境进行只读检查并备份。首先，使用 systemctl status openvpn@server 或相应服务管理命令确认 OpenVPN 服务正在运行且状态正常。接着，备份现有的 server.conf 或 openvpn.conf 配置文件，例如执行 cp server.conf server.conf.bak。这一步至关重要，因为 DNS 推送配置错误可能导致部分客户端无法解析域名，甚至影响其访问内网资源。备份文件应保留版本号和时间戳，以便在故障发生时能快速恢复原状，无需重新推导之前的配置逻辑。
修改配置前的只读检查与备份是关键步骤。
配置 DNS 推送指令及权限要求
修改服务端配置文件需要 root 或具备等效权限的用户身份，因为编辑配置文件和重启 OpenVPN 服务都涉及系统级操作。在配置文件中添加 push "dhcp-option DNS 8.8.8.8" 和 push "dhcp-option DNS 8.8.4.4"（示例 IP，实际请替换为内部 DNS 服务器地址）。注意，dhcp-option 是 OpenVPN 模拟 DHCP 选项的机制，并非真正的 DHCP 协议交互。如果同时配置了 redirect-gateway，DNS 流量会被强制通过隧道，此时推送的 DNS 地址必须可达，否则会导致客户端解析失败。配置完成后，需检查文件权限是否可读，避免 SELinux 或 AppArmor 阻止 OpenVPN 读取修改后的配置。
验证 DNS 解析路径与故障恢复
配置生效后，客户端需断开并重新连接以获取新的推送选项。在客户端使用 resolvectl status（Linux）或查看网络连接属性（Windows）确认当前 DNS 服务器是否已变更为目标地址。进行实际解析测试时，可使用 nslookup example.com 或 dig @8.8.8.8 example.com 验证是否指定了正确的 DNS 节点。若发现 DNS 未生效，应检查客户端是否启用了“忽略推送配置”选项，或本地防火墙是否拦截了 53 端口的 UDP/TCP 流量。恢复原设置时，直接还原备份的配置文件并重启 OpenVPN 服务，客户端重新连接后会自动回退到默认网关 DNS，确保网络状态回到变更前的基线。
