哪条链路应答：分离隧道 VPN DNS 的路由域

让普通浏览留在本地链路上，公司名称则通过隧道提供的 DNS 服务器解析。关掉 VPN 的默认路由只能拿到前半段，后半段仍未建立。下面要讲的是缺失的那项设置、会改变其含义的标点符号，以及唯一能显示哪条链路真正应答的命令。全文假定使用 NetworkManager 和 systemd-resolved，因为混乱通常就从这对组合开始。

第一步：把路由与解析器分开

ipv4.never-default 回答的是路由问题，阻止 NetworkManager 把此连接安装为所有 IPv4 流量的通道。DNS 路由域回答的是另一个问题：匹配后缀的查询会送到哪条链路的名称服务器。两者互不蕴含，一个配置文件可能多年只带其中一个而缺少另一个。仅路由意味着隧道承载公司子网、其解析器回答公司名称，其余一切保持原样。

只设置路由属性，内部名称就会失败，通常表现为看起来像隧道故障的超时。只设置域名，你就悄悄给机器上每个短名称加了一个搜索后缀。两种错误都会把工单送到 VPN 服务器，而那里很少是出错的地方。

第二步：向配置文件添加仅路由域

假设连接名为 corp-vpn，公司后缀是 internal.example，隧道的解析器已可达。先读取当前值，因为下面的命令会修改可能已有条目的属性。

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

换成你自己的连接名和后缀，因为上面的值只是示例。加号比看上去更重要：带上它，值会追加到现有列表；不带它，属性会被替换，昨天还能用的配置文件里不相关的域会消失。波浪号改变的是行为而非风格，下面一段说明它选择什么。保持先读后写，免得替换形态让你意外。

开头的波浪号标记仅路由域，因此匹配的查询会送到该链路的服务器，后缀也不会附加到短名称上。去掉波浪号，同一字符串也会变成搜索后缀，这是人们很少想要的结果。上面两项设置都是 IPv4，所以双栈配置文件还需要 ipv6.never-default，并在 ipv6.dns-search 中加入同一个路由域，否则 IPv6 一侧仍使用默认路由，那里内部名称就会失败。

第三步：让 resolvectl 告诉你哪条链路应答了

运行 resolvectl status，读取每条链路的 DNS 服务器和域，然后对一个你获准查询的真实内部名称运行 resolvectl query host.internal.example。第二条命令是路由域确实在起作用的唯一直接证据，因为它会指出应答的链路。仅状态列表只能证明配置，查询才能证明解析。

systemd-resolved 会选择最匹配的路由域，因此另一条链路上更具体的域仍可能赢得竞争。如果查询来自你未预料到的链路，先读域列表再动 VPN 的 DNS 服务器。根域 ~. 匹配一切；若它已存在，你的具体域在自身名称上仍然胜出，而链路应答的范围远大于你所要求的。当目的只是公司名称时，删除或收窄那条根条目。

如果 VPN 链路完全没有列出 DNS 服务器，客户端就从未注册过。背后没有服务器的路由域与缺失域的失败方式不同，所以要先修好注册。

第四步：名称能解析但服务不通时

正确的应答只能证明解析成功，应用仍需要一条通往所获地址的路由。这条路由必须穿过你刚配置的分离默认路由，所以在再次责怪 DNS 之前先检查它。然后检查服务端口是否可达，因为文件共享或目录服务会在解析、路由或认证环节失败，每种情况给出的信息都很相似。报告结果时把这三层分开，否则下一个人会重新检查本就正确的 DNS。

与这个问题一起流传的 Samba 改动针对的是访问层，而不是 DNS 的选择。把它套用到名称解析故障上，就是小问题变成第二个问题的方式。

第五步：不要为了修复缺失的域而替换解析器

覆盖解析器文件或安装另一套解析器管理器的建议解决的是另一个问题。那些是系统集成层面的改动，各有自己的故障模式，没有一项会添加从未配置过的路由域。替换之前先确定机器上名称解析归哪个组件所有，因为在带 systemd-resolved 的 NetworkManager 桌面上，这个归属已经定义好了。与它对抗，正是让原本可用的配置变成无人能复现的东西的方式。

工作顺序：确认隧道提供解析器，添加仅路由域，通过配置文件控件重新连接，验证应答的链路，最后在其端口上测试服务。这个顺序留下的结果可以交接给下一个人，而无需二次询问。