不同RHEL版本下Firewalld添加源IP后阻断SSH的行为差异问题

老哥，我之前维护不同版本RHEL服务器的时候也踩过这个坑，这本质是firewalld在版本迭代中调整了zone流量匹配优先级的逻辑，导致看似相同的配置出现截然不同的行为！

问题根源：Firewalld版本间的匹配规则变化 #

你用到的两个firewalld版本（0.6.3 vs 1.2.5），核心差异在于同时配置了接口和源IP的zone，流量匹配的优先级顺序不同：

• Server A（RHEL7.9，firewalld 0.6.3）：旧版本的匹配逻辑是接口优先——只要流量是从zone绑定的接口（ens32）进入的，不管源IP是否在zone的sources列表里，都会直接匹配该zone的规则。所以你添加源IP后，原来允许的SSH服务依然对所有从ens32进来的流量生效，不会阻断原有连接。
• Server B（RHEL9.3，firewalld 1.2.5）：新版本的匹配逻辑是源IP优先——当zone同时配置了sources和接口时，只有源IP在sources列表里的流量才会匹配该zone；其他从接口进来但源IP不在列表里的流量，会转而匹配系统的默认zone（如果默认zone没开启SSH服务，就会直接阻断SSH连接）。

解决方案（两种思路） #

根据你的需求不同，可以选下面两种方案：

方案1：让Server B和Server A行为一致（接口优先）

如果想保留旧版本的接口优先逻辑，修改firewalld全局配置：

1. 编辑/etc/firewalld/firewalld.conf，找到ZonePriority参数，修改为：

ZonePriority=interface

2. 重启firewalld生效：

systemctl restart firewalld

注意：这是全局设置，会影响所有zone的匹配顺序，适合需要统一旧版本行为的场景。

方案2：遵循新版本逻辑，规范配置（更推荐）

新版本的源优先逻辑其实更安全，建议适配这个逻辑来配置：

• 如果你想同时允许特定源IP和接口上的其他IP访问SSH，可以给public zone添加一条允许所有IP访问SSH的富规则：

# 临时生效
firewall-cmd --add-rich-rule='rule family="ipv4" service name="ssh" accept' --zone=public
# 永久生效
firewall-cmd --add-rich-rule='rule family="ipv4" service name="ssh" accept' --zone=public --permanent
# 重载配置
firewall-cmd --reload

• 或者更严谨的做法：新建一个专门的zone处理特定源IP的规则，保留public zone处理接口的默认流量：

# 新建专属zone
firewall-cmd --new-zone=trusted-source --permanent
# 添加信任源IP到该zone
firewall-cmd --add-source=xxx.xxx.xxx.xxx --zone=trusted-source --permanent
# 给该zone开启需要的服务（比如SSH、MySQL）
firewall-cmd --add-service=ssh --zone=trusted-source --permanent
firewall-cmd --add-service=mysql --zone=trusted-source --permanent
# 重载配置生效
firewall-cmd --reload

这样既实现了特定源的访问控制，又不影响原有接口的正常SSH连接。

验证方法 #

你可以在Server B上执行以下命令确认配置：

# 查看当前活跃zone的配置
firewall-cmd --get-active-zones
# 查看所有zone的规则，重点看默认zone是否开启SSH
firewall-cmd --list-all-zones | grep -A 10 "default"

如果默认zone没有SSH服务，那非源IP的SSH流量就会被阻断，这就是你看到的差异原因啦！

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