LAN 主机名在 VPN 上解析失败：后缀、mDNS 还是区域？

在设备旁边，打印机响应短名称，文件服务器响应昵称。穿过隧道后，两个名称都超时，而它们的地址仍然可用。路由在履行职责；让那些短名称生效的命名路径从未跨过隧道。产生这种现象的机制有三种，每种都需要不同的修正。

先弄清名称依赖的是哪种机制。

三种行为不同的名称

像 fileserver 这样的单标签名称，通常依赖解析器附加的 DNS 搜索后缀。该后缀往往随本地 DHCP 租约一起下发，因此从 VPN 获取地址的远程客户端没有理由知道它。添加路由并不会传递后缀。短名称干脆不再作为名称存在，尽管它背后的地址仍然可达。

以 .local 结尾的名称，通常在本地链路上通过多播 DNS 解析，正如 RFC 6762 所述。多播不会跨越被路由的隧道，除非有东西刻意为其桥接或代理，因此一旦离开该网段，名称就不再解析。

完全限定的公司名称属于由组织解析器提供服务的内部区域。当 VPN 推送这些解析器且客户端配置为使用它们时，该名称在远程也能工作。而 localhost 按 RFC 6761 属于特殊用途：它指向你面前的机器，绝不指向远程服务。

改动路由之前先读解析器

询问是哪个名称服务器作出的回答、附加了哪个后缀。同一个查询经过不同解析器会得到不同答案，而这个差异正是你需要的证据。

getent hosts fileserver
getent hosts fileserver.corp.example.com
nslookup fileserver.corp.example.com
dig +search fileserver A
resolvectl query fileserver.corp.example.com
scutil --dns | head -30

如果完全限定查询能解析而短查询不能，故障在后缀而非服务器。如果两者都不能解析而地址可用，说明客户端根本没有使用内部解析器。把解析器列表与 VPN 应当推送的内容作比较，因为对每个查询都保留本地解析器的客户端永远看不到内部区域。

把正确的名称交给客户端

向管理员索取有文档记录的远程访问名称，完整照抄，并在配置文件中使用它，而不是猜测后缀。如果部署支持拆分 DNS，就把内部域配置为由内部服务器解析，其余一切仍走本地解析器。在客户端支持的情况下，通过 VPN 配置推送搜索域。

在客户端而不是网关上验证结果。只在服务器上生效、从未到达客户端的设置不会改变任何东西。

保持证书身份完整

忽略证书错误的基于地址的测试，只能证明套接字打开了。服务证书是按名称签发的，客户端会继续有理由地拒绝不匹配。如果证书只列出内部名称，就使用该名称并修正解析，或者取得覆盖你打算使用的地址的证书。

记录下产生成功连接的名称、解析器和后缀。这份记录能让下一个人不必重复那个掩盖真正问题的基于地址的变通做法。