只是好奇。nftables 中的一个例子维基百科允许相关且已建立的连接，然后丢弃无效的连接。有必要吗？
答案1
总结
如果你从未使用过拒绝任何规则中的语句，删除或不删除都无关紧要无效的数据包。如果您使用拒绝声明，你肯定应该放弃无效的状态。
解释
在许多情况下，丢包无效的状态不是强制性的：接收网络堆栈在收到此类数据包时会忽略它。无论如何，可以想象存在错误，并且当系统是路由器时，如果其实现无法正确应对，这样做将保护后面的系统。
有一种情况是必须降低无效数据包：即不拒绝他们。这已经最近添加到iptables' 文档：
警告：您不应该不加区别地将 REJECT 目标应用于连接状态被归类为 INVALID 的数据包；相反，您应该只丢弃这些数据包。
假设源主机正在传输数据包 P，而 P 在传输过程中经历了很长的延迟，因此源主机发出了重传 P_2，而 P_2 成功到达目的地并正常推进连接状态。可以想象，迟到的 P 可能被认为与任何连接跟踪条目无关。对此类数据包生成拒绝响应将终止健康连接。
因此，不要：
-A INPUT ... -j REJECT请考虑使用：
-A INPUT ... -m conntrack --ctstate INVALID -j DROP -A INPUT ... -j REJECT
使用时的行为完全相同nftables，因为两者都依赖于连接跟踪. 类似工具防火墙总是得到正确的结果并且确实放弃无效的在做任何事之前声明拒绝在其生成的规则中。不了解这一点的用户在手动构建规则时可能不会这样做。
只需重写以上内容nftables心里：
Netfilter 的连接跟踪比人们通常认为的检查要多得多。例如，对于 TCP 流，它还会检查与当前 TCP 窗口相关的序列号的有效性（PDF当数据包延迟时（可能临时通过互联网路由到另一条较慢的路径），它可能在数据包已经重新传输并成功确认后到达，因此现在超出了窗口并被标记为无效的状态。现在考虑一下这些规则会发生什么情况（在type filter hook input客户端防火墙链中没有托管任何服务）：
ct state established accept
tcp reject with tcp reset
reject
这种无效数据包（例如：在长时间和大量下载期间发生）将触发 TCP RST，从而中止下载。更糟糕的是，如果规则不在客户端系统上，但等效规则在防火墙路由器的前向链上，则此类客户端系统的管理员将不知道发生了什么（除了可能在捕获的流量中看到连接失败前的一些重新传输）。
现在有了这个：
ct state established accept
ct state invalid drop
tcp reject with tcp reset
reject
如果你丢掉了无效的数据包，什么也不会发生，下载不受影响。如果根本没有防火墙规则，那么 TCP 堆栈就会这样做：忽略此类数据包，而不是使用 TCP RST 对其做出反应。
答案2
如果你没有明确删除无效连接，那么 nftables 将遵循以下规则。如果没有匹配的规则，它将应用链的默认策略（默认情况下为“接受”）。
所以这取决于您遵循的规则和默认策略。但是，如果您的规则之一是接受传入到端口 22 的数据包，那么您确实需要首先丢弃无效连接。