从 iptables 到 nftables：防火墙规则编写技巧与平滑迁移实战指南

52JinY 助手

最近帮公司做了一次服务器防火墙规则的迁移，把十几台机器上跑了多年的 iptables 规则全部迁到了 nftables，踩了不少坑，顺便把这段时间的心得整理出来，希望对还没开始动手的朋友有点参考价值。

先说说背景。iptables 这东西用了这么多年，老实说大家都习惯了，语法虽然啰嗦，但肌肉记忆已经形成了。`-A INPUT -p tcp --dport 22 -j ACCEPT` 这种写法闭着眼睛都能敲出来。但问题是，随着规则越来越多，性能下降很明显，而且同一条规则在 iptables、ip6tables、arptables 里要写三遍，维护起来真的痛苦。nftables 从设计上就解决了这个问题，一套规则框架支持 IPv4、IPv6、ARP 等协议族，规则合并写在一起，清爽很多。

规则语法上，nftables 的表达方式更接近自然语言，但也需要一段适应期。比如 iptables 里的多端口匹配 `-m multiport --dports 80,443` 在 nftables 里可以直接写成 `tcp dport { 80, 443 }`，用集合的方式表达，逻辑上其实更直观。状态匹配也从 `-m state --state ESTABLISHED,RELATED` 变成了 `ct state { established, related }`，整体来说更简洁。不过刚开始写的时候容易在大括号、分号这些细节上犯错，nftables 对语法的容错性比 iptables 低，少个分号直接报错，这点要注意。

迁移这件事，官方提供了一个工具叫 `iptables-translate`，理论上可以把旧规则自动翻译成 nftables 语法。我实际用下来，简单规则翻译基本没问题，但涉及到复杂的 LOG 目标、自定义链的跳转、以及某些第三方模块的匹配条件，翻译出来的结果不一定能直接用，还是得手动核对。建议的做法是先用工具批量翻译，然后逐条审查，尤其是那些带注释说明用途的规则，一定要搞清楚业务含义再确认翻译是否准确。

有一个坑我觉得特别值得单独说一下，就是规则的优先级（priority）问题。nftables 的链在创建时需要指定优先级数值，数值越小越先执行，这和 iptables 里表的固定执行顺序（raw → mangle → nat → filter）不完全对应。如果你原来的规则依赖特定的表执行顺序做一些操作，迁移时一定要仔细核对优先级设置，否则规则看起来都对，但行为就是不符合预期，排查起来相当费时间。

另外就是调试体验。nftables 有一个 `nft monitor` 命令，可以实时监控规则匹配事件，配合 `meta nftrace` 做规则跟踪，比 iptables 时代用 LOG 目标打日志要方便一些。迁移完成后我花了两天时间专门用这个工具做验证，把关键流量路径都跑了一遍，确认和原来行为一致才算放心。

总体感受是，nftables 在设计理念上比 iptables 进步了很多，规则的可读性和维护性明显更好，性能上对规则数量多的场景也有改善。迁移的成本主要集中在初期的学习和验证阶段，只要不是在生产高峰期仓促上线，稳扎稳打地做，其实没有想象中那么可怕。现在主流发行版基本上都在推 nftables，Debian 10 以后、RHEL 8 以后默认防火墙后端都已经切过去了，该适应的早点适应，拖着用老工具迟早要还这个债。