iptables重定向DNS查找IP和端口

21

我发现我的ISP（verizon）正在拦截端口53上的所有DNS通信。

我想使用iptables将所有DNS查找流量重定向到特定的IP和端口（5353）。我的计算机在端口53上连接到另一台计算机的任何尝试都应重定向到23.226.230.72:5353。

为了验证我要使用的DNS服务器和端口，我已经运行了此命令。

~$ dig +short serverfault.com @23.226.230.72 -p5353
198.252.206.16

这是我要使用的iptables规则。

iptables -t nat -A OUTPUT -p udp -m udp --dport 53 -j DNAT --to-destination 23.226.230.72:5353

添加该规则后，未找到所有DNS查找。网站ping返回unknown host。网页上说“找不到服务器”。

~$ mtr serverfault.com
Failed to resolve host: Name or service not known

我希望从23.226.230.72:5353提取DNS查询。如何使iptables规则起作用？

编辑

我的ISP演示了DNS（端口53）拦截。跟踪从dig的输出通过端口5353到端口23.226.230.72，然后通过端口53。

~$ dig +trace stackexchange.com @23.226.230.72 -p5353

; <<>> DiG 9.9.5-3-Ubuntu <<>> +trace stackexchange.com @23.226.230.72 -p5353
;; global options: +cmd
.           86395   IN  NS  ns7.opennic.glue.
.           86395   IN  NS  ns4.opennic.glue.
.           86395   IN  NS  ns3.opennic.glue.
.           86395   IN  NS  ns5.opennic.glue.
.           86395   IN  NS  ns2.opennic.glue.
.           86395   IN  NS  ns10.opennic.glue.
.           86395   IN  NS  ns1.opennic.glue.
.           86395   IN  NS  ns6.opennic.glue.
.           86395   IN  NS  ns8.opennic.glue.
dig: couldn't get address for 'ns8.opennic.glue': no more


~$ dig +trace stackexchange.com @23.226.230.72 -p53

; <<>> DiG 9.9.5-3-Ubuntu <<>> +trace stackexchange.com @23.226.230.72 -p53
;; global options: +cmd
.           7440    IN  NS  f.root-servers.net.
.           7440    IN  NS  d.root-servers.net.
.           7440    IN  NS  j.root-servers.net.
.           7440    IN  NS  i.root-servers.net.
.           7440    IN  NS  g.root-servers.net.
.           7440    IN  NS  k.root-servers.net.
.           7440    IN  NS  a.root-servers.net.
.           7440    IN  NS  h.root-servers.net.
.           7440    IN  NS  e.root-servers.net.
.           7440    IN  NS  m.root-servers.net.
.           7440    IN  NS  c.root-servers.net.
.           7440    IN  NS  b.root-servers.net.
.           7440    IN  NS  l.root-servers.net.
;; Received 239 bytes from 23.226.230.72#53(23.226.230.72) in 2948 ms

stackexchange.com.  215 IN  A   198.252.206.16
;; Received 62 bytes from 192.228.79.201#53(b.root-servers.net) in 116 ms

我当前的iptables。 iptables-save

~# iptables-save
# Generated by iptables-save v1.4.21 on Tue Jul 15 23:06:52 2014
*mangle
:PREROUTING ACCEPT [79950528:41742899703]
:INPUT ACCEPT [78748282:41360159554]
:FORWARD ACCEPT [13:5427]
:OUTPUT ACCEPT [85455483:57472640071]
:POSTROUTING ACCEPT [85480442:57475512901]
-A POSTROUTING -o lxcbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
COMMIT
# Completed on Tue Jul 15 23:06:52 2014
# Generated by iptables-save v1.4.21 on Tue Jul 15 23:06:52 2014
*nat
:PREROUTING ACCEPT [71:18713]
:INPUT ACCEPT [7:474]
:OUTPUT ACCEPT [109:7855]
:POSTROUTING ACCEPT [109:7855]
:DOCKER - [0:0]
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 172.17.0.0/16 ! -d 172.17.0.0/16 -j MASQUERADE
-A POSTROUTING -s 10.0.3.0/24 ! -d 10.0.3.0/24 -j MASQUERADE
COMMIT
# Completed on Tue Jul 15 23:06:52 2014
# Generated by iptables-save v1.4.21 on Tue Jul 15 23:06:52 2014
*filter
:INPUT ACCEPT [78748139:41360144354]
:FORWARD ACCEPT [13:5427]
:OUTPUT ACCEPT [85454926:57472600172]
:fail2ban-ssh - [0:0]
:fail2ban-vsftpd - [0:0]
-A INPUT -p tcp -m multiport --dports 21,20,990,989 -j fail2ban-vsftpd
-A INPUT -p tcp -m multiport --dports 22,6622 -j fail2ban-ssh
-A INPUT -i lxcbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i lxcbr0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i lxcbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A INPUT -i lxcbr0 -p udp -m udp --dport 67 -j ACCEPT
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A FORWARD -o lxcbr0 -j ACCEPT
-A FORWARD -i lxcbr0 -j ACCEPT
-A fail2ban-ssh -j RETURN
-A fail2ban-vsftpd -j RETURN
COMMIT
iptables  dns 
— 朗讯88
source
因此，您尝试将所有端口53流量重定向到该IP（23.226.230.72）和端口（5353）吗？
— tachomi
请把你的iptables rules位置
— Networker的
@tachomi正确
— Rucent88
或者，你不能使用你的ISP的DNS ...谷歌的公共DNS服务器8.8.8.8和8.8.4.4
— 小河
@Creek我想你误会了。我的isp正在通过端口53拦截所有流量。即使我想使用google dns服务器，也无法访问它们。
— Rucent88

