OPNsense 构建 DNS 管控体系 – 鐵血男兒的Blog

在局域网部署 AdGuard Home、Pi‑hole 等本地 DNS 过滤组件后，多数使用者会默认局域网内所有终端均会遵循 DHCP 服务所下发的 DNS 解析配置，但实际网络运行环境中该假设并不成立，部分智能终端内置公共 DNS 服务器地址，浏览器可启用 HTTPS 加密 DNS（DoH），移动端设备与各类应用程序亦可通过 TLS 加密 DNS（DoT）机制，绕过局域网内部的本地解析链路。仅仅依靠 DHCP 选项分配 DNS 服务器地址，无法实现完整的局域网 DNS 管控。完整的解决方案，需要将 DNS 过滤、递归解析服务与防火墙访问控制策略相结合，同时也要认清该方案的能力边界和潜在副作用。

DNS重定向

针对终端直接访问 223.5.5.5、223.6.6.6 等外部公共 DNS 服务器的场景，可在 OPNsense 防火墙的目标 NAT 模块配置规则，将局域网 LAN 接口发出的 TCP、UDP 53 端口流量强制重定向至 AdGuard Home 服务。

接口：LAN
协议：TCP/UDP
源：LAN net
反转目标：启用
目标：防火墙本机
目标端口：53
重定向目标：AdGuard Home服务地址
重定向端口：53

如果 AdGuard Home 独立部署于局域网内其他主机，则需通过源地址匹配或地址别名排除该主机自身流量，避免 AdGuard Home 向外访问 53 端口时触发重定向规则，引发流量环路。若 AdGuard Home 仅转发解析请求至 OPNsense 上 Unbound 的 5353 端口，则不会匹配该 53 端口重定向规则。

同时需要分别完成 IPv4 与 IPv6 两套规则配置；防止在仅处理 IPv4 环境时，开启 IPv6 的终端仍可通过 IPv6 链路实现 DNS 绕过。

DoT阻断

DNS over TLS（DoT）标准服务端口为 TCP 853；依据 RFC 9250 规范，专用链路下 DNS over QUIC（DoQ）默认使用 UDP 853 端口。可以在 LAN 接口防火墙规则中，拒绝局域网终端对外建立 TCP/UDP 853 端口连接。

动作：阻止
接口：LAN
协议：TCP/UDP
目标：任意地址
目标端口：853
备注：阻断标准端口下DoT与DoQ服务

该规则逻辑清晰明确，对于需要使用加密 DNS 的终端，可以配置对应的放行例外。

端口阻断

UDP 443 端口主要承载 QUIC/HTTP3 协议流量，部分加密 DNS 服务也使用该端口。全局封禁 UDP 443 端口，浏览器会降级使用 TCP 443 的 HTTP/2 协议，但代价是整个局域网将丧失 HTTP/3 访问能力。

因此该规则不属于必选配置。建议结合防火墙日志与业务实际运行情况评估方案，可选择全局禁用、仅针对非可信 VLAN 生效，或保留 HTTP/3 协议。即便封禁 UDP 443，也无法拦截运行于 TCP 443 之上的常规 DoH 流量。

DoH阻断

1、域名黑名单

绝大多数 DoH 客户端，仍需要先完成 DoH 服务域名解析。可在 AdGuard Home 过滤器中引入维护完善的加密 DNS 绕过防护列表，例如 HaGeZi 项目下 DoH/VPN/TOR 相关域名列表，并开启自动更新。

AdGuard Home → 过滤器 → DNS黑名单 → 添加黑名单
https://raw.githubusercontent.com/hagezi/dns-blocklists/main/adblock/doh.txt

该方式能够有效拦截主流浏览器与应用程序的 DoH 请求，但无法处理直接连接硬编码 IP 地址的终端，同时也不能覆盖用户自建的私有 DoH 服务。

2、IP 黑名单

在 OPNsense 防火墙别名管理模块，新建URL Table (IPs)类型别名，拉取已知 DoH 服务端 IP 地址集合：

别名名称：DoH_Servers
类型：URL Table (IPs)
URL：https://raw.githubusercontent.com/hagezi/dns-blocklists/main/ips/doh.txt
刷新周期：每日

完成别名创建后，配置 LAN 接口防火墙规则，拒绝终端访问DoH_Servers别名内的地址。URL Table 会按预设周期自动更新，适配服务 IP 频繁变动的场景。

注意：基于 IP 地址的阻断会作用于该 IP 上全部业务流量，而非仅 DNS 相关会话。若该 IP 同时承载普通网站、CDN 节点或者业务接口，极易产生误拦截。

终端管控

对于可接管的计算机终端，优先通过浏览器或者系统组策略禁用外部 DoH 功能，相比大范围 IP 封锁具备更高稳定性。建议将局域网终端划分为两类：受管理终端通过系统、浏览器策略完成统一配置；IoT 设备、电视盒子等不可管控终端，部署至独立 VLAN，依托 NAT 与防火墙规则实施强制访问约束。该划分模式便于故障定位，降低对正常业务的负面影响。

存在限制

本套机制在以下场景无法实现防护：

VPN 与代理隧道：DNS 查询报文被封装于隧道内部，网关无法解析识别原始 DNS 请求；
私有 DoH 服务：部署于任意 VPS 实例的自定义 HTTPS 解析端点，公开防护列表无法实现完整覆盖；
业务地址复用场景：加密 DNS 服务与正常业务部署在同一域名或 IP，阻断策略会直接造成业务失效；
防护列表过期：服务商变更 IP 与域名，防护列表需要定期刷新，持续观测误报与命中情况；
IPv6 旁路风险：IPv4 防火墙规则不会自动同步至 IPv6，双栈网络需要独立验证。

检查测试

在客户端手动指定外部公共 DNS 服务器发起解析请求，确认查询报文能够出现在 AdGuard Home 运行日志；
测试 TCP 853、UDP 853 端口连通性，确认外部 DoT、标准端口 DoQ 连接被成功阻断；
核查浏览器安全 DNS 运行状态，确认受管理终端策略生效；
查阅 OPNsense 防火墙日志，确认 DoH 相关规则存在命中记录，且不存在常用业务误拦截；
分别针对 IPv4、IPv6、IoT 隔离 VLAN、访客网络开展测试，避免仅通过单台终端得出结论。

局域网 DNS 防护无法依靠单条防火墙规则实现。最优实践为组合使用 53 端口流量强制重定向、853 端口访问限制、DoH 域名黑名单过滤、已知 DoH 服务 IP 阻断，叠加终端系统与浏览器管控策略。全局封禁 UDP 443 属于高影响可选策略，需要结合网络业务需求审慎启用。本方讨论的方案，并非对抗刻意绕过网络管控的用户，而是使浏览器、应用程序、IoT 设备的默认网络行为，回归可观测、可过滤的本地 DNS 解析链路。

发送评论编辑评论

推荐方案