☰

Iptables 导致 ssh 停滞？

tag-icon • tag-icon ssh iptables
Iptables 导致 ssh 停滞？

我有一台通过两个网桥运行多个虚拟机的服务器，并且想通过 iptables 保护主机的安全。

所以我有 IN/OUTPUT：drop 和 FORWARD：accept 的默认值，以及一些 IN/OUTPUT 规则以允许我 ssh 访问。

现在的问题是，当命令产生几行输出时，ssh 会话似乎会冻结。例如，date可以工作，但iptables -L或top会在输出中间挂起。我可以用 终止会话~.，再次登录，将 iptables 重新设置为默认值，然后一切又可以正常工作。

此外，设置 iptables 规则后，需要一段时间才会出现问题。我无法确定确切的时间范围，我认为是在 5 到 20 分钟之间。

知道什么可能导致这样的问题或如何诊断它吗？

答案1

尝试运行iptables -L -n（添加 -n 选项）。名称解析可能会导致 iptables -L 挂起。

答案2

您是否完全阻止了 ICMP？如果是这样，您可能已经创建了一个PMTU黑洞。

答案3

您是否有一条 iptable 规则来允许已建立的流量通过？

iptables -A OUTPUT -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

我也见过由于网络水平分割而导致的这个问题，但这听起来不像是你的问题，因为当你删除 iptable 规则时这个问题就会消失

答案4

这可能是 MTU 黑洞问题。

MTU 是最大传输单元；即每端可以处理的数据包大小。以太网默认为 1500 字节，但这绝不是唯一的可能性。

短命令可以工作，因为它们低于两个 MTU 大小。长命令则不行，因为它们不低于 MTU 大小。

如果连接的两端使用的 MTU 不同，或者中间的网络具有较小的 MTU，则您的系统将需要以某种方式解决这个问题；该过程称为路径 MTU 发现。

这种情况发生在 ICMP 消息中。如果你阻止所有 ICMP，那么你也就阻止了有用的东西。

更多信息请点击这里：为什么不阻止ICMP？

还要注意，如果中间的小 MTU 网络是第 2 层（例如，您配置的网桥），则路径 MTU 发现将不起作用；数据包将被丢弃并在交换机/网桥和/或以太网接口上显示为错误。

相关内容