我不明白 conntrack 模块的一些基本概念。
首先，我确定它已在我的系统（Ubuntu 18.04）中启用，modinfo显示有关 nf_conntrack 的信息，并且/proc/modules文件告诉 nf_conntrack 是“实时”的。
其次，我有以下测试设置：
机器 A (192.168.1.2) <-----> 路由器机器 (192.168.1.1 & 192.168.2.1) <----> 机器 B (192.168.2.2)
在路由器机器上，我有以下 iptables 规则：
iptables -t filter -A FORWARD -m set --match-set BlackListPort dst -j DROP
BlackListPort 是一个 ipset 表。
现在我建立了从机器 A (1.2) 到机器 B (2.2) 的 SSH 连接。确认其正常工作后，我将端口 22（SSH 默认值）添加到 BlackListPort 表中。
SSH 连接冻结/挂起，直到我从该 ipset 表中删除端口 22。
现在问题: 既然我的系统中存在conntrack，为什么SSH阻止成功？ SSH 连接是在端口 22 添加到 ipset 之前建立的，因此 conntrack 应该跳过所有数据包，从而允许 SSH 工作。
答案1
SSH 连接是在端口 22 添加到 ipset 之前建立的，因此 conntrack 应该跳过所有数据包，从而允许 SSH 工作。
这是不正确的。
所有数据包都将通过过滤规则进行处理，无论它们是否属于跟踪的连接。
将类似的内容放在相关规则链的开头附近（FORWARD在您的示例中）是 iptables 规则的一种非常常见的优化：
iptables -t filter -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
在较旧的发行版上，您可能会看到这个版本：
iptables -t filter -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
（我知道conntrack现在匹配比匹配更受欢迎state。我认为某些内核版本甚至会在这方面对你唠叨。）
如果属于现有连接的数据包存在连接跟踪信息，这将允许它们通过。但重点是，你可以控制到底在哪里你制定了这条规则，或者你是否使用了它。因此，您可以根据需要让防火墙规则尽可能多地或尽可能少地关心连接状态。