在沒有 resolv.conf 的情況下正確地使用 iptables 重新路由 DNS 查詢

我在 127.0.0.1:53 上執行了一個自定義 DNS 服務，我不只是希望所有查詢都通過它，我還希望只有該服務響應。這就是問題所在。我的 NAT iptables 設置：

iptables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to-destination 127.0.0.1:53
iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to-destination 127.0.0.1:53

這裡是我的 tcpdump，ping ya.ru：

[root@localhost ~]# tcpdump -nnSXvv -i any udp
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
18:34:15.974227 IP (tos 0x0, ttl 64, id 20601, offset 0, flags [DF], proto UDP (17), length 51)
   192.168.0.6.54387 > 127.0.0.1.53: [bad udp cksum 0x3fe0 -> 0x2c11!] 58964+ A? ya.ru. (23)
   <data here>
18:34:15.974457 IP (tos 0x0, ttl 64, id 26083, offset 0, flags [DF], proto UDP (17), length 604)
   192.168.0.6.56172 > 77.66.84.233.443: [bad udp cksum 0x6533 -> 0x48f0!] UDP, length 576
   <data here>
18:34:16.028783 IP (tos 0x0, ttl 57, id 7923, offset 0, flags [none], proto UDP (17), length 204)
   77.66.84.233.443 > 192.168.0.6.56172: [udp sum ok] UDP, length 176
   <data here>
18:34:16.029127 IP (tos 0x0, ttl 64, id 12032, offset 0, flags [DF], proto UDP (17), length 78)
   1.1.1.1.53 > 192.168.0.6.54387: [bad udp cksum 0xc2fb -> 0xc42e!] 58964 q: A? ya.ru. 1/0/1 ya.ru. A 87.250.250.242 ar: . OPT UDPsize=1252 (50)
   <data here>
18:34:16.075993 IP (tos 0x0, ttl 64, id 20662, offset 0, flags [DF], proto UDP (17), length 73)
   192.168.0.6.38972 > 127.0.0.1.53: [bad udp cksum 0x3ff6 -> 0x7be2!] 32011+ PTR? 242.250.250.87.in-addr.arpa. (45)
   <data here>
18:34:16.076448 IP (tos 0x0, ttl 64, id 26142, offset 0, flags [DF], proto UDP (17), length 604)
   192.168.0.6.53415 > 77.66.84.233.443: [bad udp cksum 0x6533 -> 0xf1ca!] UDP, length 576
   <data here>
18:34:16.186718 IP (tos 0x0, ttl 57, id 7930, offset 0, flags [none], proto UDP (17), length 268)
   77.66.84.233.443 > 192.168.0.6.53415: [udp sum ok] UDP, length 240
   <data here>
18:34:16.187096 IP (tos 0x0, ttl 64, id 12081, offset 0, flags [DF], proto UDP (17), length 103)
   1.1.1.1.53 > 192.168.0.6.38972: [bad udp cksum 0xc314 -> 0xfa7e!] 32011 q: PTR? 242.250.250.87.in-addr.arpa. 1/0/1 242.250.250.87.in-addr.arpa. PTR ya.ru. ar: . OPT UDPsize=1252 (75)
   <data here>

1. 本地埠 54387 的程序發送請求，並按預期重定向到 127.0.0.1:53

2. 本地自定義 DNS 服務向遠端 DNS 伺服器發送請求

3. 遠端伺服器響應

4. ??? 本地埠 54387 的原始程序收到來自 1.1.1.1:53 的響應 ???

5+) 重複 PTR

這裡發生了什麼以及為什麼發生以及如何在不編輯解析的情況下避免這種情況？總體而言，這不是一個大問題，但來自自定義服務的 DNS 查詢是加密的，而來自 1.1.1.1:53 的響應則不是。

作為參考，目前 resolv.conf 通過 DHCP 租約更新：

1.1.1.1
8.8.8.8

我沒有能力編輯它，因為原始問題是針對 Android 9+ 的，它根本沒有一個地方可以讓你設置 DNS 和快樂。我設法在我的CentOS8設置上重現了相同的情況，所以這個問題應該適用。

上述第 1) 點中的請求是在其中一個預路由鏈中的 DNAT 發生之後看到的。這就是為什麼您看到 127.0.0.1 的目標地址而不是 1.1.1.1 的 ORIGNAL 目標地址。這個數據包在你的解析器上，然後你似乎繼續使用 HTTPS 上的 DNS。

當從本地解析器返回的響應被發送回請求者時，它也通過 NAT。此 NAT 將確保響應的 SOURCE 地址是請求的 ORIGINAL DESTINATION 地址。這就是為什麼您在上面的第 4) 點中將 1.1.1.1 視為源地址的原因。

基本上 NAT 發生在兩個地方：

1. 它根據您提供的規則修改 OUTGOING 數據包。
2. 它還修改 INCOMING 數據包以恢復上述修改，並確保返回數據包與“發起”節點處的正確套接字正確匹配。

引用自：https://serverfault.com/questions/1019898