我在 wifi 路由器后面有一台 Debian 机器。每当对预定义主机的 ping 失败时,机器都会运行一个 cron 脚本来恢复连接。我已经设置了 iptables,以便只打开所需的端口/地址。一切正常。
它变得有点复杂,因为我还需要警惕路由器的外部 IP 地址可能发生的变化,这就是为什么我使用动态 DNS 提供程序 ( www.noip.com ) 来保持机器可以从外部访问。每当连接恢复后,我使用以下命令更新机器的地址:
curl https://login:[email protected]/nic/update?hostname=user.domain.net&myip=11.22.33.44
反过来,为了确定 11.22.33.44 部分,我运行
dig +short myip.opendns.com @resolver1.opendns.com
现在,这部分也有效。但仅在禁用 iptables 的情况下。这就是我的问题开始的地方 - 我不确定在 iptables 中启用哪些端口/地址来让上述请求通过。
我设置了 iptables 来记录请求。我可以看到有问题的机器和使用端口 53 的 wifi 路由器之间的 UDP 交换。那是DNS,我可以理解。但是随后,Debian 机器也从路由器接收到一个用于 224.0.0.1 的数据包(好吧,我找到了它的含义 - 它是多播,即使我不确定它有多么必要),并向其发送一个 UDP 请求德国的服务器,看起来像 NTP(端口 123)。最后,它在端口 443 上联系 52.9.108.157,这显然是 noip 服务器。
这是我的问题:
1
假设端口 123 是 ntp,我该怎么办?它真的是挖掘/更新过程的一部分吗?如果是这样,为什么要使用特定的德国服务器,然后我应该将其列入白名单?
2
224.0.0.1 - 我应该启用它吗?
(不询问 dynupdate.no-ip.com 的 IP 地址的动态处理,因为它在这个站点上已经有了答案: Using iptables to redirect traffic to a dynamic DNS name instead of an IP address?)
(由 David Go 添加,用于注释中提供的 iptables 规则的可读性格式)
-P INPUT DROP
..........
-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
..........
-A INPUT -p udp -m udp --sport 53 --dport 1024:65535 -j ACCEPT
..........
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
..........
-A INPUT -i enp1s0 -m state --state RELATED,ESTABLISHED -j ACCEPT
我认为您的 iptables 列表中缺少一些规则。我会假设这些是无关紧要的。
我的猜测是缺少相关规则或以下规则错误:
上述规则假定请求反转源端口和目标端口 - 即,当您运行 dig 时,目标端口是 53,源端口是 1024-65535。
我指出了另一个问题——这是相关的,但不是当前的问题——你只处理 UDP 端口 53。DNS 使用 UDP 和(对于更长的查询)TCP 53,所以你需要像这样的规则
(您可以另外添加一个源端口,但我不确定这会带来什么好处)
实际上,我与 noip 的支持人员取得了联系,他们指出我需要为 curl 请求解除 INPUT 链上的端口 80 和 443 的阻塞。他们还提到了端口 8245,但是没有它该命令也可以工作。