Answers:

12

以超级用户（sudo）的身份执行所有这些指令。

编辑此文件。

/etc/NetworkManager/NetworkManager.conf

通过注释掉该行来禁用DnsMasq dns=dnsmasq。#在行前放一个

#dns=dnsmasq

重新启动网络。

service network-manager restart

添加这些iptable规则。

iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to 23.226.230.72:5353
iptables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to 23.226.230.72:5353
— 朗讯88
source
2
该解决方案随操作系统进行更新，并且消耗零资源，并且具有零安全风险，具有启动脚本的超级轻松设置和零维护。缺点是它不是很灵活
— Rucent88 '16
3

看起来您真正想要的是要控制DNS查询的内容。

我不确定使用iptables是否是我的首选解决方案。

您是否考虑过设置将请求转发到所需主机和端口的本地DNS服务器？一个示例：使用bind9 forwarders选项，您可以将端口添加到转发器。

这样的设置更易于维护和故障排除，并且可能更加灵活。考虑缓存的优势，或者仅考虑外部DNS服务器关闭的情况。您的DNS配置中可以有多个转发器，但是iptables规则中只有一个IP...。

在Digital Ocean的教程中，对bind9的设置有很好的概述。只需将端口添加到转发器，就可以完成所有工作。

Bind9根本不占用太多资源，并且易于配置（或者至少：比iptables :-)更容易）

— 文森特·德·贝尔
source
哦，不用说，在该设置中，请不要忘记将您的设备设置为使用本地的转发DNS服务器。
— Vincent De Baere 2014年
我确实有一个DNS服务器正在运行，但是它不可靠（垃圾硬件）。保持安全性更新是一个痛苦。它消耗了更多的时间，资源和电力，最终使人们付出了代价。如果我在公司网络后面有数百台计算机，那么我同意DNS服务器将是一个好主意。但是我只是一个拥有笔记本电脑的人。几个iptable规则应该是最简单和最少的资源。
— Rucent88
只需在您的笔记本电脑上添加一台笔记本电脑，它几乎就不会消耗任何资源，并且会通过您的主操作系统进行更新（假设您使用分发软件包），并使其在本地主机上侦听。安全风险几乎为零。
— Vincent De Baere 2014年
确实，恕我直言，这是在99％的案例中维持该方案的更好方法。唯一不适用的1％是在配置Captive Portal系统时，但这是另一回事了。
— ivanleoncz
2

尝试这个：

首先，您必须在中启用转发选项

/etc/sysctl.conf

将值设置为1 

net.ipv4.ip_forward = 1

启用更改

sysctl -p

保存并运行以下命令：

iptables -t nat -A PREROUTING -p tcp --sport 53 -j DNAT --to-destination 23.226.230.72:5353
iptables -t nat -A POSTROUTING -j MASQUERADE

如果可以在PREROUTING中指定入接口（-i eth1）或/和在POSTROUTING中指定出接口（-o eth0）可能会有用。

注意：在用主IP屏蔽目标IP时，必须使用MASQUARADE线。

— ach
source
我输入sysctl net.ipv4.ip_forward=1了iptables规则。DNS正在运行，但仍被我的isp拦截。所以这表明，我认为DNS仍然通过端口53发
— Rucent88
我将您的规则更改为udp，但得到了相同的结果。
— Rucent88
您能不能把iptables-save的输出放进去？我可能只是掩盖所有指定的MASQUERADE全部-10.0.3.0/24，所以如果您可以禁用该行并保留-A POSTROUTING -j MASQUERADE一条，可能会有所帮助
— tachomi
我添加了您请求的信息
— Rucent88
好的，让我们来了解一下。...所有53号入站流量都是您要重定向到23.226.230.72还是出站的流量？
— tachomi
1

尝试这个：

iptables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to 23.226.230.72:5353;

iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to 23.226.230.72:5353;

iptables -t nat -A POSTROUTING -j MASQUERADE

这意味着：
1）任何联系世界tcp 53的本地用户都在端口5353发送到23.226.230.72。2
）与1相同，但对于udp
3）将传出数据包的源信息设置为来自我们。

— 乔治·伊达尔戈
source
0 
iptables -t nat -A PREROUTING -p tcp --dport 53 -j DNAT --to XX.XX.XX.XX:5353
iptables -t nat -A PREROUTING -p udp  --dport 53 -j DNAT --to XX.XX.XX.XX:5353
iptables -t nat -A POSTROUTING -j MASQUERADE
— 日布里
source
这个答案没有提到“ 5353”的事实使我相信它是自动错误的。
— G-Man说“恢复莫妮卡”
更正了…………
— Zibri
好的，我再看看您的答案。它似乎与tachomi的答案非常相似，除了（1）您已更改sport为  dport（这显然是三年前battman622指出的 tachomi答案的错误，（2）您为udp（this是对tachomi答案的合理改进，但已在评论中提及了  …（续）
— G-Man说'Resstate Monica'
（续）…和其他几个答案），以及（3）您替换--to-destination为  --to。  手册页没有这么说，--to并且  --to-destination是等效的。相反，它表示--to与NETMAP目标（而不是  DNAT目标）一起使用，并且其自变量不包含端口号。（尽管我注意到，还有其他几个答案也使用--to了您的方法。）您确定--to该方法可以有效地使用它（带有端口号和  DNAT目标）吗？…（续）
— G-Man说'Resstate Monica'
（续）…（如果这样，也许有人应该向手册页的维护者提交更改请求。）  除了简洁--to以外--to-destination，还有其他更好的   方法吗？
— G-Man说“恢复莫妮卡”
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.