Windows 上 OpenVPN 连接后 DNS 为何停止工作

在 "OpenVPN" 连接之后，发往办公室解析器的 ping 仍有回应，可每一次名称查询都以失败告终。地址可达而端口不可达，一旦知道 Windows 能按适配器过滤 DNS，这个组合就说得通了。若配置中存在 block-outside-dns，该过滤项便是第一嫌疑，路由表并不是该看的地方。下面两项测试能在数秒内把层次分开。

地址可达，端口已死

ping 成功只能证明主机在线、路径存在。它不说明是否有权到达端口 53，因为问题中的过滤项工作在另一层，并绑定在适配器上。正因如此，同一台机器可以回应 ICMP，却拒绝发往同一地址的每一次查询。改动任何配置之前，请在同一次会话里跑完两项测试。

ping <resolver-ip>
nslookup <name> <resolver-ip>

这一对结果就是诊断。发往子网的普通流量照旧，名称解析却死掉，于是人们断定服务器坏了，或者 DNS 从未下发。两种解释追查起来都很贵，而证据指向更窄的地方。动手改设置之前先确认这一对。

该选项是筛选平台的规则

OpenVPN 文档把 block-outside-dns 描述为 Windows Filtering Platform 的一项限制，阻止应用访问隧道之外适配器上的 DNS。它覆盖 TCP 与 UDP 的 53 端口。由于该过滤项位于 WFP，而不是普通防火墙规则清单，在别处新增放行规则未必改变结果。这就是允许 DNS 这条常见建议一再失效的原因。

该设置可能来自导入的配置文件，也可能来自服务器，而你最后编辑的那个文件 "并不能证明客户端实际加载了什么"。请把生效配置与连接日志放在一起读。该选项还是 Windows 专属的，把它当成可移植设置只会给出不适用的建议。

不要继续加规则，而要找到拥有该限制的客户端组件。所有者才是真正能移除它的东西。

过滤项不是解析器

阻断隧道之外的流量，并不会在隧道内装好一个可用的解析器。该选项移除了一条路径，把隧道的 DNS 配置留给配置文件的搭建者。从未下发过解析器的配置，如今一个也没有。

按顺序做三项检查。第一，失败的应用程序实际使用哪个解析器。第二，客户端是否应用了 VPN 的 DNS 设置。第三，哪个接口承载通往该解析器的流量。

1. 在用解析器：把 Resolve-DnsName -Server <resolver-ip> <name> 与 ipconfig /all 列出的 DNS 服务器作比较。
2. VPN DNS 已应用：在同一份 ipconfig /all 输出中查看隧道适配器的 DNS 条目。
3. 所用接口：Find-NetRoute -RemoteIPAddress <resolver-ip> 会指出通往该目标的外出接口。

在该策略下，LAN 解析器按设计变得不可达，即使其他 LAN 流量照常工作。这正是该选项在做它该做的事。若设计需要经 VPN 的 DNS，就去修正解析器注册与隧道路径；若需要带本地例外的分离 DNS，配置的所有者必须以受支持的方式表达这些例外。

该选项不覆盖什么

53 端口并不是名称解析的全部。DNS over HTTPS 与 DNS over TLS 走不同的传输，有些应用无视系统设置，自行运行解析逻辑。因此浏览器能解析名称，命令行却不行。

把这种差异当作诊断线索，而不是矛盾。在判定系统解析器损坏之前，先把两者比一比。

写结论时把范围收窄。该选项只限制单一平台上的单一传输，解析路径的其余部分是另一项设计问题，另有其所有者。

断开前后各查一次状态

在连接期间执行同一次查询，并在拥有该设置的客户端断开后再执行一次。隧道在线时，前者对外部解析器应当失败；过滤项移除后，后者应当成功。若断开后仍然失败，说明过滤项没有被清理。

ipconfig /displaydns
nslookup <name> <resolver-ip>

重启客户端服务或机器通常能清掉残留的过滤项。这印证了诊断，却没有证明永久修好。把看到的现象记下来，因为能熬过断开的过滤项还会再来一次，而正是这份记录让缺陷报告站得住。

只有在这些检查之后，替换解析器或重建防火墙策略才说得通。两者都比证据支持的改动更大。