☰

iptables - INPUT DROP 忽略 FORWARD 规则？

tag-icon • tag-icon networking iptables routing
iptables - INPUT DROP 忽略 FORWARD 规则？

我最近在家庭网络中的一台 Debian 服务器上安装了客户端 VPN。我想将其用作网络中某些设备的另一个网关。这是我已经成功的事情，所以一切都很好，只是想告诉你背景故事。

现在，我有一个 RDP 服务器 (WS 2019)，只要我不使用 iptables -P INPUT DROP，我就可以通过 VPN 上的 WAN 连接到该服务器。但是，我正在使用端口转发，所以我很困惑为什么这些端口不起作用。我昨天开始使用 iptables，所以这可能是非常明显的事情，但我不知道如何用谷歌搜索它。

我的设置：

$ iptables -L -n  
Chain INPUT (policy DROP)  
target    prot opt source               destination         
ACCEPT     tcp  --  192.168.0.0/24      0.0.0.0/0            tcp dpt:22  
Chain FORWARD (policy ACCEPT)  
target     prot opt source               destination  
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:11111  
Chain OUTPUT (policy ACCEPT)  
target     prot opt source               destination      


$ iptables -L -n -t nat  
Chain PREROUTING (policy ACCEPT)  
target     prot opt source               destination  
DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:11111 to:192.168.0.50:3389 <-(RDP server)  
Chain INPUT (policy ACCEPT)  
target     prot opt source               destination  
Chain POSTROUTING (policy ACCEPT)  
target     prot opt source               destination  
SNAT       all  --  192.168.0.0/24      0.0.0.0/0            to:[my public VPN IP]  
Chain OUTPUT (policy ACCEPT)  
target     prot opt source               destination

需要明确的是，要使一切再次正常工作，我唯一要做的就是将“输入”策略设置为“接受”，但我不想这样做，因为它是到 WAN 的路由器。

那么，INPUT 的策略是否也定义了前向链的流量？如何解决此问题，以便使用 DROP 策略并仍将 11111 流量转发到本地 RDP 服务器上的 3389？

答案1

为了确保流量确实到达您的 Windows Server，我建议您在防火墙脚本末尾添加“-J LOG”，以便在丢弃包之前记录该包。如果您没有看到软件包被丢弃，则 Windows 防火墙可能会丢弃它。此外，我知道此设置可能正在进行中，但我根本不建议您使用 ACCEPT 作为防火墙中 FORWARD 链的默认目标，因为这会非常危险。您可能还需要检查终端服务日志（不确定它们在哪里），以确保 Windows 正在接收并且不会因任何原因断开连接。

希望这可以帮助。

答案2

通过仅将 SSH 端口作为 INPUT 规则，然后引​​入iptables -P INPUT DROP，您将阻止传入的 ICMP。

所有现代操作系统（至少从 Windows 95 开始）都在 TCP 连接上使用路径 MTU 发现 (PMTUD)。 MTU = 最大传输单元，基本上是可以传输的最大数据包的大小，而无需将其拆分为两个或多个较小的数据包（碎片）。

基本上，现代操作系统将始终发送设置了“不分段”标志的数据包，如果某处的路由器发现它们不会通过特定的网络跃点，因为该跃点的最大数据包大小小于正常的最大数据包大小，那么它们就会预计路由器将发回一个 ICMP“需要分段”数据包，其中还将包含能够通过未分段的最大数据包大小的信息。一旦他们收到该 ICMP 消息，他们将开始使用指定的大小。当在数据包大小受限的任何跃点上重复该过程时，TCP 连接将自动找到能够从源一直传递到目的地而不会产生碎片的最大数据包大小。其间的所有路由器都可以以最佳效率工作。

通过阻止所有 ICMP，您已经对工作造成了影响。很可能您的服务器正在尝试发送最大大小的数据包，而其他东西则试图告诉它“这不适合，请稍微调低您的 MTU”。但由于传入的 ICMP 被阻止，您的服务器将继续尝试发送永远不会到达预期收件人的最大大小的数据包......直到连接超时。

您还使用 VPN。因为任何进入 VPN 隧道的数据包都需要有第二组地址标头作为前缀（可能还要加上一些用于加密和/或 VPN 自身需求的开销），所以大多数 VPN 连接会将 MTU 限制为某个值略小于以太网的默认值。所以你肯定需要 PMTUD 才能工作。

各种基于云的服务的 MTU 值也可能略有降低，但并非所有服务的 MTU 值都完全相同。所以手动设置较小的MTU值并不理想。

您需要阅读 ICMP，并自行决定您认为哪些 ICMP 数据包足够安全，可以处理，以及您希望在防火墙中丢弃哪些 ICMP 数据包。

另外，您应该意识到，现代操作系统默认情况下已经包含一些针对基于 ICMP 的攻击的防护措施：例如，发送 ICMP 错误消息通常被认为比处理任何正常工作的连接具有较低的优先级。并且传出 ICMP 消息的数量可能已经受到操作系统内核本身的速率限制：网络协议代码开发人员通常不是完全的傻瓜。

相关内容