网络管理 on KnightLi的博客

理解 nftables 框架：表、链、规则和集合

Sat, 18 Apr 2026 10:31:12 +0800

学习 nftables 时，容易一开始就陷入命令细节：怎么添加规则、怎么删除 handle、怎么写端口匹配。命令当然重要，但如果先把框架概念理清楚，后面读规则、排查问题和设计规则集都会轻松很多。

可以把 nftables 理解成一套分层结构：

table 负责隔离规则空间。
family 决定规则处理哪类网络协议。
chain 决定规则在什么阶段执行。
rule 负责具体匹配和动作。
set、map、verdict map 用来减少重复规则，让规则集更易维护。

下面按概念逐层说明。

table：规则的命名空间

table 是 nftables 里最外层的规则容器。不同 table 之间相互隔离，因此常见做法是把一组相关规则放进同一个 table。

例如，你可以把过滤规则、NAT 规则或自定义测试规则分开放。这样做的好处是边界清晰：调试时知道自己在改哪一组规则，清理时也不容易误删无关内容。

table 本身不会直接处理数据包。真正参与数据包处理的是 table 里面的 chain 和 rule。

family：规则面对哪类协议

创建 table 时需要选择 family。它决定这张表里的规则适用于哪类数据包。

常见 family 可以这样理解：

ip：只处理 IPv4。
ip6：只处理 IPv6。
inet：同时处理 IPv4 和 IPv6。
arp：处理 ARP。
bridge：处理桥接层流量。
netdev：更靠近网络设备入口，适合较早阶段处理流量。

日常写普通防火墙规则时，inet 很常用。它可以把 IPv4 和 IPv6 规则放在同一个 table 里，避免维护两套结构相似的规则。

chain：规则执行的位置

chain 是 rule 的列表。数据包进入某个 hook 后，会按顺序经过 chain 里的规则。

chain 大致可以分为两类：

基本 chain：挂到内核网络路径的某个 hook 上，会被数据包流程主动调用。
常规 chain：不直接挂 hook，需要被其他规则跳转调用。

基本 chain 通常会指定几个关键属性：

type：这条 chain 的用途，例如 filter、nat、route。
hook：挂在哪个处理阶段，例如 prerouting、input、forward、output、postrouting。
priority：同一个 hook 上有多条 chain 时，谁先执行。
policy：没有规则匹配时的默认动作，常见是 accept 或 drop。

理解 chain 的关键是：规则不是“随便写在哪里都能生效”。同一条规则放在 input、forward 或 output，含义完全不同。

rule：匹配条件加动作

rule 是 nftables 里真正做判断的地方。它通常由两部分组成：

匹配条件：例如源 IP、目标 IP、协议、端口、接口、连接状态。
动作：例如 accept、drop、reject、counter、jump、return。

规则会按顺序求值。数据包命中某条会终止流程的动作后，就不会继续执行后面的规则。没有命中时，则继续往下走，直到 chain 结束或触发默认策略。

这也是为什么规则顺序很重要：更具体的规则通常要放在更宽泛的规则前面，否则可能永远没有机会被执行。

set：把一组值放在一起

如果有很多 IP、端口或接口需要匹配，直接写多条规则会很难维护。set 用来把一组同类型的值集中管理。

例如，一组可信 IP、一组禁止访问的端口、一组需要限速的地址，都可以放进 set。规则只需要判断某个值是否属于这个 set。

set 的好处是：

规则数量更少。
可读性更好。
后续增删元素更方便。

当规则里出现大量重复条件时，通常就该考虑用 set。

map：把匹配值映射成结果

map 可以理解成“查表”。它根据一个输入值返回一个结果。

例如，不同端口映射到不同标记，不同地址映射到不同处理参数，都可以通过 map 表达。相比写多条 if/else 式规则，map 更集中，也更容易维护。

set 关心的是“是否在集合里”，map 关心的是“这个值对应什么结果”。

verdict map：把匹配值映射成动作

verdict map 是 map 的一个重要用法：它把匹配值映射成 verdict，也就是规则动作。

例如，不同 IP 段可以对应 accept、drop 或跳转到不同 chain。这样可以把很多分支判断压缩到一个结构里。

当规则集开始变复杂时，verdict map 很有用。它能减少重复规则，也能把策略表达得更像一张表，而不是一长串判断语句。

从概念看规则设计

设计 nftables 规则时，可以按这个顺序思考：

先确定规则属于哪个 family。
再决定放进哪个 table。
然后选择合适的 hook 和 chain。
最后编写具体 rule。
如果重复条件很多，再引入 set、map 或 verdict map。

这样写出来的规则会更容易维护，也更容易排错。

