是iptables -F命令locking我的SSH？

我正在使用iptables为VPS创build一些防火墙规则。我的shell脚本看起来像这样：

#!/bin/sh # My system IP/set ip address of server SERVER_IP="1.2.3.4" # Flushing all existing rules iptables -F iptables -X # Setting default filter policy iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP # Allow SSH on 22 iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -o eth0 -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT # Default policy DROP iptables -A INPUT -j DROP iptables -A OUTPUT -j DROP

如果在运行这个脚本之后运行iptables -F命令，我会被locking在SSH之外（我可以重新login，但是我不希望SSHclosures）。

我有三个问题。

当我运行iptables -F命令时，我被默认的filter策略locking了吗？
如果我使用iptables -FX我会不会被locking？
如果我在shell脚本的末尾添加默认的删除策略，甚至需要默认的filter策略吗？

干杯!

当然，你被locking了 – 你将策略设置为默认拒绝，然后冲洗所有允许你进入的规则。

是。
不，因为-X和链式政策有很多关系，就像-F （也就是什么都没有）。
是的，因为规则可以删除，刷新，纺纱和残缺。连锁政策不能。

你只能findssh暂时locking，因为你已经允许规则中的“ESTABLISHED”。但是，临时数据包丢失会使ssh失败，tcp恢复需要10秒或更长的时间。

我自己，我总是在flush命令之后立即放置一个通用的“iptables -A INPUT -m状态 – 状态build立，相关的”规则，以便locking非常短暂！

你不是在用conntrack来冲洗状态吗？

ps如果你正在控制来自相对可信任的局域网的连接，那么在最后使用REJECT规则可能会更有帮助，因为新的连接尝试失败会立即被拒绝，而不是不得不超时。