firewalld配置咨询：实现ipset匹配未命中时转由接口zone处理

这个问题我之前也碰到过，核心原因就是firewalld默认在nftables里用goto指令处理zone匹配——一旦流量命中some-ips-allowed对应的ipset规则，就会跳转到该zone的处理链，若链内没有允许对应端口的规则，就会执行zone的默认目标（通常是拒绝），不会回到主链继续匹配接口对应的something-trusted zone。

下面给你两种可行的解决方案，优先推荐用firewalld原生的direct规则，避免直接修改nft规则带来的持久化问题：

方案一：用firewalld Direct规则替换默认的goto为jump #

firewalld的Direct规则允许我们直接插入自定义的nftables规则，以此覆盖默认的zone匹配逻辑：

1. 先移除some-ips-allowed zone中绑定的ipset源（避免默认生成goto规则）：

   firewall-cmd --permanent --zone=some-ips-allowed --remove-source=ipset:some-ip-set
   

2. 添加Direct规则，用jump指令替代默认的goto，这样流量在some-ips-allowed zone未匹配到允许规则时，会回到主链继续处理：

   firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT_ZONES 0 -m set --match-set some-ip-set src -j jump filter_IN_some-ips-allowed
   

3. 重新加载firewalld配置使修改生效：

   firewall-cmd --reload
   

这种方法完全基于firewalld的原生命令，配置会被持久化，且不会和firewalld的其他管理逻辑冲突。

方案二：直接修改nftables规则（谨慎使用） #

如果Direct规则不符合你的需求，也可以直接修改nftables规则，但要注意firewalld重新加载配置时会覆盖手动修改的规则，所以需要额外做持久化处理：

1. 先查看当前的INPUT_ZONES链规则，确认目标行：

   nft list chain filter filter_INPUT_ZONES
   

2. 将对应的goto指令替换为jump：

   nft replace rule filter filter_INPUT_ZONES 'ip saddr @some-ip-set goto filter_IN_some-ips-allowed' 'ip saddr @some-ip-set jump filter_IN_some-ips-allowed'
   

3. 为了避免firewalld重启后规则丢失，你可以把这条修改命令添加到firewalld的启动钩子脚本中（比如/etc/firewalld/firewalld.conf中配置的PreStartCommands），或者用Direct规则来持久化（本质和方案一类似）。

这种方法只要只修改目标规则，不触碰firewalld管理的其他链，一般不会出现不可预测的冲突，但长期维护性不如方案一。

测试的时候建议先不加--permanent参数做临时配置，验证功能正常后再持久化，避免影响业务流量。

备注：内容来源于stack exchange，提问作者rubikonx9