我在 wifi 路由器后面有一台 Debian 机器。该机器正在运行一个 cron 脚本，以便在 ping 到预定义主机失败时恢复连接。我已设置 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 来记录请求。我可以看到有问题的机器和 wifi 路由器之间的 UDP 交换，两者都使用端口 53。那是 DNS，我能理解。但是，Debian 机器还从路由器接收到一个发往 224.0.0.1 的数据包（好吧，我找到了它的含义 - 它是多播，尽管我不确定它有多必要），并向德国的一个看起来像 NTP（端口 123）的服务器发送一个 UDP 请求。最后，它通过端口 443 联系 52.9.108.157，这显然是 noip 服务器。
这是我的问题：
1
假设端口 123 是 ntp，我该怎么办？它真的是挖掘/更新过程的一部分吗？如果是这样，为什么是那个特定的德国服务器，我应该将它列入白名单吗？
2
224.0.0.1——我应该启用它吗？
（不询问 dynupdate.no-ip.com 的 IP 地址的动态处理，因为该站点上已经有答案： 使用 iptables 将流量重定向到动态 DNS 名称而不是 IP 地址？）
（由 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
答案1
我认为您的 iptables 列表中缺少一些规则。我假设这些规则无关紧要。
我猜测是缺少相关规则或者以下规则是错误的：
-A INPUT -p udp -m udp --sport 53 --dport 1024:65535 -j ACCEPT
上述规则假设请求反转源端口和目标端口 - 即当你正在运行挖掘时，目的地端口为53，源端口为1024-65535。
我指出了另一个陷阱——这是相关的，但不是当前的问题——你只处理 UDP 端口 53。DNS 同时使用 UDP 和（对于较长的查询）TCP 53，因此你需要像这样的规则
-A INPUT -p udp --dport 53 -j ACCEPT
-A INPUT -p tcp --dport 53 -j ACCEPT
（您可以另外添加源端口，但我不确定这会带来什么好处）
答案2
实际上，我联系了 noip 的支持人员，他们指出我需要解除 INPUT 链上对端口 80 和 443 的阻止，以便执行 curl 请求。他们还提到了端口 8245，但即使没有它，命令也能正常工作。