小结

nftables 的概念并不复杂，但层级很重要：

table 管规则边界。
family 管协议范围。
chain 管执行位置。
rule 管匹配和动作。
set、map、verdict map 管复杂度。

先理解这些概念，再去看具体命令，会比直接背命令更稳。尤其是在规则集变多以后，概念清楚能帮助你判断：问题到底出在协议范围、执行阶段、规则顺序，还是匹配条件本身。

参考

https://docs.redhat.com/zh-cn/documentation/red_hat_enterprise_linux/10/html/configuring_firewalls_and_packet_filters/concepts-in-the-nftables-framework

nftables 快速入门：表、链、规则和常用操作

Sat, 18 Apr 2026 10:22:07 +0800

nftables 是 Linux 上常用的包过滤和防火墙规则管理工具。如果只是做设备联网控制、流量统计、端口匹配或简单限速，不需要一开始就把完整规则体系全部学完，先理解三个概念就够了：

table：规则的容器。
chain：规则执行的位置，通常会挂到某个 hook 上。
rule：真正的匹配条件和动作。

下面整理一套最小可用的入门流程，适合先在测试环境里做实验。

基础结构

先准备几个变量，后面的命令会复用：

table=customtable
chain=custom_control
target=drop
ip=192.168.18.251
mac=00:00:01:02:03:04

创建一个同时支持 IPv4 和 IPv6 的 inet table：

`1`	`nft add table inet $table`

再创建一条挂在 forward 阶段的 chain：

`1`	`nft add chain inet $table $chain { type filter hook forward priority 0\; }`

这里的 type filter 表示做过滤规则，hook forward 表示处理经过转发的数据包。

常见匹配方式

按源 IP 匹配，通常可以理解为设备上传方向：

`1`	`nft add rule inet $table $chain ip saddr $ip $target`

按目标 IP 匹配，通常可以理解为设备下载方向：

`1`	`nft add rule inet $table $chain ip daddr $ip $target`

按 MAC 地址匹配时，可以用 ether saddr 控制上行：

`1`	`nft add rule inet $table $chain ether saddr $mac $target`

需要注意的是，在经过桥接、转发或地址转换的网络里，下行包未必能可靠用目标 MAC 过滤。实际做设备联网控制时，优先从 ether saddr 或 IP 规则开始验证。

匹配端口时，可以同时覆盖 TCP 和 UDP：

`1`	`nft add rule inet $table $chain { tcp, udp } dport 22 $target`

如果要匹配端口范围，可以使用比较表达式：

`1`	`nft add rule inet $table $chain tcp dport \>= 1024 $target`

统计单个设备流量

如果只是想统计某个 IP 的上下行流量，可以用 counter return。这样命中后记录计数并返回，后面还有其他统计规则时，能减少继续匹配的开销。

1
2

nft add rule inet $table $chain ip saddr $ip counter return
nft add rule inet $table $chain ip daddr $ip counter return

查看统计结果：

`1`	`nft list chain inet $table $chain`

如果需要看到每条规则的 handle，加上 -a：

`1`	`nft -a list chain inet $table $chain`

handle 很重要，因为 nftables 删除单条规则时通常要靠它定位。

简单限速

限速可以用 limit rate over。例如按 MAC 地址限制超过指定速率的流量：

rate=10
unit=mbytes

nft add rule inet $table $chain ether saddr $mac limit rate over $rate $unit/second drop

这里的 mbytes、kbytes 可以按日常理解的 M、K 来看，不需要再手动做 8 倍换算。实际使用时建议先用较宽松的值测试，确认命中方向和效果后再收紧。

删除和清理规则

先查看带 handle 的规则：

`1`	`nft -a list chain inet $table $chain`

再按 handle 删除某条规则：

`1`	`nft delete rule inet $table $chain handle <handle>`

清空某条 chain：

`1`	`nft flush chain inet $table $chain`

删除 chain：

`1`	`nft delete chain inet $table $chain`

删除整个 table：

`1`	`nft delete table inet $table`

日常调试时，建议先只清理自己创建的 table，不要直接改系统或其他服务自动生成的 table。这样即使规则写错，也更容易回滚。

使用建议

使用 nftables 时，可以优先自己创建独立的 table 和 chain。这样做有两个好处：

不容易和系统已有规则混在一起。
调试、清空和删除都更安全。

另外，规则写完后一定要用 nft list chain 看实际命中情况。尤其是 MAC、接口、端口和限速规则，不同设备、桥接方式和系统版本下表现可能不同，先小范围测试比一次性写复杂规则更稳。

参考

https://www.right.com.cn/forum/thread-8369750-1-1.html