让 DNS 只走自家 VPN 解析器：一步步走通

从你输入域名的瞬间开始，跟着一次名字查询走一遍。浏览器问操作系统，操作系统问它策略选中的解析器，查询就从某块网卡、某种传输方式离开了设备。你的 VPN 设计说：应答应当来自指定的解析器、走指定的路径。这两句话之间的落差，正是你要配置、然后强制执行的东西。

第 1 步：把解析器和路径写清楚

动防火墙之前先写下三件事：解析器地址、你预期的协议与端口、以及查询应当从哪块网卡出去。没有这份清单，规则只是对流量的一种猜测，而不是对某个决定的执行。VPN 可以承载应用数据，同时让 DNS 走另一套安排，这本身并不是错误。它只是没人告诉客户端别的事情时会出现的状态。

把路径明确写出来，是设计与意外的分界线。它也给你留下了日后可测的东西，因为每一条观察都能和写下来的预期对照。把这份清单放进变更单，而不是留在谁脑子里。

第 2 步：把策略放在它真正生效的地方

解析器的选择属于客户端：操作系统的网络配置、VPN 客户端自己的设置，或受管的浏览器策略。先在那里设置，用平台支持的机制，因为防火墙没办法强迫客户端去选一个从没被告知过的解析器。在分流隧道客户端上，要明确写出哪些域名走内部解析器。在受管机群里，浏览器策略往往是 DoH 唯一的杠杆，因为浏览器可以不受系统设置约束，自己挑一个加密解析器。

跳过这一步直奔防火墙，你会得到一条允许正确解析器的规则，外加一个根本不使用它的客户端。规则看起来是对的，解析器日志却一直空着，这种组合最难排查。先配置好选择，再去强制执行。

第 3 步：把路径收窄再执行

现在为允许的路径加上网络许可：解析器地址、协议与端口，以及应当走出的网卡。把规则限定在那一个解析器上，而不是放行全部出站 DNS。下面三条路径是现代客户端可能走的路，而 53 端口规则只覆盖第一条。

封掉 DoH 和 DoT 是正当的；假设 53 端口规则已经把它们封住了则不是。走 DoH 的浏览器会沿一条你的规则从未描述过的路径解析名字，自带解析器的应用也一样。把你打算放行的每一条路径、打算拒绝的每一条路径都写下来。不点名路径的规则，等于没有对它做出决定。

第 4 步：同时盯住内部名和公网名

分流 DNS 有意只把内部命名空间送去内部解析器，公网名则走别处，所以设计里出现多个解析器并不等于泄漏。泄漏是：本该去你那台解析器的查询落到了别处，或者本该走的路径不可达，客户端悄悄回退。这两种情况才是要查的。在既定策略下分别跟踪一个内部名和一个公网名，记下各自由哪台解析器应答。

会报告你所用解析器的测试站点只是线索，不是证据，因为它只看得到到达它的查询。需要知道查询实际走了哪条路时，在客户端一侧抓包，再把两边观察对照起来。两边对不上，你就找到了没人记录的静默回退。

如果解析器地址没错却不可达，问题在路由或过滤，而不是策略。把查询追到那个地址，确认应答从预期网卡返回，再动解析器设置。

第 5 步：给自己留一条回来的路

收紧网关的 DNS 访问之前，先确认一种不依赖域名解析的恢复手段。解析器一旦坏掉，任何修复工具都更难够得着，包括你用来回滚这次变更的那些。在新策略被证明可用之前，保留本地控制台或带外通道。等策略熬过一次重连之后，再把它撤掉。

重连或浏览器策略更新之后，要重新检查实际生效的状态，因为这两者都可能在不改你规则的情况下换掉解析器。要求是：查询有已知的接收方、有受保护的路径，而不是一张截图里让人安心的解析器标签。RFC 8484 的 DNS over HTTPS 规范正是你的端口规则看不见的那条加密路径的依据。