1. 为什么绕不开firewalld配置文件搞Linux运维的尤其是常年跟CentOS、Rocky、Fedora这些Red Hat系发行版打交道的老哥对firewalld绝对不陌生。日常开个端口、放行个服务大多数人第一反应就是敲firewall-cmd --add-port8080/tcp这当然没错但一旦遇到服务器重启、防火墙规则丢了几百条、或者要批量下发配置到几十台机器的时候直接在命令行敲命令就完全不现实了。我最早接触firewalld配置文件是被一个线上事故逼的。生产环境有一次被人改了zone配置结果firewall-cmd --reload之后规则全部回滚服务端口全部失联机房远程卡直接断掉的那种崩溃感到现在还记忆犹新。后来花了整整一个晚上把/etc/firewalld/目录下的文件全部翻了一遍才真正搞明白firewalld的设计思路它所有的运行时状态和持久化规则本质上都是XML文件。命令行工具firewall-cmd只是操作这些文件的一层皮真正决定防火墙行为的永远是你磁盘上的配置文件。所以这篇文章专门聊聊firewalld配置文件怎么改、怎么理解、怎么排错。适合已经会用firewall-cmd开端口、但还没彻底搞懂规则是怎么被持久化的同学也适合需要在多台机器上批量标准化防火墙配置的运维场景。读完你至少能做到不依赖firewall-cmd也能手工写出一份完整可用的zone配置并且知道改完之后怎么安全地让它生效。2. 配置文件体系与加载优先级2.1 两个核心目录必须分清楚firewalld的配置全部以XML格式存储分布在两个目录下/usr/lib/firewalld/系统自带默认配置是软件包安装时写入的出厂设置不同的Linux发行版有差异。/etc/firewalld/用户自定义配置也就是我们日常需要修改的地方。两个目录同名文件的逻辑是后者覆盖前者。比如系统默认的public.xml里放行了ssh服务而你自己在/etc/firewalld/zones/public.xml里写了一份只放行http的配置那么重载之后实际生效的就是/etc下的这份文件。/usr/lib下的所有内容本质上就是“模板”永远不要直接去改它因为软件包升级时会被覆盖所有自定义内容都应该放在/etc/firewalld/下面。搞清楚了这一个优先级关系很大一部分“改了没生效”的灵异事件就找到了根源。2.2 核心文件与目录结构逐项拆解用tree /etc/firewalld看一眼大概长这样/etc/firewalld/ ├── firewalld.conf # 守护进程主配置默认zone、IPv6支持、日志级别等 ├── icmptypes/ # ICMP类型定义限流ping之类的时候会用到 ├── ipsets/ # IP集合用于批量管理大量的IP地址段 ├── helpers/ # FTP、SIP等需要额外helper模块的协议 ├── services/ # 预定义服务一个xml定义一组端口 ├── zones/ # 区域规则核心中的核心 ├── direct.xml # 直接传递nftables/iptables规则的入口 ├── lockdown-whitelist.xml # 白名单锁定模式下谁有权限改防火墙 └── policy/ # 策略规则policy-based forwarding相关这份清单里日常改动频率最高的是zones/和firewalld.conf其次是services/。剩下几个属于进阶场景才碰的东西我也是到后期做复杂网络隔离方案的时候才真正用上。后面逐一讲。3. firewalld.conf主配置与默认zone修改3.1 默认zone的作用机制firewalld.conf里最重要的参数是DefaultZone。它决定了当一个不匹配任何source或接口绑定的流量进来时会被丢进哪个zone处理。比如你是内网服务器通常希望默认拒绝所有外部入站流量那就把默认zone设为drop或者block如果你是在调试环境希望所有流量默认放行设成trusted就能快速打通网络。我见过很多用户搞混一个概念修改默认zone不等于改网卡绑定的zone。/etc/firewalld/firewalld.conf里的DefaultZonepublic只是兜底如果某张网卡在nmcli或zone配置里明确绑定了internal那么该接口流量进的是internal不归默认zone管。3.2 修改默认zone的正确姿势假设我要把默认zone从public改成dmz具体操作是编辑/etc/firewalld/firewalld.conf# 打开文件找到这一行 DefaultZonepublic # 改成 DefaultZonedmz然后执行firewall-cmd --reload用firewall-cmd --get-default-zone确认是否生效。这里有个比较容易踩的坑firewall-cmd --reload不会让已经绑定的接口或source立即跳到新zone它只改变“未来新入站流量”的归属。如果多张网卡已经在跑业务你改了默认zone现有连接可能仍然走原zone直到连接中断。3.3 conf里的其他高频参数我翻firewalld.conf的时候一般重点看这几个参数它们在特定场景下特别有用CleanupOnExitno默认yes即firewalld服务停止时自动清理所有防火墙规则。生产环境如果短时间需要手工介入iptables调试建议设为no否则一重启服务规则全没了。IPv6_rpfilteryesIPv6反向路径过滤防伪造源地址攻击的一般不建议关。IndividualCallsno是否对每个规则单独调用iptables/nft命令调试的时候设成yes能精确到单条规则但性能差一些。FirewallBackendnftables现在的主流版本都基于nftables后端旧脚本如果还在用iptables命令直接管理需要确认兼容性或者迁移写法。4. zones目录规则的主战场4.1 一个zone文件到底能写什么拿一个生产服务器常用的/etc/firewalld/zones/webserver.xml举例?xml version1.0 encodingutf-8? zone targetDROP shortWeb Server/short descriptionProduction web server zone, allow only 80/443/description service namessh/ service namehttp/ service namehttps/ port port8080 protocoltcp/ source address10.0.0.0/24/ forward/ /zone一个zone文件的内容选项很多日常最常用的有这些配置项作用示例target该zone对未匹配规则的流量的默认动作ACCEPT/DROP/REJECT/defaulttargetDROPservice引用预定义的service比如http其实是80/tcp的一组别称service namehttps/port直接开放指定端口和协议port port10050 protocoltcp/protocol按IP协议号放行而不只是TCP/UDPprotocol valueicmp/source匹配源地址可以搭配target实现白名单source address192.168.1.5/forward是否允许zone内流量转发到其他zoneforward/masquerade开启SNAT伪装做端口转发/NAT时必须用masquerade/rule富规则最灵活但最复杂后面单开一节rule familyipv4source address1.2.3.4/accept//ruleicmp-block阻止特定ICMP类型比如禁pingicmp-block nameecho-request/4.2 target的语义与常见误用target这个属性很多人理解不透。它管的是进入该zone且没有匹配任何规则的那部分流量也就是“兜底策略”。取值为default采用编译进内核的默认行为通常就是接受最宽松ACCEPT明确接受所有未被规则匹配的流量DROP直接丢弃客户端表现为超时无响应REJECT拒绝并返回错误报文客户端能立刻感知“连接被拒”。我自己做服务器隔离的通常习惯是targetDROP 白名单式放行宁丢勿放调试阶段才临时改成ACCEPT配好规则验证完再切回DROP。4.3 手工新增一个zone假设我要为数据库服务器建一个独立zone只让应用服务器网段访问3306端口。我不需要用firewall-cmd --new-zone去命令式创建直接在目录下新建文件就行vim /etc/firewalld/zones/db.xml内容?xml version1.0 encodingutf-8? zone targetDROP shortDatabase Zone/short descriptionOnly allow app subnet access/description service namessh/ port port3306 protocoltcp/ source address192.168.10.0/24/ /zone保存后firewall-cmd --reload firewall-cmd --get-zones没意外的话db就会出现在zone列表里。接着把网卡或源地址绑定到这个zonefirewall-cmd --zonedb --add-source192.168.10.0/24 --permanent firewall-cmd --reload这里值得多说一句绑定source之后zone内的source和命令行--add-source可以并存最终规则取并集。所以为了维护简单要么走纯命令、要么走纯文件别两边同时铺开写改起来容易乱。5. services目录与端口复用5.1 看懂service文件的结构/etc/firewalld/services/下预置了一堆服务定义其中ssh.xml这种内容很典型?xml version1.0 encodingutf-8? service shortSSH/short descriptionSecure Shell protocol for remote login/description port port22 protocoltcp/ /service说白了service就是对一组端口协议组合的命名封装。你不用每次都写22/tcp直接引用service namessh/即可语义清晰而且统一管理方便。5.2 自定义服务文件业务系统如果用的是特殊端口比如某个中间件监听18080/tcp那我不建议在zone里到处散落port标签更专业的做法是自建一个service文件比如/etc/firewalld/services/myapp.xml?xml version1.0 encodingutf-8? service shortMyApp Middleware/short descriptionCustom middleware service port 18080/description port port18080 protocoltcp/ /service之后在任意zone文件里直接service namemyapp/或者在命令行用firewall-cmd --zonepublic --add-servicemyapp --permanent这个service文件一旦建好所有zone可以共用。那当业务改了端口你只需要改一个文件所有引用这个service的zone统一生效。这个复用思路在大规模集群里非常重要几十台机器逐台修改port标签会疯掉的。6. 端口转发与富规则6.1 端口转发的配置实现firewalld的端口转发一般指把某个端口收到的流量转发到另一台机器或另一个端口。比如内网有一台机器只监听3306但希望外部访问13306时能穿透到它。这里的关键是必须显式开启masquerade否则firewalld不会做SNAT转发链条是断的。需要在zone文件里写的核心片段masquerade/ forward-port port13306 protocoltcp destination address192.168.20.5 port3306/ /forward-port很多人只写了forward-port忘了加masquerade/结果从外部访问13306就是不通。原因也不难理解目标机器192.168.20.5收到了来自防火墙的数据包但它看到源地址是外部IP回包时不知道往哪走所以要靠防火墙做一次源地址伪装把回程流量揽回来。命令行等价写法是firewall-cmd --zonepublic --add-masquerade --permanent firewall-cmd --zonepublic --add-forward-portport13306:prototcp:toport3306:toaddr192.168.20.5 --permanent firewall-cmd --reload6.2 端口范围与目标地址省略场景转发端口是连续范围时也可以写范围forward-port port2000-3000 protocoltcp destination address10.0.0.8/ /forward-port省略destination里的port属性表示转发到目的地址时保留原端口。这种场景常见于代理节点原封不动把整段端口转发到后端。我这里插一句实际经验能做源地址限定的尽量加上。比如只允许公司出口IP转发可以在zone里加一条source address企业出口IP/不然端口转发等于在全网开放扫描器稍微扫一下就暴露了。6.3 富规则搞定复杂逻辑纯service和port只能做“开端口”这种简单动作。如果需求是“允许A网段访问80/443拒绝B网段其余DROP”那就需要富规则。rule familyipv4 source address192.168.30.0/24/ service namehttp/ accept/ /rule rule familyipv4 source address10.0.0.0/8/ reject/ /rule富规则里能从四个维度组合source源地址、destination目的地址、service/port/protocol服务或端口、accept/reject/drop/log/masquerade动作。它的本质是firewalld帮你生成一段nftables规则链所以逻辑上可以很灵活代价是阅读和维护成本上升。我的经验是优先用简单标签只有简单标签表达不了需求时才上富规则别把配置文件写成天书。7. direct.xml与底层规则直通7.1 什么时候才用direct.xml先明确一个概念direct.xml是为了兼容旧时代iptables直通需求而存在的接口。很多人喜欢什么东西都往direct.xml里塞这是非常坏的习惯因为一旦用direct你等于绕过了firewalld对规则对象的管理firewall-cmd --list-all根本看不到这些规则排错只能去查nft list ruleset。我自己只在两种场景下用direct有一些极特殊的链型控制比如要单独控制INPUT链上某一行规则的顺序firewalld原生接口无法实现时从旧iptables脚本迁移、短期过渡用的。7.2 配置示例与隐患开FTP被动模式端口时传统方式需要在iptables里加载nf_conntrack_ftp模块并加规则firewalld在helper里其实有对应配置。但如果你非要用direct写法大概是这样?xml version1.0 encodingutf-8? direct rule priority0 tablefilter ipvipv4 chainINPUT -p tcp --dport 21 -j ACCEPT /rule /direct这里有讲究的是priority数值越小的优先级越高。多条direct规则混合时数值错乱会造成预期之外的匹配顺序轻则规则不生效重则防火墙洞开。我建议非必要不碰direct现代firewalld的富规则已经能覆盖绝大部分需求没必要做这种高风险的自残式配置。8. 实操从配置到生效的全流程演练8.1 场景设定与备份策略假设我现在接手了一台新上线的Rocky Linux 9服务器需求如下默认拒绝所有外部入站流量只允许SSH对外开放80和443端口给Nginx用10.0.0.0/8内网段可以访问服务器的3306和6379配置8080端口转发到另一台内网主机的80端口。动手之前第一件事备份现有配置这是规矩mkdir -p /backup/firewalld-$(date %F) cp -a /etc/firewalld /backup/firewalld-$(date %F)/8.2 编写zone文件我直接写一个prod-server.xml?xml version1.0 encodingutf-8? zone targetDROP shortProd Server/short descriptionProduction access control/description service namessh/ service namehttp/ service namehttps/ source address10.0.0.0/8 port port3306 protocoltcp/ port port6379 protocoltcp/ /source masquerade/ forward-port port8080 protocoltcp destination address192.168.100.10 port80/ /forward-port /zone注意source标签里嵌了port表示这些端口只对该网段开放。先把文件放到/etc/firewalld/zones/下然后重载firewall-cmd --reload firewall-cmd --get-zones看到prod-server出现在列表里就说明文件解析成功。8.3 把网卡绑到zone上新zone创建后不会自动接管任何流量需要显式绑定。我用nmcli把业务网卡ens192绑定到这个zone上nmcli connection modify ens192 connection.zone prod-server nmcli connection up ens192这样网卡流量就归新zone管理了。验证方法firewall-cmd --get-active-zones输出里应该能看到prod-server以及它关联的接口。8.4 即时生效与彻底重启的区别上面用的是firewall-cmd --reload它做的是平滑重载保留现有连接状态适合生产环境。另一种是firewall-cmd --complete-reload相当于把防火墙规则全部清掉再重新加载会中断所有现有连接通常只有深度调试的时候才用。命令行配了规则之后必须带--permanent参数再去reload否则规则只存在于运行时内存里重启机器或者firewall-cmd --reload后就没了。我个人习惯是先不写--permanent试一把确认业务没受影响再补一条带--permanent的最后reload一次。之所以这么做是为了防止遗忘了参数导致放过期规则把防火墙开放成筛子。9. 常见问题与排查技巧实录9.1 配置没生效的三大真相我处理过的故障里九成都是这三个原因rule写错了或文件位置不对reload时报错或静默跳过可以用journalctl -u firewalld -n 50搜XML解析错误日志有问题它会明确告诉你哪一行出问题。没有--permanent规则只活在运行时检查/etc/firewalld/zones/*.xml确认里面到底有没有内容。默认zone和接口绑定zone语义搞混public.xml改了不代表所有机器都用public接口可能绑了别的zone。排查之前可以先跑一个命令把所有当前生效规则dump出来firewall-cmd --list-all-zones对症看实际的规则列表比瞎猜高效得多。9.2 reload正常但防火墙没动作另外有一种坑是firewalld服务明明跑着但规则没进去。这类问题大多出在系统里同时存在旧版iptables service或者nftables配置。Red Hat系新版本默认用nftables后端但如果你机器上有个老的iptables.service在开机时先跑了可能两边互相覆盖。排查思路systemctl status firewalld systemctl status iptables nft list ruleset | grep -i filter_INPUT都是0输出的话说明规则确实没进去就要看zone文件里的XML有没有闭合、属性有没有写对。一个未闭合的标签会导致整个文件被跳过但firewalld经常不报明确错误只是日志里留一行warning。9.3 端口转发不生效的检查顺序转发问题排查我按这个顺序来确认masquerade开没开确认内核ip_forward开关有没有打开sysctl net.ipv4.ip_forward为0的话手动echo 1 /proc/sys/net/ipv4/ip_forward确认目标机器有没有防火墙自己挡了端口确认源地址匹配是否误伤了转发流量。这四个环节里最阴间的是第4个。如果zone文件里有source address10.0.0.0/8这种限制转发流量源地址可能不在这个网段导致数据包被targetDROP直接丢了但转发规则本身又是完好的。9.4 XML语法检查技巧手工改XML难免手滑。推荐一个小习惯改完先做语法校验python3 -c import xml.dom.minidom,sys; xml.dom.minidom.parse(/etc/firewalld/zones/prod-server.xml)没输出就是没问题有输出会直接报出行号。火急火燎地直接在线上reload结果reload成功但规则没进去还不如花两秒做一次校验。10. 多机批量下发与版本管理10.1 标准化配置的目录打包手头管几十台机器的时候一台台上去敲命令不现实。做法是把整套配置做成一个标准化目录结构firewalld-conf/ ├── firewalld.conf ├── zones/ │ ├── prod-server.xml │ └── internal.xml └── services/ └── myapp.xml打包后用rsync或scp分发到目标机器的/etc/firewalld/下rsync -av ./firewalld-conf/ roottarget:/etc/firewalld/ ssh roottarget firewall-cmd --reload注意分发前先确认目标机器没有正在运行的关键业务连接reload虽然平滑但也有极小概率导致长连接中断。稳妥起见我会先挑一台业务低峰期试一次确认脚本没问题再批量推。10.2 git管理防火墙配置的收益我后来把/etc/firewalld整个目录纳入git管理每次变更都提交一次。好处不用多说谁改了啥、什么时候改的、改之前是什么样清清楚楚。出问题直接git diff就能定位。初始化仓库的时候有个点要注意firewalld运行时有可能因为自动保存规则去写一些文件/etc/firewalld/zones/下有时候会生成public.xml.old这种备份建议.gitignore里忽略掉只跟踪真正的配置源文件。10.3 上线前后的验证清单最后分享一份我每次改完配置都会过一遍的验证清单验证项命令期望结果zone是否加载firewall-cmd --get-zones新zone在列表中接口绑定是否生效firewall-cmd --get-active-zones接口归属正确端口是否可访问nc -vz 127.0.0.1 8000通默认zone是否符合预期firewall-cmd --get-default-zone与配置一致配置是否持久化重启firewalld服务后测试规则还在11. 根据我个人经验的一些体会跟firewalld配置文件打了这么多年交道我慢慢养成几个习惯说不上标准但对少踩坑特别有帮助。第一能不碰direct.xml就不碰。direct规则跳出firewalld的管理体系出了问题排查成本高到离谱。真的需要特殊规则时先用富规则写写不出来的场景再考虑direct而且必须做好注释和文档。第二多利用--permanent配合reload而不是--runtime-to-permanent。--runtime-to-permanent看起来很美好一键把运行时规则固化但它同时会把一些调试用的临时规则也固化下来容易把配置搞脏。第三善用系统自带模板。每次不确定XML标签怎么写我就跑去/usr/lib/firewalld/下面看默认模板比如想写ICMP规则时看看icmptypes/里有哪些类型想写helper时看看helpers/的示例。系统自带的东西永远是语法来源最准确的学习资料。第四配置文件老出错的周期往往伴随着业务变更的高峰。多留一份心思把变更记录写好比抱怨“怎么又登录不上了”有用得多。特别是多人共管的服务器每个维护者都有自己的一套习惯统一用配置文件管理之后至少大家的规范是同一个不会再出现你敲你的命令、我改我的文件这种混乱局面了。firewalld这套配置体系初看只是几个XML文件真正深入进去就明白它设计的核心思想就是让规则可描述、可持久化、可统一管理。用命令是顺手用配置文件才是把防火墙真正管起来的态度。