Windows 上究竟是谁在应用 OpenConnect 的 DNS 设置？
Windows 在三处保存解析器状态。在手动修改适配器 DNS 或添加命名空间规则之前，先找到真正掌管连接的那个助手。
建立隧道并不等于安装它的 DNS 值。OpenConnect 负责协商，Windows 一侧的助手负责应用。这两步之间的缺口解释了这个客户端上大多数私有名称故障，而那个助手几乎从来不是 Windows 的 VPN 设置页面。
把网关提供的内容和 Windows 实际安装的内容分开
客户端把连接数据交给脚本接口，Unix 与 Windows 的变体是两个独立的程序。在 Windows 上，实现通常是一个 JavaScript 助手，它先读取内部 DNS 服务器和内部域之类的变量，然后才接触任何适配器。隧道本身不写入任何解析器状态。
这种分工很重要，因为一个值可以存在于协商中却永远到不了适配器。缺失、半途失败，或是被打包在 GUI 外壳里的旧副本，都会让 Windows 维持原样。会话看起来已连接，私有名称仍旧走本地解析器，客户端窗口里没有任何东西提示差异。读助手自己的输出，是唯一可靠的办法来判断哪一步断了。
| Stage | What exists there | Where you see it |
|---|---|---|
| Negotiated | Internal DNS address and domain pushed by the gateway | Client log or helper input |
| Installed | Adapter DNS entry, connection suffix, or namespace rule | Adapter and policy queries |
| Selected | Resolver Windows uses for one specific query | The failing application |
GUI 外壳可能自带客户端和助手的副本，所以磁盘上别处出现第二个 openconnect.exe 说明不了什么。先找到启动该会话的可执行文件，再判断它的配置。
在不改动的前提下读取解析器状态
三条只读查询足以覆盖常见的困惑，每一条回答不同的问题：
Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix
Get-DnsClientNrptPolicy -Effective适配器级别的服务器就是大多数人说的 VPN DNS。连接专用后缀决定短名称到底会不会被展开。命名空间策略列表对所有匹配的名称生效，与适配器顺序无关，而当助手从未打算创建规则时，那里结果为空并不是故障。编辑前把三者都读一遍，才能避免那种只是把症状挪到别处的修复。
从完全限定名称开始。如果 FQDN 能解析而短名称不能，缺口在后缀或搜索列表，而不在服务器地址。
第二步直接用任何已安装的解析工具向目标服务器发查询。直接应答证明该服务器可达并对该区域具有权威。它无法证明应用程序默认向哪台服务器提问。
认清掌管连接的那个组件
常见的有两种安排。从终端启动的客户端会显式传入脚本路径，所以归属者在实际运行的命令里就能看到。打包好的应用程序替你启动客户端，并把助手放在自己的目录里，这意味着何时更换由供应商决定。
替换任何东西之前，先比较不同安装之间的助手版本。只因为文件名看着眼熟，就把从镜像取来的助手以提升的权限运行，会把 DNS 缺口变成安全事件。
一旦知道归属者，修复目标就清楚了：启动器里受支持的脚本路径、更新软件包，或修正网关上的配置文件。这些都不需要手动编辑适配器属性。
修归属者，不是修适配器
手动设置的适配器 DNS 常常在断开后仍然保留，所以它看起来有效，然后在下一个网络上制造麻烦。把公共解析器硬塞到每个接口上，只会掩盖私有命名空间问题，而不是解决它。如果助手从未收到 DNS 值，该看的是网关配置。如果它收到了，而适配器仍显示旧服务器，说明助手在连接过程中失败了，客户端日志通常会在隧道建立相关的行附近记录这一点。
通过受支持的路径重建状态，然后验证完整循环：连接、解析私有 FQDN、打开服务、断开，并确认适配器带着原先的服务器恢复。
检查真正出问题的那个应用程序
自带加密 DNS 设置的浏览器会忽略以上全部内容，继续从公共解析器获得答案。持有隧道建立之前的否定缓存应答的应用程序也一样。再次修改解析器地址之前，先把它与同一台机器上的普通系统查询作对比。
如果系统查询正确而应用程序不正确，剩下的故障在该应用程序自身的 DNS 配置里，而不在 VPN 路径上。