为什么路由器自身的 DNS 会绕过 VPN 隧道？

客户端的查询走隧道，而路由器自身的查询从 WAN 出去，管住其中一条的防火墙规则对另一条毫无作用。原因并不是缺陷：被转发的请求和路由器自己发起的请求是两条独立的流量，各自对应配置里不同的部分。只抓客户端这一半，会对另一半从不使用的那条路径给出一个很有把握的答案。修法是先把路由器的解析器明确指到该走的地方，再分别测试两条路径。

抓包究竟属于哪一条流量

一次查询包含两次交换。局域网客户端向路由器的解析器发出查询，它作为转发流量从 LAN 接口进来，因此一条为转发包写的策略路由或 NAT 规则可以命中它。随后路由器从缓存作答，若未命中，就向上游服务器发起自己的查询。

这第二次查询以路由器自身为源、也以自身为目的，平台从另一个配置块里为它选路。两次交换携带同一个名字，谁也不复制谁。所以在 LAN 侧抓到的包只能证明客户端那一半去了哪里，对出站的那一半什么也说明不了。

实际检查是两侧同时观察。在路由器上列出解析器的套接字，本地查询它，再抓 WAN 接口：

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

如果套接字列表显示监听绑定在回环或 LAN 地址上，说明路由器是在本地应答，而不是把请求转给另一台主机。这时抓包才能看出由此产生的上游查询是从隧道接口出去，还是从 WAN 出去，而这正是策略路由规则永远给不出的答案。

策略路由为什么永远看不到第二次查询

防火墙规则是针对接口、源、目的和端口写的，评估对象是穿过设备的包。路由器自己发起的查询不穿过任何东西，本地进程直接把它交给路由表。 策略路由与 NAT 因此只作用于转发路径，这也是规则集看着完整、却仍可能把路由器的 DNS 留在隧道之外的原因。

这个区分能经住每一次固件重写，因为它来自包的路径而不是某个功能。设备为自身产生的一切——解析器查询、时间同步、更新检查或软件包镜像访问——都属于本地发起，落在同一个盲点上。这也是从笔记本上做的测试证明不了路由器任何事的原因。

pfSense 的解析器在哪里决定自己的上游路径

pfSense 让这个分离变得可见。客户端流量可以按策略经 VPN 网关走，而防火墙自身的流量遵循解析器的出站设置，而不是 LAN 规则。在 Web 界面里该设置位于 Services > DNS Resolver > Outgoing Network Interfaces 之下，它的值是解析器可用于上游查询的接口列表。

在那里只点名隧道接口、而且只点名它，才是让路由器自身查询跟随隧道的原因。若保持默认，解析器会从路由表里选出口，而在双 WAN 或 VPN 主机上那往往是 WAN。

其他固件用别的名字给出同一个决定：绑定到源地址的上游服务器列表、仅转发模式，或成文的策略路由。要寻找的设置始终是那条为本地发起的查询选择出口或源的设置。 解析器配置参考 记录了 pfSense 的这个选项，改动前值得一读。

先决定故障时的行为，再动设置

隧道掉线时有两种行为站得住脚：停掉上游查询什么也不漏，或退回到已知路径上经批准的解析器。两者都是策略，默认哪一种都拿不到。先决定网络需要哪一种，再碰接口列表。

故障时关闭更容易辩护，但它把隧道中断变成了路由器后面每台设备的域名解析中断。回退保住了办公室可用，代价是隧道之外的一次上游交换，而这次交换必须是有意接受的，不能是碰巧发生。把选择写下来，因为下一个看到 VPN 之外解析器地址的人，除非有说明，否则会把它读成泄漏。正是那份说明，把成文的回退和下个季度复盘中无法解释的发现区分开来。

有两种情况让决定变复杂。私有域名可能需要隧道能够到达的内部解析器，而自带加密 DNS 的浏览器或应用可以完全绕过路由器，所以你配置的解析器并不总是某个应用实际使用的那个。

两条路径都测，结果分开保存

基于浏览器的 DNS 测试只回答一个狭窄的问题：在那次测试的条件下，这个浏览器用了哪些解析器。它既不清点网络中的设备，也看不到路由器为自身发起的查询。把它的输出当作一个数据点，而不是一次审计。

从局域网客户端请路由器解析一个公开名字，再解析一个只应由你内部区域作答的私有名字。只有第二个查询失败，指向的是名字转发，而不是隧道：

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

接下来把隧道降掉，重做这两个查询。被拒绝的应答意味着解析器在故障时关闭；成功的应答指向回退解析器以及它走的路径。把它与你写下的说明、以及同一分钟在 WAN 接口上做的抓包对照。

在记录里把观察分开：客户端与路由器之间的交换、路由器与上游之间的交换，以及决定后者的配置。之后的一次路由变更会在没有任何提示的情况下用到那第二次交换。来自 VPN 终点以外某处的应答本身不是泄漏；只有当配置碰巧选了那条路径时，它才成为泄漏。