Gentoo Linux Kernel 从 6.12 升级至 6.18

最近把 Gentoo Linux 的内核从 6.12 升级到了 6.18，过程本身没什么特别的，还是照旧 make oldconfig、检查一下必要的网络选项、编译、安装、重启。

不过重启之后发现 iptables 规则不太对劲。尤其是手搓路由器这种环境，iptables 一旦不正常，影响就比较直接：转发、NAT、docker、xray 这些依赖防火墙规则的东西都会跟着出问题。

问题现象

先看内核配置，会发现从 Linux Kernel 6.17 之后，默认情况下 iptables legacy 相关支持已经不是以前那种顺手可用的状态了。

比较典型的是这个配置：

1# CONFIG_NETFILTER_XTABLES_LEGACY is not set

如果系统里 iptables 还指向 legacy backend，那么升级内核之后就很容易出现规则加载失败、命令执行异常，或者某些依赖 iptables 的服务启动之后没有正确写入规则的情况。

这类问题表面上看起来像是 iptables 坏了，实际上是用户态工具和内核里的 netfilter backend 没对上。

legacy 与 nft

现在的方向已经很明确了：继续使用 iptables 命令没问题，但 backend 应该切到 nftables。

也就是说，日常脚本里仍然可以写：

1iptables -t nat -A POSTROUTING -s 192.168.88.0/24 -o ${WAN} -j MASQUERADE
2iptables -A FORWARD -i ${LAN} -o ${WAN} -j ACCEPT
3iptables -A FORWARD -i ${WAN} -o ${LAN} -m state --state RELATED,ESTABLISHED -j ACCEPT

只是命令背后不再走 xtables-legacy，而是走 xtables-nft。对于大多数常规规则来说，这个切换是比较平滑的。

Gentoo 中切换 iptables backend

在 Gentoo 里处理这个问题很简单，直接用 eselect 看一下当前的 iptables symlink 指向哪里：

1eselect iptables list

输出大概是这样：

1Available iptables symlink targets:
2  [1]   xtables-legacy-multi
3  [2]   xtables-nft-multi *

如果 * 在 xtables-legacy-multi 后面，就需要切换到 nft：

1eselect iptables set 2

切换完成后再确认一下：

1eselect iptables list

确保 * 在 xtables-nft-multi 后面：

1Available iptables symlink targets:
2  [1]   xtables-legacy-multi
3  [2]   xtables-nft-multi *

也可以顺手看一下 iptables 当前使用的 backend：

1iptables --version

正常情况下应该能看到类似这样的输出：

1iptables v1.8.x (nf_tables)

如果看到的是：

1iptables v1.8.x (legacy)

那说明还没有切过去。

重新加载规则

切换完成之后，建议重新加载一次自己的防火墙脚本。

比如我的路由器上，一般会把规则集中写在一个 shell 文件里，启动时由 openrc 执行。切换 backend 之后，直接重新执行一遍：

1/etc/local.d/iptables.start

或者如果是自己写的 service，就重启对应服务：

1rc-service iptables restart

然后检查 filter 和 nat 表：

1iptables -t filter -nL --line-numbers
2iptables -t nat -nL --line-numbers

如果规则能正常显示，NAT 和转发也恢复了，那基本就没问题了。

小结

这次升级其实不是 iptables 语法本身的问题，而是内核升级之后，legacy backend 这条路越来越不适合继续用了。

在 Gentoo 里最直接的处理方式就是：

1eselect iptables list
2eselect iptables set 2
3iptables --version

把 iptables 切到 xtables-nft-multi 之后，原来的规则脚本大多数情况下可以继续使用。后面如果有时间，还是应该逐步把复杂规则迁移到原生 nftables，毕竟这才是后续长期维护更舒服的方向。