使用 iptables DROP 目标会导致套接字 CLOSE_WAIT 永远不会完成吗？

Question

我有一些简单的规则来阻止黑客/垃圾邮件发送者经常使用的某些 IP 块，例如：

iptables -A INPUT -s 173.208.250.0/24 -j DROP

但是，我注意到 apache 在几天后挂起，在 netstat 的输出中显示了许多 CLOSE_WAIT，这些信息永远不会消失：

# netstat -atlpn 
Active Internet connections (servers and established) 
Proto Recv-Q Send-Q Local Address Foreign   Address State PID/Program name 
tcp 1 0 ::ffff:10.0.0.107:80 ::ffff:173.208.250.123.50813 CLOSE_WAIT 29125/httpd

这可能是由在规则中指定 DROP 目标引起的吗？我应该改用 REJECT 吗？

Answer 1

这可能是由在规则中指定 DROP 目标引起的吗？

不。

我应该改用 REJECT 吗？

不。

INPUT 链上该规则的 DROP 目标意味着 Apache 永远不会看到第一个 SYN 数据包或任何具有该源地址的数据包。如果不建立连接，它永远不会处于 CLOSE_WAIT 状态。请参阅下面的维基百科状态图：

如您所见，CLOSE_WAIT 仅在建立会话之后发生，并且仅在客户端启动关闭会话时才在服务器上发生。使用 KeepAlive，会话保持打开状态，直到客户端或服务器之一达到超时并主动关闭会话。

服务器达到此超时并关闭会话是很常见的，导致服务器以 TIME_WAIT 状态结束大量连接。默认情况下，它们将保持此状态两分钟，但这很少会导致问题。TIME_WAIT 连接（在 Linux 上）会占用一个 IP/端口组合，但在 TIME_WAIT 状态下有大约 30,000 个连接之前，您不会用完这些。

您规则中的源地址范围与示例中处于 CLOSE_WAIT 状态的 IP 地址不匹配。

REJECT 用于礼貌的人，如果由于某种原因您无法接受他们的连接，因为它允许他们立即关闭连接，但对于黑客/垃圾邮件发送者则无需礼貌。让他们等待他们配置的任何超时。

那么，什么会导致连接处于 CLOSE_WAIT 状态呢？客户端发送 FIN，服务器以 FIN/ACK 响应，然后等待最终的 ACK。如果它从未收到最后的 ACK，它会一直卡在那里，直到发生其他事情，例如重新启动 Apache。

其他代码（例如硬件防火墙）中的不良连接状态跟踪可能会导致这种情况，客户端也可能会出现问题。我无法确定是什么导致了您的具体问题。