nftables 拼接集合怎样按地址和端口同时匹配

如果规则要求“某个源 IPv4 地址只能访问指定 TCP 端口”，可以把地址和端口声明成一个拼接键，再用 nftables named set 维护允许的组合。关键不是把两个条件分别放进集合，而是让集合类型与规则表达式保持同样的字段顺序：集合使用 ipv4_addr . inet_service，规则就使用 ip saddr . tcp dport。

官方资料：https://wiki.nftables.org/wiki-nftables/index.php/Concatenations

这种写法适合“地址和端口必须成对出现”的白名单。例如允许 203.0.113.10 访问 8443，不等于允许这个地址访问所有端口，也不等于允许所有地址访问 8443。

先把两个条件看成一个键

nftables 的 concatenation 会把两个或多个选择字段组合起来，作为 set、map 或 verdict map 的查找键。对本文场景而言，一条数据不是单独的地址或端口，而是一个二元组：

因此，集合中的 203.0.113.10 . 8443 与 203.0.113.10 . 9443 是两个不同元素。查找时如果实际报文的源地址或目标端口任一项不同，就不会命中同一个元素。

声明 named set 与规则表达式

先定义一个保存地址和服务端口组合的集合，再让输入链上的规则使用同样的表达式查找它。下面是可保存到 nftables 配置文件的示例；代码中的注释说明每个边界，示例本身不代表已经在某台机器上执行。

# 创建独立的 inet 表，示例只承载本文的匹配关系
add table inet address_port_demo

# 集合的第一个字段是 IPv4 地址，第二个字段是服务端口
add set inet address_port_demo web_allow {
    type ipv4_addr . inet_service
    elements = {
        203.0.113.10 . 8443,
        198.51.100.8 . 443
    }
}

# 只有源地址和 TCP 目标端口组成的二元组同时命中，才接受报文
add chain inet address_port_demo input { type filter hook input priority filter; policy drop; }
add rule inet address_port_demo input ip saddr . tcp dport @web_allow accept

这里有三个容易混淆的点。第一，inet_service 表示服务端口这一类字段，而不是把端口写成字符串。第二，规则中使用的是 ip saddr，对应集合里的 IPv4 地址字段；如果把它换成 ip daddr，查找语义就变了。第三，点号两边的字段顺序必须和集合类型一致，不能把集合声明成地址、端口，却在规则里按端口、地址查找。

写入、查看和变更集合元素

如果集合已经由规则文件声明，后续调整通常只需要增删元素，不必复制一条新规则。命令行写入时要保持同样的二元组格式，并注意 shell 对花括号和分号的处理。

# 查看集合的类型和现有元素，先确认字段顺序
nft list set inet address_port_demo web_allow

# 增加一个地址与端口的组合，不增加新的过滤规则
nft add element inet address_port_demo web_allow { 203.0.113.20 . 8443 }

# 删除同一个组合元素，地址和端口都要写对
nft delete element inet address_port_demo web_allow { 203.0.113.20 . 8443 }

# 查看链上的查找表达式，确认它仍是 ip saddr . tcp dport
nft list chain inet address_port_demo input

动态维护的核心是“元素变化，规则不变”。例如新增一台来源主机访问同一个端口，只新增一个组合元素；如果同一地址还要访问另一个端口，则新增另一个组合元素，而不是把端口单独塞进一个全局集合。

排查不匹配与范围边界

字段方向写反

最常见的问题是集合想表达“来源地址 + 目标端口”，规则却写成了 ip daddr . tcp dport，或把 tcp dport 写成了 tcp sport。先用 nft list set 和 nft list chain 对照两边的字段，不要先改地址值。

协议字段不一致

tcp dport 只描述 TCP 目标端口。UDP 服务即使使用相同的数字端口，也不是同一个协议字段；需要支持 UDP 时，应明确设计另一条匹配表达式和对应的集合类型，不能把 TCP 端口名当成所有传输协议的通用字段。

地址族与类型不一致

ipv4_addr 只接收 IPv4 地址。如果策略同时覆盖 IPv6，应重新设计地址族和集合类型，或将 IPv4、IPv6 规则分开说明。把 IPv6 文本直接写进 IPv4 集合，属于类型不匹配，不是元素顺序问题。

不要把精确组合误当成 interval 范围

拼接集合的基本语义是多个字段组成一个键；它不自动把端口数字扩展成连续范围。需要地址或端口范围时，必须查阅对应 set 的 interval 能力并单独确认版本和语法，不能因为元素使用了点号就推断它具有范围匹配语义。本文的示例只覆盖精确的地址、端口组合。

元素命中不等于整条业务请求成功

集合只参与报文分类。即使复合键命中，后续仍可能受到连接状态、应用监听、路由、其他链规则或业务鉴权影响。排查时可以把“复合键是否命中”和“服务是否能完成请求”分成两个问题，避免把 nftables 的集合结果当成应用层结果。

怎样判断是否该用拼接集合

选择的判断标准不是“语法越复杂越好”，而是策略是否天然由多个字段共同决定。字段越多，集合类型、规则表达式和变更工具越需要统一；如果团队无法稳定维护这三处，拆成更清晰的规则反而更容易排障。

常见问题

为什么集合元素中间要写点号

点号表示 concatenation，把多个选择字段组成一个复合键。它不是小数点，也不是把地址和端口拼成字符串。

能不能写成两个独立集合再同时查找

可以分别表达两个条件，但那不是本文的“成对组合”语义。两个独立集合通常表示地址和端口可以自由组合，而拼接集合表示只有登记过的地址、端口二元组才允许命中。

修改集合后是否需要重写规则

在规则已经引用 named set 的前提下，通常只需增删集合元素。若修改了字段类型、字段顺序或查找表达式，就不再是单纯的元素变更，需要按完整规则变更处理。

为什么看起来命中了地址，最后还是被拒绝

地址命中只是第一字段满足，端口、协议、链路径和后续策略仍可能不满足。先把实际报文的源地址、目标端口和传输协议与集合元素逐项对照。

参考资料

• nftables 官方 Wiki：Concatenations
• nftables 官方 Wiki：Sets
• nftables 官方 Wiki：Counters