几个月前,我使用 debian 推荐的程序将 debian 笔记本电脑的防火墙从 迁移iptables
到nftables
,一切似乎都很好。现在,几个月后,我正在仔细检查由该迁移过程创建的规则集,尝试学习语法nftables
,并查看一些我不理解并怀疑可能不正确的基于计数器的规则。我还没有发现nftables
wiki 是一个有用的教育资源,也没有找到任何其他在线教育资源来解决此类问题:
默认自动迁移规则集包括以下内容:
table inet filter {
chain INPUT {
type filter hook input priority 0; policy drop;
counter packets 123 bytes 105891 jump ufw-before-logging-input
counter packets 123 bytes 105891 jump ufw-before-input
counter packets 0 bytes 0 jump ufw-after-input
counter packets 0 bytes 0 jump ufw-after-logging-input
counter packets 0 bytes 0 jump ufw-reject-input
counter packets 0 bytes 0 jump ufw-track-input
}
前两个counter
陈述是引起我注意的例子。我是否正确,他们说“跳转到 ufw-before-foo 部分中的规则,但仅在收到前 123 个数据包和前 105891 个字节之后”。
- 为什么不立即从数据包0字节0开始呢?
- 为什么不使用 nftables 似乎支持的 >= 语法?
- 这些数字是任意的吗?可能是由于迁移过程中出现故障?
上述规则集包括跳转到以下链,可能存在类似的问题。这是它的一个片段:
chain ufw-before-input {
iifname "lo" counter packets 26 bytes 3011 accept
ct state related,established counter packets 64 bytes 63272 accept
ct state invalid counter packets 0 bytes 0 jump ufw-logging-deny
ct state invalid counter packets 0 bytes 0 drop
...
}
- 为什么接受决策是基于接收到的 26 个或 64 个先前数据包?
- 防火墙在启动和网络发现/连接后可以随时刷新,那么为什么要丢弃所有这些初始数据包呢?
正如我上面提到的,这些规则已经实施了几个月,所以我想知道它们可能会产生什么负面影响。我想到的唯一候选者是,笔记本电脑有时会很难建立 wifi 连接(尤其是从睡眠状态恢复后),而附近的第二台笔记本电脑则没有这样的问题。
- 这些丢弃数据包的规则是否会成为 wifi 连接协商困难的罪魁祸首?
答案1
不,解释要简单得多:柜台语句有可选参数数据包和字节它显示当数据包达到其所在规则时计数器计数的数据包数和字节数。柜台前无过滤器,任何因此,数据包(包括环回)将增加值,因此它可以非常早且快速地发生。进行转换的工具看到了 iptables 默认计数器,并选择转换其值以确保保真度。
因此,通常当您编写规则时,您不会设置这些值,而是counter
单独放置一个简单的值,并且它们都获得默认值 0。当数据包穿过它时,这些值会增加。可选,尤其是在命名计数器中使用时有状态对象甚至可以显示和重置(使用类似的东西nft reset counters
),为了进行某种形式的记账,可以在编写规则集时设置这些值:通常是在恢复重新启动之前保存的规则集时。这仅当用作指定变体时才能重置,而不是“内联”匿名计数器。它们不能用于改变规则中的匹配,有没有其他选择而不是展示它们。
您遇到的任何 wifi 问题不能由任何原因引起柜台陈述。
如果现在您想使用数据包计数来限制 nftables 防火墙中规则的使用,根据需要有几种不同的方法:
另一个有状态对象配额(同样可以匿名使用,但是仅当使用命名时才能重置)。然后,您可以让规则永远不匹配或根据其计数开始匹配。
有限制计数语句费率。例如,如果您担心日志规则可能会淹没日志文件,您可以使用它来限制完成的日志数量。它还可以限制某些资源的速率(通常与其他具有 conntrack 的过滤器一起使用)。
有了足够新的 nftables(0.9.2?)和内核(4.18?),就有了CT计数 连接跟踪表达式使用 conntrack 来计算已建立连接的数量,通常是为了限制对某些资源(ssh、Web 服务器...)的并发访问