你的分离隧道能到达应用，却到不了它的 DNS 服务器

路由应用的子网是分离隧道显而易见的部分，但并不是全部工作。解析器常位于与其所服务应用不同的地址上，因此一条能工作的隧道仍可能把查询留在隧道之外。只承载 10.80.0.0/16 的配置文件会把发往 10.90.0.53 的查询从本地接口送出，而那里并不存在私有区域。加上通往解析器的那条路由，然后看问题的另一半：客户端实际选择哪个服务器。

误区：一条路由覆盖整个服务

分离隧道是经由连接的目的地列表，不是对服务的描述。应用子网和解析器地址是两个目的地，配置文件可以只带其中一个。当这种情况发生时，应用按地址可达，但名字解析失败，看起来像 DNS 故障而不是路由缺口。

解析器周围的子网也不会被自动覆盖。到单个地址的主机路由对该解析器够用，但不会打开它的邻居。主机路由的意义正在于此：设计上很窄，而且当下一个服务出现在同一子网时很容易被忘记。

查询要能工作，必须同时满足三件事：客户端把解析器地址经由隧道路由，网关接受并转发该请求，解析器接受它收到的源地址。应答也必须沿约定的路径返回。缺任何一条，症状都一样，所以在动配置之前值得先把地址表写下来。

确定配置文件必须承载哪些地址

按顺序列出目的地：应用网络、解析器地址，以及终止隧道本身的公网端点。第三个绝不能被路由进隧道，因为外层连接需要一条在隧道之前就存在的路径。

为 DNS 同时包含 UDP 和 TCP，因为实现应当同时支持 UDP 与 TCP，而被阻断的 TCP 路径产生的是缓慢的、部分失败，而不是干净的失败。如果私有区域也通过 IPv6 提供服务，等价的主机例外要使用 IPv6 地址和前缀，并且是单独的条目。

在添加任何内容之前，先记录配置文件已覆盖的范围。重复的路由无害，但一条意料之外的现有路由说明该配置文件是为与你拿到的不同的地址规划而设计的。

通过连接的所有者添加主机路由

对于本地管理的原生 Windows 配置文件，路由属于连接而不是机器的全局路由表。先预览这次添加，然后用配置文件所用的同一范围应用它。

Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf
Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes

第一条命令在不安装任何东西的情况下预览改动，第二条列出配置文件当前承载的路由。Microsoft 的 Add-VpnConnectionRoute 参考文档记录了按用户和所有用户的范围；所有用户的配置文件需要自己的范围参数，而针对所有用户配置文件的按用户命令会失败或落到错误的位置。

当配置文件由外部管理或来自厂商客户端时，改动属于那个所有者。把一条永久系统路由叠在连接策略之上，能一直工作到策略被重新应用、路由消失为止，而这通常发生在支持通话中而不是测试时。这种失败是无声的：路由消失，名字不再解析，却没人把两件事联系起来。把改动放进所有者自己的记录里，这样下次重新应用会带上它而不是抹掉它。

应用之后要重新连接配置文件，而不是假设路由已经生效。活动连接上的路由改动不一定会被采纳，重新连接也会复现用户实际会遇到的状态。

检查客户端实际使用了哪个解析器

路由控制的是发往解析器的数据包。它不决定哪些名字应该发往那里，那个选择是另一套机制。在 Windows 上，生效的命名空间规则可以按域选择解析器，而配置文件的 DNS 设置提供默认值。这两层可以不一致而不报任何错误，所以直接查询只是一半证据。

Get-DnsClientNrptPolicy
Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A

第一条命令打印当前生效的命名空间策略，第二条直接向私有解析器查询应用名。直接得到回答证明路径和解析器工作；它并不证明应用自身的查询选择了那台服务器。把它与同一名字的普通查询、以及应用实际收到的回答作比较。

要考虑缓存以及浏览器层面的安全 DNS，后者可能对用户输入的名字完全绕过系统解析器。搜索后缀是另一个误导线索：它把短名扩展为完全限定名，与哪台服务器应答毫无关系。

最后重新连接并重复普通查询，然后确认日常浏览仍然遵循其已批准的策略。为了让一个无关名字解析而把私有解析器换成公共解析器不是修复，它只会悄悄把私有查询送到它们从不该去的地方。