如何在网关上正确地把 DNS 请求路由到 TUN?

最近把 OpenWRT 网关上的分流工具从 Clash 切换到了 sing-box ，顺带开始了解基于 TUN 的透明代理配置。目前遇到的一个问题是，局域网内的 DNS 请求并没有被正确地路由/转发进 sing-box 的 DNS 模块。

具体的情况有点复杂。因为需要让家里运行着 PT 的 NAS 这类的设备不被透明代理，所以在配置 TUN 时并没有使用 auto route，而是自己编写了 nftables 规则和对应的 ip rule/ip route 策略路由，将需要代理的设备的流量标上一个特定的 fwmark ，再将标记的流量策略路由到 sing-box 的 TUN 网卡 tun0 。简化后的设置类似这样：

# 在 nftables 的 prerouting 阶段标记需要被代理的流量：
type filter hook prerouting priority mangle - 1; policy accept;
# 1. 需要直连的设备 MAC 被提前存在 direct_macs set 中，不做额外处理直接放行
ether saddr @direct_macs counter return
# 2. 剩余的来自 LAN 的流量均需要代理，标记为 $tun_mark (0x02)
iifname $lan_devices counter meta mark set $tun_mark

之后配置策略路由：

# 将被标记了 tun_mark 的流量查 tun_table 表路由至 tun_dev
ip route replace default dev ${tun_dev} table ${tun_table}
ip rule add fwmark ${tun_mark} table ${tun_table}

至此整个系统可以正常工作了。但奇怪的是，只有指定了 DNS 服务器为非网关地址 (≠ 192.168.50.1) 的局域网内 DNS 请求才会被转发进 TUN ，而默认的、DNS 服务器地址为 192.168.50.1 的 DNS 请求并没有被 sing-box 看到，而是仍由监听在网关 53 端口的 dnsmasq 处理：

# 在局域网内的任一台被透明代理的设备上：
nslookup google.com         # 这条查询会被 dnsmasq 接收
nslookup google.com 1.1.1.1 # 这条查询才会被正确地路由进 sing-box 的 TUN 设备

请问大家是不是我配置的策略路由在哪里出问题？多谢

CrazyRundong

343 天前

目前的临时解决方案是在网关 sing-box 上再开一个 TProxy 端口，借助 TProxy 可以处理 UDP 请求的特性，把来自 LAN 的 TCP/UDP 53 流量通过 nftables 规则 TProxy 到这个端口。但感觉还是搞得太繁琐了，应该没必要这么麻烦
```
# 增加了一条 nftables 规则来 TProxy 来自局域网的 DNS 请求
iifname $lan_devices meta l4proto {tcp, udp} th dport 53 counter meta mark set $tproxy_mark tproxy to :$tproxy_port
```
（需要配置对应的额外策略路由）
```
ip route replace local default dev lo table ${tproxy_table}
ip rule add fwmark ${tproxy_mark} table ${tproxy_table}
```