UniFi Dream Machine 特别版 (UDM SE) - iptables NAT PREROUTING 无法在自己的子网上工作

UniFi Dream Machine 特别版 (UDM SE) - iptables NAT PREROUTING 无法在自己的子网上工作

对我来说这是一个非常令人困惑的情况,我觉得这个问题没有答案。但经过几个小时的测试,我还是不知道事情目前是如何运作的,或者没有按我预期的方式运作。如果你有足够的勇气阅读这篇文章,提前感谢你。

网关 192.168.1.1 (UDM SE)

DNS 服务器位于 192.168.1.2

初始防火墙规则:

iptables -t nat -A PREROUTING ! -s 192.168.1.2 -p tcp --dport 53 -j DNAT --to 192.168.1.2
iptables -t nat -A PREROUTING ! -s 192.168.1.2 -p udp --dport 53 -j DNAT --to 192.168.1.2
iptables -t nat -A POSTROUTING -m iprange --src-range 192.168.1.4-192.168.4.254 -j MASQUERADE

这很有效。它强制任何执行 DNS 请求(如“nslookup site.tld 8.8.8.8”)的人在所有 4 个子网上从 192.168.1.2 而不是 8.8.8.8 获得响应。这是预期和期望的结果。出于某些原因,我不会让您感到厌烦,我需要改变一些东西,并发现了意想不到的和不想要的结果。

更改一个 Delta(路由范围后):

iptables -t nat -A PREROUTING ! -s 192.168.1.2 -p tcp --dport 53 -j DNAT --to 192.168.1.2
iptables -t nat -A PREROUTING ! -s 192.168.1.2 -p udp --dport 53 -j DNAT --to 192.168.1.2
iptables -t nat -A POSTROUTING -m iprange --src-range 192.168.2.1-192.168.4.254 -j MASQUERADE

使用此配置,192.168.1.x 子网上的设备可以“nslookup site.tld 192.168.1.2”,但会在“nslookup site.tld 8.8.8.8”上超时。其他三个子网(192.168.2.1-192.168.4.1)无论通过哪种方式进行查找,都会从 192.168.1.2 获得结果。如果我删除 2 个 PREROUTING 条目,“nslookup site.tld 8.8.8.8”将从 8.8.8.8 解析,并且在 192.168.1.x 设备上不会超时,在其他 3 个子网上也是如此。为什么在存在 PREROUTING 规则的情况下,192.168.1.x 设备解析需要 MASQUERADE 规则?

更改两个增量(DNAT --to)

iptables -t nat -A PREROUTING ! -s 192.168.1.2 -p tcp --dport 53 -j DNAT --to 208.67.222.123
iptables -t nat -A PREROUTING ! -s 192.168.1.2 -p udp --dport 53 -j DNAT --to 208.67.222.123
iptables -t nat -A POSTROUTING -m iprange --src-range 192.168.1.4-192.168.4.254 -j MASQUERADE

从三个子网 ( 192.168.2.1-192.168.4.1 ) 执行 'nslookup welcome.opends.com 192.168.1.2' 或 'nslookup welcome.opends.com 8.8.8.8' 可获得使用 208.7.222.123 作为 DNS 的预期结果,并正确返回 146.112.59.8。从 192.168.1.x 设备执行 'nslookup welcome.opends.com 8.8.8.8' 可返回 146.112.59.8,正如我所料,这是由于 PREROUTING 规则。但是,执行“nslookup welcome.opends.com 192.168.1.2”会返回 146.112.59.9,这意味着查询通过了 192.168.1.2,而不是 PREROUTING 规则定义的 208.67.222.123。为什么这些 192.168.1.x 设备没有得到预路由,而不管 nslookup 期间指定的 DNS 服务器是什么?显然,当使用 8.8.8.8 和 nslookup 时,它们会被拦截。

感谢您观看这篇怪物帖子。

答案1

使用此配置,192.168.1.x 子网上的设备可以“nslookup site.tld 192.168.1.2”,但会在“nslookup site.tld 8.8.8.8”上超时。其他三个子网(192.168.2.1-192.168.4.1)无论通过哪种方式进行查找,都会从 192.168.1.2 获得结果。如果我删除 2 个 PREROUTING 条目,“nslookup site.tld 8.8.8.8”将从 8.8.8.8 解析,并且在 192.168.1.x 设备上不会超时,在其他 3 个子网上也是如此。为什么在存在 PREROUTING 规则的情况下,192.168.1.x 设备解析需要 MASQUERADE 规则?

因为同子网通信绕过了路由器。

您的本地 DNS 服务器 (192.168.1.2) 知道客户端设备 (192.168.1.x) 位于同一子网(这实际上是“子网掩码”参数的用途!),因此它会将响应直接发送到客户端的 MAC 而不是路由器的 MAC,从而允许您的以太网交换机将其直接传送到目的地。

因此,UDM 将没有机会对响应应用反向 NAT,因此客户端会从与发送查询完全不同的 IP 地址接收响应并将其忽略。

通常的解决方法是 a) 首先不要将您的服务器放在“客户端”子网中,或者 b) 使用 SNAT/MASQUERADE 的“NAT 发夹”来隐藏原始源 IP 地址,就像您当前正在做的那样,或者 c) 代理 ARP 和以太网级“端口隔离”(有时也称为“私有 VLAN”;相当于 Wi-Fi“客户端隔离”)欺骗所有子网设备将本地 IP 地址解析为路由器的 MAC 地址。

但是,执行“nslookup welcome.opends.com 192.168.1.2”会返回 146.112.59.9,这意味着查询通过了 192.168.1.2,而不是 PREROUTING 规则定义的 208.67.222.123。为什么这些 192.168.1.x 设备没有得到预路由,而不管 nslookup 期间指定的 DNS 服务器是什么?显然,当使用 8.8.8.8 和 nslookup 时,它们会被拦截。

与上文相同:同子网通信绕过路由器。您的客户端设备知道 192.168.1.2 位于其自己的子网中,因此它将直接向 192.168.1.2 的 MAC 地址发送查询,而不是向路由器的 MAC 地址发送查询,这意味着路由器将没有机会将任何 NAT 或防火墙规则应用于数据包。

SNAT/MASQUERADE 方法在这里不起作用,但其他两种解决方法仍然适用。

相关内容