隧道建好之后,最后一步通常是一个能直接用的名字,而不是你粘贴进书签的地址。一条 dnsmasq 主机记录,加上客户端能访问的解析器地址,用两个文件、不要组播就能做到。真正需要斟酌的决定更窄:客户端是把所有 DNS 都发往家庭解析器,还是只把 home.arpa 之下的名字发过去?以下内容都假定已有获批的 WireGuard 配置、一台 Linux 客户端,以及一台由家庭管理员维护的实验室解析器。

把解析器交给客户端的三条路径

ApproachScopeCost
DNS = in the wg-quick interfacethe client's general DNS while the tunnel is upevery name in the house now depends on the tunnel
Platform split-DNS for home.arpaonly that suffixmore configuration per client platform
Manual dig @resolverone query at a timefine for testing, useless for applications

对偶尔接入隧道的笔记本,分离式 DNS 是更好的默认选择:常见互联网域名仍然留在机器本来就信任的解析器上。对专门用来访问家庭服务的机器,把解析器推下去更简单,作用范围的代价也无所谓。

在拥有该区域的解析器上发布记录

写配置之前先把角色分开:VPN 客户端地址、解析器和服务是三台各司其职的不同主机。本实验室里分别是客户端的 10.77.0.2、dnsmasq 的 192.168.50.53 和 NAS 的 192.168.50.20,隧道负责路由家庭 LAN。

listen-address=127.0.0.1,192.168.50.53
bind-interfaces
local=/home.arpa/
host-record=nas.home.arpa,192.168.50.20

host-record 一行给出地址,local= 一行则把未知的 home.arpa 查询留在本解析器内,而不是转发到上游。先读现有配置,把已经定义服务器、接口或同一本地域的内容全部对齐;在冲突配置上再叠一段,只会得到一个能正常加载却答错的解析器。dnsmasq 手册对这两条指令和监听控制都有定义。

然后验证正在运行的服务,而不是文件。配置测试加一次重启是最低要求,真正有效的答案是查询返回的结果。

路由解析器,而不只是网页

WireGuard 的 AllowedIPs 决定哪些目标进入隧道。如果解析器地址落在范围之外,查询就会走普通路由,根本到不了 dnsmasq,即使 NAS 本身可以访问。把解析器地址或包含它的 LAN 前缀加进去,并检查对端网关的转发策略。

允许来自已授权隧道范围的 UDP 和 TCP 53 端口,并保证有回到客户端隧道地址的回程路径。不要为了便于测试而从 WAN 转发 53 端口:家庭宽带上的开放递归解析器几小时内就会被人找到。绑定到某个接口本身并不是访问控制策略。

先验证答案,再看应用

先直接问解析器,再问系统,最后问应用。每一步隔离链条上的一环,它们之间的差异就是诊断结论。

dig @192.168.50.53 nas.home.arpa. A
dig +tcp @192.168.50.53 nas.home.arpa. A
getent ahostsv4 nas.home.arpa
curl -sS --max-time 5 http://nas.home.arpa/ -o /dev/null -w '%{http_code}\n'

值得运行 TCP 查询,因为被截断的 UDP 应答会强制重试,而丢弃 TCP 53 的策略会造成看似时断时续的故障。getent 这一步显示机器解析器配置实际做了什么,而它并不总是你推送下去的东西。

决定隧道断开时怎么办

如果客户端的通用 DNS 指向 192.168.50.53,那么隧道没起来时所有域名解析都会停摆。这在只靠隧道才有用的机器上可以接受,在还要连咖啡馆 Wi-Fi 的笔记本上则不可接受。分离式 DNS 完全绕开这个问题,因为只有 home.arpa 的查询依赖家庭解析器。

记住这个名字是什么:home.arpa 保留给住宅网络使用,并不全局唯一,所以别的网络完全可能合法地使用同一个名字。它只是本地便利,不是可靠的标识。服务迁移时保持记录最新,实验室退役时删掉解析器策略,而不是留下一台笔记本指向一个只能通过已不存在的隧道才能访问的地址。

相关文章