我已经阅读了大量关于这个的post，但没有一个有实际的答案。
我们有3台机器，其中一台（不在我们的关心）平衡负载到另外两台。 第一个与FreeBSD正常工作，另一个最近被格式化，现在正在使用Ubuntu服务器。
第二台机器当前正在将所有连接保留在SYN_RECV上，原因不明。 两台机器都没有防火墙。
dmesg显示Possible SYN Flood attack但我们知道情况并非如此。
什么可能是错的？ 有一些我必须做的内核configuration吗？ Ubuntu有一些已知的问题呢？
谢谢
编辑：我发现在BSD机器的PF的规则，我不知道，但它应该与这个问题有关。
pass in log on bce1 proto tcp from <nois> to any port = http flags S/SA keep state (max 2000, source-track rule, max-src-states 120, max-src-conn 80, adaptive.start 1200, adaptive.end 2400)
它基本上保持SYN SYNACK标志包的状态…有谁知道如何将其翻译成IPTABLES？
基本上，发生了什么事是，Linux的盒子正在接收SYN（试图打开一个TCP连接），然后它没有得到ACK（完全是这个过程）。 半开连接会累积起来，直到服务器决定受到攻击。
有几个可能的原因：
首先，可以configuration负载均衡器来执行此操作。 它可能传递一个SYN到两个盒子，只允许一个连接完成到客户端，因为它只需要一个。 平衡者可能会认为忽略这个答复是无害的，因为数据包一直在下降。 但是，在这种情况下，真的没有理由让你遇到实际的问题。 确保你已经启用了syncookies，只是为了确保在这种情况下不会造成问题。
其次，响应于SYN的Linux盒子的ACK可能不会通过Linux盒子的防火墙。 这将需要一个非常糟糕的防火墙configuration，所以这是不可能的。
可能性较小的可能性是：
第三，由于某种原因，负载均衡器可能会拒绝Linux机器的ACK。
第四，负载均衡器可能无法将ACK传回Linux机器。
第五，Linux的防火墙可能会丢弃传入的ACK。
从你所说的话来看，负载均衡器很可能会检查从后端服务器返回的SYN / ACK，看看它是否已经启动，然后才把所说的SYN / ACK传回给客户端。 这意味着除了负载平衡之外，它也执行故障转移职责。
显然，FreeBSD的处理方式与Ubuntu不同，而Ubuntu的盒子将其视为SYN洪水攻击。
嗅探来自客户端和负载均衡器与后端之间的stream量会告诉你到底发生了什么事情。