iptables DROP 不会静默丢弃数据包答案

【问题标题】：iptables DROP does not silently drop the packetsiptables DROP 不会静默丢弃数据包
【发布时间】：2014-05-09 07:01:29
【问题描述】：

我有两台服务器，一台作为备用服务器，另一台作为活动服务器。从备用 pgpool 不断检查 postgres 是否在另一台服务器上工作。我正在尝试模拟 pgpool 对活动服务器的请求超时的情况，并尝试为此使用 iptables DROP。

根据我的阅读，DROP 选项会在源不知道的情况下静默丢弃数据包，并且需要很长时间才能失败（让源知道）。我在活动服务器的 iptables 中使用了以下条目：

iptables -A INPUT -p tcp -s <standby server ip> \
         -m state --state NEW,ESTABLISHED --dport 5432 -j DROP

通过这样做，我可以模拟一个超时，但它超时太快了（甚至不到一秒）。

谁能解释所有参考文献中的“需要很长时间才能失败”是什么意思？以及我是否可以使用任何选项来增加失败所需的时间。

【问题讨论】：

假设一个 ipv4 linux 客户端，检查/proc/sys/net/ipv4/tcp_syn_retries。典型值为 5 给出 ~60s 超时。
谢谢丹尼尔。我检查了值，正如你提到的那样。但是我发现 DROP 实际上正在工作，但 pgpool 没有遵守超时
@spathirana pgpool 不遵守超时时间 — 不，不，不... pgpool 可能有自己的超时时间，并且比您预期的要小。它将在 Intranet 上使用，因此超时可以是 100 毫秒，并且足以知道连接不会发生。许多客户端在 Internet 后端以这种方式工作，以确保快速满足请求。

【解决方案1】：

根据规则集中规则的位置，它可能不会触发，来自<standby server ip> 的数据包可能会遇到ALLOW 规则。

您可以使用watch 主动监控iptables 以查看触发了哪些规则

$ sudo watch -n1 "iptables -vnL"

“Take a long time to fail”表示DROP 告诉 iptables 不要用 tcp 重置数据包或 icmp 错误来响应数据包的发送者。这会导致发送者在关闭尝试的连接之前必须等待其指定的超时时间。

【讨论】：

谢谢Creek，我知道当我通过脚本添加规则后，我的活动服务器（源）中的超时时间就达到了DROP 规则。当我通过脚本再次删除规则时开始接受请求。也许我必须检查指定的超时时间。

【解决方案2】：

我使用 telnet 而不是 pgpool 再次对此进行了测试，它确实按预期等待了 60 秒。原来问题出在 pgpool 本身，但不在 iptables 中。我将这个作为任何遇到这个问题的人的答案。谢谢大家的回答

【讨论】：