分离 DNS 与 VPN：域名规则不是 IP 路由

你的笔记本通过隧道解析 intranet.corp，而 gitlab.com 继续走运营商解析器，这正是按设计工作的安排。它来自两个彼此独立的决定：一条名称匹配规则选定了解析器，一条路由把答案带了回来。破坏其中任何一个，浏览器就会显示从外面看完全相同的故障。多数分离 DNS 的报告在描述第二个故障时，引用的却是关于第一个故障的证据。

两半分处不同位置，通常也由不同的人编辑。一半是挂在 VPN 配置文件上的 DNS 策略，另一半是隧道安装或保留的路由。当没有人确认到底是哪一半动了，排查就会卡住。

一个请求里的两个决定

名称那一半是策略对象，不是路由。在 Windows 上是 VPN 配置文件上的名称解析策略；在 Apple 平台上是 DNS 设置对象上的一组匹配域；在 Linux 上是路由域、分离解析器行或名称服务切换顺序。路径那一半是普通路由，由隧道或手工安装，它根本不知道主机名是什么。一个允许后缀的配置文件只决定谁来回答，从不让答案变得可达。

一个快速症状测试能把两者分开：用地址替换名称。地址能用，说明路径没问题、规则错了。地址也不能用，说明规则可能对、路径缺失。

每个平台如何表达同一条名称规则

意图相同，字段名不同。从一个客户端复制到另一个的示例能干净地解析，却永远匹配不上。三种形态是这样的：

匹配域或路由域是后缀测试，所以 intranet.corp 涵盖 git.intranet.corp，不涵盖 corp.intranet，把它写反是整个配置里最常见的错误。Windows 把映射作为挂在配置文件上的名称解析策略，并带有自己的优先级顺序，与该接口原有的后缀列表竞争。Apple 平台把匹配域挂在网络扩展的 DNS 设置对象上，系统按每个限定作用域的解析器应用。这些形态都不是路由，也都不能让不可达的地址变得可达。Windows 名称解析策略参考列出了该平台的字段名和优先级规则，而这些并不是 Apple 或 systemd 文档所用的那一套。

正确的答案仍然需要路径

解析器的答案只是一个地址，应用仍然必须到达那里。分离隧道设计常常推送 10.20.0.0/16 并保留默认路由，于是内部名称解析成功，连接随后卡住。相反的情形同样常见：路由存在，公共解析器对私有名称回答 NXDOMAIN，故障被记成路由问题。先测路径会让你盯着路由，去查一个根本不会解析的名称。

还有第三道门，两半都不覆盖。网关上的 ACL、防火墙规则或客户端策略，都可能在两个决定都正确之后丢掉连接。名称解析了、路由存在、连接仍然超时，那就别测 DNS 了。

按固定顺序测试名称与路径

选一个顺序并坚持下去，否则你会在追上一个刚失败的步骤。解析文档中给出的完整内部名称，确认答案是一个路由表能承载的地址，然后用公共名称重复一遍，证明隧道没有把一切都抓走。在 systemd 主机上，查询与解析器的路由域只差一条命令：

resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10

Windows 客户端用另一组 cmdlet 问同样两个问题。第二条报告系统实际会使用的接口：

Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10

如果查询返回地址、路径检查指名物理接口，那么名称规则生效了，路由没有。如果短名称失败而完整名称解析成功，错的是后缀列表，不是解析器。

比较通常在哪里出错

第一个错误是拿无关的公共解析器去问私有名称，再把拒绝当作关于 VPN 的证据。第二个是以为公共查询能用就证明了隧道的解析器路径。第三个是把分离隧道和分离 DNS 当成同一个设计决定，而部署完全可能一个对、另一个坏。每种错误都会从一次从未触及被指责部分的测试里得出自信的结论。

带自己安全 DNS 的浏览器也能绕过系统规则，所以一个浏览器失败、另一个成功并不矛盾。要比的是回答的解析器，不是抱怨的浏览器。

两半都可见之后，剩下的问题是策略问题而不是技术问题：哪些命名空间属于组织，每条答案由谁负责，其中哪些根本不该离开机器。把它写在配置文件旁边，因为下一个碰到这条规则的人会需要它。