为什么我们的防火墙（Ubuntu 8.04）拒绝带有 RST 的最终数据包（FIN、ACK、PSH）

Question 1

类似情况描述如下http://www.spinics.net/lists/netfilter/msg51408.html：一些本应由 NAT 处理的数据包不知何故被标记为 INVALID 而不是 ESTABLISHED，并进入 INPUT 链。您应该添加一些规则来-m state --state INVALID检查这种情况，答案位于http://www.spinics.net/lists/netfilter/msg51409.html建议始终丢弃此类无效数据包，因为 NAT 没有正确执行，因此其中的地址可能是错误的。

如果你的问题数据包确实被标记为无效，那么添加iptables -I INPUT -m state --state INVALID -j DROPlikely 可以解决问题（损坏的数据包不会到达本地进程，也不会导致 RST 响应，然后 TCP 将在超时后从丢失的数据包中恢复）。然后你可以尝试进一步调试问题，如中所述http://www.spinics.net/lists/netfilter/msg51411.html：

echo 255 >/proc/sys/net/netfilter/nf_conntrack_log_invalid

（在这种特殊情况下，问题是由路径上的某些网络硬件损坏引起的，可能还与某些 TCP 校验和卸载故障有关。）

Answer

类似情况描述如下http://www.spinics.net/lists/netfilter/msg51408.html：一些本应由 NAT 处理的数据包不知何故被标记为 INVALID 而不是 ESTABLISHED，并进入 INPUT 链。您应该添加一些规则来-m state --state INVALID检查这种情况，答案位于http://www.spinics.net/lists/netfilter/msg51409.html建议始终丢弃此类无效数据包，因为 NAT 没有正确执行，因此其中的地址可能是错误的。

如果你的问题数据包确实被标记为无效，那么添加iptables -I INPUT -m state --state INVALID -j DROPlikely 可以解决问题（损坏的数据包不会到达本地进程，也不会导致 RST 响应，然后 TCP 将在超时后从丢失的数据包中恢复）。然后你可以尝试进一步调试问题，如中所述http://www.spinics.net/lists/netfilter/msg51411.html：

echo 255 >/proc/sys/net/netfilter/nf_conntrack_log_invalid

（在这种特殊情况下，问题是由路径上的某些网络硬件损坏引起的，可能还与某些 TCP 校验和卸载故障有关。）

Question 2

我在其他类型的防火墙上也看到过这种行为，而且它们的行为如此相似，所以我想把它扔掉。

我遇到的问题是防火墙正在通过 NAT 进入与盒子上的临时端口相同的空间。如果两者发生冲突，这将导致这种确切的行为，因为内核现在假设连接是用于本地计算机的。为此，您可以检查几件事。首先，您是否在 iptables 中指定了出站端口配置（使用 --to-ports）？或者您是否修改了计算机上的临时端口范围：

$ cat /proc/sys/net/ipv4/ip_local_port_range

为了进行诊断，您可以设置捕获并查看是否在 RST 之前的 3*MSL 时间内看到使用相同外部 fw ip、端口组合的任何其他请求（我认为约为 180 秒）。

虽然我还不确定这是否就是答案，但如果我处于这种情况，我会首先排除这个可能性，然后再考虑其他一些事情。

这是否容易重现？是否可以从防火墙框捕获更多诊断信息并查看问题是否发生？我会尝试捕获：

$ netstat -anp
$ cat /proc/net/ip_conntrack

每秒左右尝试重现一次，查看是否有某些东西本地绑定到端口，以及问题发生时伪装表是什么样的。

如果您使用防火墙阻止出站 RST，那么来自内部客户端的最终 ACK 是否会导致连接成功？

最后一件事，你看到了所有的日志吗？你已经检查过 dmesg 了吗？你是否在 syslog 配置中的防火墙框上将 *.* 设置为文件以确保安全？

请告诉我你发现了什么！我非常感谢你在问题中提供的大量信息，谢谢。

Answer