Linux nft set 与 map 的动态黑白名单实现与 ipset 迁移路径

nft set 不能替代 ipset 的 timeout 功能，因其不支持 per-entry 超时，添加 timeout 会报语法错误；需用 nft map 存时间戳并由用户态判断过期。

为什么 nft set 不能直接替代 ipset 的 timeout 功能

因为 nft set 本身不支持 per-entry 超时（timeout），只有 nft map 配合 ct timeout 或用户态定时器才能模拟。你写 add element inet Filter blackhole { 192.168.1.10 timeout 30s } 会报错：Error: syntax error, unexpected timeout。

常见错误现象：照着 ipset 的用法往 nft set 里加 timeout，命令直接失败；或者误以为 auto-merge 或 gc-interval 能清理过期项——它们只管内存回收，不管逻辑过期。

• nft set 适合静态或长期有效的黑白名单（如固定封禁 IP）
• 需要自动过期的条目，必须用 nft map + 用户态脚本（比如用 date 和 awk 定期扫描清理）或配合 conntrack 超时策略
• 性能上，set 查询是 O(1) 哈希查找；map 在无索引 key 时也是 O(1)，但维护成本更高

如何用 nft map 实现带时间戳的动态黑名单

核心思路：把 IP 当 key，把 unix 时间戳当 value，查表时用当前时间减去 value 判断是否超时。nft 本身不提供时间函数，所以匹配逻辑必须由用户态完成，nft 只负责存和查。

使用场景：ssh 暴力破解临时封禁（封 10 分钟）、http 接口限流后的冷却期、CI 测试环境临时放行。

• 定义 map：nft add map inet filter ip_blacklist { type ipv4_addr : time; }（注意：time 是伪类型，实际存整数秒）
• 插入带时间戳条目：echo $(date +%s) | xargs -I{} nft add element inet filter ip_blacklist { 192.168.1.20 : {} }
• 匹配规则要分两步：先 lookup 获取时间戳，再由 shell 脚本判断是否过期；nft 规则本身不能做减法运算
• 兼容性提醒：time 类型在 kernel ipv4_addr : ct label + 外部标记，或退化为定期 nft delete

ipset 迁移到 nft 的三步落地检查清单

不是所有 ipset 功能都有直接对应，迁移前必须逐项验证，否则上线后丢包或漏封。

• 检查 ipset 类型：如果原用 hash:net,iface（网段+接口绑定），nft 没有等价结构，只能拆成多个 set 或改用 fib 表匹配
• 确认 timeout 粒度：ipset 支持毫秒级 timeout，nft map 存的是秒级整数，误差在 1 秒内可接受，但高频短时封禁（如每 500ms 封一个）不适合
• 验证原子性：ipset 的 add/del 是原子的；nft 的 add element 单条是原子的，但批量操作需用 nft -f 加载脚本，否则中间状态可能生效
• 路径依赖：旧脚本里写的 /sbin/ipset -L blacklist 得替换成 nft list map inet filter blacklist，注意输出格式完全不同，解析逻辑要重写

真正容易被忽略的点：规则加载顺序与 set 更新时机

很多人以为只要 nft add element 成功，新 IP 下一秒就进黑名单——其实不一定。nft 规则匹配发生在数据包进入 hook 点的瞬间，而 set 内容更新是异步生效的，尤其在高并发插入时，存在极短窗口期（微秒级）导致漏匹配。

更麻烦的是：如果你用 cron 每分钟 reload 整个 ruleset（nft -f /etc/nftables.conf），所有 set 会被清空重建，期间新连接可能绕过黑名单。

• 正确做法：对活跃 set 使用 nft add/delete element 增量更新，永不 reload 全局配置
• 避免在 prerouting hook 里直接 lookup 大型 set（>10 万条），kernel 查找延迟会上升，建议拆成多个小 set 按地域/用途分离
• 调试时别只信 nft list set，要用 tcpdump -n -i any host 192.168.1.20 实测封禁效果，因为路由决策可能早于 nft hook