Pritunl 的私有 DNS 失败？添加一条狭窄的解析器路由

私有名称在公司网络上对所有人都能解析，而在 VPN 上对所有人都会超时。解析器应答网关，到它的路由存在，查询却始终收不到回复。缺的不是另一个公共解析器或更宽的路由：缺的是私有 DNS 服务器愿意应答的源地址。

确认解析器正在拒绝你的客户端地址池

先证明故障与来源有关，而不是可达性。从已连接的客户端直接查询私有解析器，观察请求是超时还是以拒绝形式返回。dig @10.40.0.53 intranet.example.net +time=2 +tries=1 超时，而从网关发出的同一查询成功，说明解析器上存在访问策略。SERVFAIL 回复则完全指向别处，通常是区域或上游转发器。

测试前记下客户端地址。客户端上的 ip -4 addr show tun0，或控制台显示的租约，会告诉你解析器看到的是哪个地址池。

然后确认路径存在。把解析器地址送入隧道的路由是先决条件，不是修复方案；如果数据包从未到达，来源策略根本不会被检查。在客户端上用 ip route get 10.40.0.53 检查它。

添加一条主机路由，而不是翻译整个网段

Pritunl 的私有 DNS 指南描述了这个狭窄的做法：为解析器地址添加一条启用 NAT 的 /32 路由，并把该地址选为客户端 DNS 服务器。这条路由只改变解析器在 DNS 流量中看到的来源。应用流量仍然保留你为其选择的来源保持设计。

在检查现有路由是否重叠之后，通过服务器支持的路由所有者来配置它。上例中目标是启用 NAT 的 10.40.0.53/32，客户端地址池保持 10.90.0.0/24。不要为了修一个服务而翻译整个私有网段，因为每个依赖客户端真实地址的下游策略都会开始看到网关。在测试查询期间查看解析器的查询日志，确认它实际收到的地址。单靠一条主机路由无法证明翻译或权限。

解析器仍须在 UDP 和 TCP 上允许翻译后的来源，其回复也必须能够返回。改变来源无法创建缺失的区域或记录。

判断查询是由服务器还是客户端发出

Pritunl 还记录了与 VPN Client DNS Mapping 绑定的 DNS 代理安排，由服务器代表客户端转发上游查询。在该模型中，上游来源属于服务器自身的网络环境，客户端侧的例外是错误的修复。

在添加任何东西之前，先确定哪种模型在生效。三种重叠的修复，即代理、客户端解析器覆盖和手动 NAT 脚本，通常意味着没有人确定过：哪个组件应该发出查询。同时检查 bootstrap：私有专用解析器不可能是隧道建立前找到端点的唯一方式，永久的解析器修改也不应该比连接活得更久。

测试私有查询，而不是公共网页

应用更改并重新连接后，检查客户端实际生效的解析器配置，然后解析一个你知道只存在于私有区域的名字。不带显式服务器的 dig intranet.example.net 显示客户端实际使用什么。随后向该查询返回的地址发送请求，因为解析和服务访问是两个独立步骤。通过 DNS-over-HTTPS 加载公共网站的浏览器，无法证明操作系统的私有解析器路径。公共辅助解析器也不是内部区域的权威。

把解析器地址、/32 路由和客户端 DNS 设置一起记入服务器笔记。只恢复其中一半，就会重现原来的故障。

最后，确认 DNS 成功后隧道仍然把应用目标路由出去。路由、服务访问和身份验证仍然与名称解析无关，一次可用的查询说明不了吞吐量。如果私有页面很慢但能解析，说明解析器完成了它的工作，问题转移到了路径上。