集群环境下的防火墙挑战
在搭建Web服务、数据库集群或微服务架构时，多台服务器协同工作成了常态。比如你公司上线了一个高并发的电商平台，后端用了6台应用服务器做负载均衡，外加3台Redis做主从集群。这时候如果防火墙没配好，轻则服务连不上，重则整个集群被扫描攻击。
和单机部署不同，集群内部节点之间频繁通信，像ZooKeeper的心跳、Kafka的Broker交互、MySQL主从复制，这些流量都得在防火墙规则里放行。只开放80和443端口？那可能刚启动就被“隔离”了。
明确通信矩阵是第一步
别急着敲命令，先画出节点之间的访问关系。比如应用服务器要连接数据库集群的3306端口，Redis主节点要和从节点同步数据（默认端口6379），监控系统要拉取各节点的指标（可能走9100端口）。把这些写下来，比直接上iptables试错靠谱得多。
使用主机名或IP段批量管理
手动给每台机器加规则太累，尤其节点动态扩容时。建议按子网划分，比如所有应用服务器放在192.168.10.0/24网段，数据库在192.168.20.0/24。这样防火墙可以直接放行整个子网间的特定端口。
以CentOS 7常用的firewalld为例：
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.10.0/24" port protocol="tcp" port="3306" accept'
firewall-cmd --reload这条规则就允许应用集群访问数据库端口，不用一个个IP去加。
注意内部端口的安全暴露
很多人觉得“内网=安全”，于是把Redis、Etcd这些组件的端口全开给内网。但一旦某台机器被攻陷，横向移动轻而易举。正确的做法是精确到IP或最小网段。比如只有Zookeeper集群的三台机器能互相访问2181端口：
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.5.11" port protocol="tcp" port="2181" accept'
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.5.12" port protocol="tcp" port="2181" accept'
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.5.13" port protocol="tcp" port="2181" accept'避免规则冲突和顺序问题
iptables和firewalld都有规则优先级。如果你前面加了一条拒绝所有入站的规则，后面再放行端口也没用。建议先清空测试环境的规则，用--list-all确认当前策略。生产环境变更前记得备份：
firewall-cmd --list-all > firewall-backup.txt日志不能少，排查靠它救命
打开防火墙日志，能看到被拒绝的连接尝试。比如在rich rule里加上log：
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.0.0/8" port protocol="tcp" port="22" log prefix="SSH_BLOCKED" level="info" reject'之后在/var/log/messages里就能搜到异常登录行为，及时发现扫描动作。
云环境别忽略安全组
如果你用的是阿里云、AWS这类平台，主机防火墙只是第一层。安全组才是真正的网络大门。比如ECS实例虽然开了6379端口，但安全组没放行，外部照样连不上。反过来，安全组开了但主机防火墙拦着，也通不了。两边得对齐。
实际运维中见过太多人改了iptables却忘了安全组，或者调好了安全组却发现firewalld默认zone是drop。这种双层控制必须同时考虑。