说实话Linux服务器上最容易被折腾出问题的就是防火墙。尤其是CentOS用户刚装完系统高高兴兴把服务跑起来了结果外部访问死活不通要么就是各种“操作不当”把远程连接给整断了只能灰溜溜地去机房或者VNC控制台救火。今天就把CentOS防火墙的这些事一次性聊透从原理到实操从常见踩坑到排查链路都摊开讲清楚。这篇内容主要解决几类问题CentOS上的防火墙到底怎么开、怎么关、重启后怎么保证配置还在端口开放后为什么还是连不上防火墙规则和iptables、SELinux是什么关系以及日常运维里我见到频率最高的那些“玄学问题”的真实原因。不管是刚接触Linux的新手还是干了几年运维需要查漏补缺的老手这篇都能给你一些有价值的东西。1. CentOS防火墙到底是什么先搞清firewalld和iptables的关系很多人一提到防火墙就是“iptables”一说防火墙操作就是“service iptables stop”这个习惯到了CentOS 7以后其实已经过时了。CentOS 7开始系统默认的防火墙管理工具换成了firewalld它和iptables不是对立关系firewalld底层依然会调用iptables内核模块来下发规则只是在用户态换了一套更友好的管理接口。换句话说你用firewalld配置规则最后还是落在netfilter上但规则的管理方式、持久化方式、zone模型都和以前完全不一样了。1.1 两代防火墙机制的区别与选择CentOS 6时代大家习惯用iptables命令直接增删规则然后通过service iptables save把规则写入/etc/sysconfig/iptables文件。这套方式的逻辑是“顺序匹配”规则一行一条从上往下走匹配到就执行对应动作。优点是灵活强大缺点也很明显规则一多脑子里得维护一张“规则执行顺序图”稍不注意就会把规则加错位置导致流量被错误拦截或者错误放行。CentOS 7之后默认的firewalld采用了“zone”模型官方预置了trusted、home、internal、work、public、dmz、block、drop等几个区域。每个zone定义了不同的信任级别比如public默认拒绝绝大多数入站流量只放行跟出站连接关联的回包trusted默认放行所有流量。这种模型的好处是你不需要操心复杂的规则链只需要想清楚“这个网卡信任程度是哪个级别”然后往对应的zone里加规则就行。那能不能在CentOS 7上继续用iptables可以。你有两种选择一种是把firewalld停掉然后安装iptables-services另外一种是继续保留firewalld直接用iptables命令临时写规则但这样规则不会持久化重启就丢。我的建议是除非你有历史脚本和规范必须沿用iptables否则新环境直接习惯firewalld因为它对规则的处理确实更友善。而且大多数云厂商的安全组规则也是类似“放行清单”的思路上手没有违和感。1.2 防火墙的核心概念zone与默认行为zone是理解firewalld的门槛。系统里默认区域是public你可以通过firewall-cmd --get-default-zone查看当前默认zone。如果你的服务器只有一块网卡而且没有特别指定过zone那么这块网卡就属于默认zone。换句话说你平时执行firewall-cmd --add-port8080/tcp实际是在给public这个区域增加放行规则。每个zone自己维护一张规则清单包括放行的服务、端口、协议、源地址等。不同zone之间的规则互相独立比如你在public放行了8080但网卡如果绑定的是internal区域那你访问8080还是不通。这点特别容易被忽视很多人配置了半天规则最后发现网卡挂在别的zone上那前面做的全是无用功。另外还要澄清一点firewalld的默认策略是“放行出站、拦截入站”也就是说服务器主动往外发连接不受影响但外部主动访问服务器的连接默认会被拒。这也是为什么你开了服务本地测试没问题外部就是连不上——最大嫌疑就是防火墙没放行对应端口。理解了zone和默认策略之后我们再来看具体怎么操作思路就会清晰很多。2. 防火墙基础操作开启、关闭、重启与开机自启防火墙的基础操作看着简单但很多人对“临时操作”和“永久操作”分不清导致改完配置重启服务器之后又回到原样或者因为直接关了防火墙导致服务全裸奔。这一节把服务管理的各种细节展开讲照着做基本不会出岔子。2.1 管理防火墙服务状态的核心命令在CentOS 7及以上的系统里firewalld是一个系统服务通过systemd来管理。查看当前状态用systemctl status firewalld如果只想知道防火墙功能本身是否在运行可以执行firewall-cmd --state它会直接输出running或者not running比翻一堆journal日志更直观。启动防火墙用systemctl start firewalld停止用systemctl stop firewalld重启用systemctl restart firewalld。这些命令大家应该不陌生但有一个细节很多人会踩坑如果你修改了firewalld的配置或者手动编辑了zone的XML文件想让它生效不一定需要restart执行firewall-cmd --reload就够了。这个reload会重新加载永久的配置而且关键是不会中断已经建立的连接在线上环境非常实用。还有一个细节是systemctl stop firewalld和firewall-cmd --state之间的矛盾。某些情况下你明明执行了systemctl stop firewalld但再执行firewall-cmd --state时发现它提示running这是怎么回事多半是因为firewalld服务启动了自恢复机制或者你使用了一些直接操作iptables的工具导致状态判断异常。遇到这种情况别慌看systemctl status firewalld为准必要时systemctl mask firewalld彻底禁用防止其他进程把它拉起来。2.2 开机自启与临时关闭为什么建议用永久配置而不是一直disable把防火墙关了确实能一了百了端口直接全通但代价是服务器彻底暴露在网络上。如果机器是内网环境或者仅仅是本地开发机也许还能接受如果是公网服务器关了防火墙等于把大门敞开任何端口扫到就进这是拿安全性换省事风险极高。如果你只是需要临时调试某个服务可以用systemctl stop firewalld关闭调试完再systemctl start firewalld恢复。切忌用systemctl disable firewalld来“永久关闭开机自启”除非你有充足的网络层面隔离方案。disable的意思不只是本次关闭而是以后每次开机都不加载防火墙规则这个状态一旦忘了恢复服务器基本等于裸奔。正确的做法是保持防火墙服务常开用zone和端口规则来做精细化放行。这样即使以后有未知的新服务启动也不会因为你忘了关某个口子而直接被外部扫描到。在实际生产中我更倾向于在云平台上用安全组做第一层过滤再用系统防火墙做第二层防护双重保险比单靠哪个都稳妥。安全组负责大范围的进出口控制系统防火墙负责本机精细化规则比如只允许某个IP访问某个端口这种粒度安全组也能做但系统防火墙做起来同样顺手。3. 开放端口实战从命令到配置文件的完整路径这部分是大多数人最关心的。开放端口用命令无非就是firewall-cmd --add-port端口/协议但这里面的门道有不少。直接说结论不加--permanent的规则是临时规则重启或者reload之后就会消失加了--permanent才是永久规则但需要reload之后才会生效。这个机制让不少人懵过明明加了--permanent为什么执行了--add-port之后马上又用--query-port查询显示没有放行因为永久规则在reload之前不会加载到runtime环境里。3.1 最常用的firewall-cmd端口操作放行一个TCP端口的标准写法是firewall-cmd --permanent --add-port8080/tcp firewall-cmd --reload第一条命令把8080端口的TCP协议加入永久规则第二条命令让规则生效。如果你想放行UDP协议把tcp换成udp即可比如DNS解析常用的53端口就是UDP。查看当前已经放行的端口列表firewall-cmd --list-ports这个命令输出的是runtime环境里已经生效的端口规则。如果你刚加了--permanent但还没reload此时是看不到新规则的这属于正常现象别急着怀疑命令没执行成功。查询某个具体端口是否放行firewall-cmd --query-port8080/tcp输出yes表示放行no表示没有放行。这个命令同样查询的是runtime状态不是永久配置。很多人在这个细节上栽跟头永久配置明明写了但查询为no原因就是没reload。删除端口规则firewall-cmd --permanent --remove-port8080/tcp firewall-cmd --reload删除之后记得也要reload否则runtime里仍然保留着放行规则。这里我建议删规则的时候慎重尤其是公网服务器删了之后外部访问就会断最好在业务低峰期操作。3.2 通过配置文件开放端口手写XML与直觉式编辑firewall-cmd命令最终会把永久规则写入/etc/firewalld/zones/目录下的XML文件。以默认的public区域为例对应的文件是/etc/firewalld/zones/public.xml。如果你不想用命令也可以直接编辑这个XML文件加端口。一个典型的public.xml内容如下?xml version1.0 encodingutf-8? zone shortPublic/short descriptionFor use in public areas./description service namessh/ service namedhcpv6-client/ port port8080 protocoltcp/ /zone在zone标签里增加port port8080 protocoltcp/保存后执行firewall-cmd --reload就可以生效。不过说实话我不太推荐手动编辑XML文件。原因有几个第一XML语法有严格规范标签写错了半个字符firewalld直接起不来到时候只能进控制台恢复非常狼狈第二命令行的--add-port本身就是在帮你维护这个XML没必要自己去碰。但理解这个文件的机制是有用的比如你需要批量迁移防火墙规则、或者写脚本批量添加端口时直接操作XML反而更高效。如果你真的想手改XML我建议先备份原文件修改后用firewall-cmd --reload验证如果firewalld没有报错说明语法没问题再检查firewall-cmd --list-ports能否看到新规则。一旦firewalld启动失败立刻用备份文件恢复。3.3 端口区间、服务名与富规则进阶开放方式除了单个端口firewalld还支持端口区间、服务名和富规则。端口区间写法firewall-cmd --permanent --add-port10010-10020/tcp firewall-cmd --reload这段命令开放了从10010到10020之间的所有TCP端口适合一些使用动态端口范围的程序比如FTP被动模式、RTP媒体流服务等。服务名方式比端口号更语义化。比如你想开放HTTP服务不用记80端口直接firewall-cmd --permanent --add-servicehttp firewall-cmd --reloadfirewalld内置了很多常用服务定义用firewall-cmd --get-services可以查看完整列表。用服务名的好处是以后如果标准端口变了虽然不太可能你只需要更新系统服务定义不用改业务规则。富规则rich rule是firewalld里最灵活的手段适合做“只允许特定IP访问特定端口”之类的精细控制。比如只放行192.168.1.100这台机器访问本机的3306端口firewall-cmd --permanent --add-rich-rulerule familyipv4 source address192.168.1.100/32 port protocoltcp port3306 accept firewall-cmd --reload富规则的语法比较啰嗦但是表达能力强。类似的场景还有把某个IP段拉黑firewall-cmd --permanent --add-rich-rulerule familyipv4 source address10.0.0.0/8 drop firewall-cmd --reload使用富规则的人相对少因为很多公司直接用云安全组替代了这个功能。但在纯物理机或者内网环境富规则是唯一不需要额外工具就能实现“IP白名单”的方式。4. 配置留存与迁移让规则在重启后依然生效防火墙规则最怕的就是“配置一时爽重启火葬场”。很多人用--add-port放行端口后服务立刻通了一切正常结果某天重启服务器端口又连不上了。原因就是漏掉了--permanent参数。这一节我们把持久化和迁移的细节讲透。4.1 --permanent的作用与reload机制firewalld内部管理着两套规则一套是runtime规则也就是当前内存中生效的规则另一套是permanent规则也就是持久化在磁盘XML文件里的规则。firewall-cmd --add-port默认只改runtime不加--permanent就意味着规则不会写入XML文件重启服务或者重启系统之后就会丢失。而加了--permanent只是写入磁盘不会立刻在runtime里生效需要reload或者重启firewalld服务。理解这个机制之后你应该能推断出几种操作的结果。如果只执行了--add-port8080/tcp当前能访问重启后失效如果只执行了--permanent --add-port8080/tcp磁盘上有了记录但当前没生效需要reload如果两个都执行了这是最标准的“当前生效重启保留”方案。有些习惯用iptables的老手一开始很不适应这个两段式逻辑但用熟之后会发现它其实更安全——你可以在命令行里试错确认没问题了再永久化不至于一次误操作就把环境搞乱。firewall-cmd --reload和firewall-cmd --complete-reload是有区别的。前者保留运行时状态只是应用一下永久配置不会断掉现有连接日常用这个就够后者是完全重新加载等于把所有规则丢弃再重新加载一遍会导致现有连接全部中断。线上环境千万别用--complete-reload除非你有足够的心理准备面对一波工单。4.2 备份与迁移防火墙规则服务器防火墙规则的管理应当纳入变更流程就像代码一样需要可回滚。firewalld的规则都集中在/etc/firewalld/目录最简单粗暴的备份方式就是备份整个目录cp -r /etc/firewalld /root/firewalld-backup-$(date %F)恢复时把备份目录里的文件覆盖回去再reload即可。这个操作我建议在改动较大规则集之前做一次尤其是生产环境有了备份就算把规则改崩了几分钟之内就能恢复。如果要在多台机器之间迁移规则可以先在源机器上导出再到目标机器导入。可以用firewall-cmd --list-all-zones把所有zone的当前规则全部列出来但这只是人眼查看不适合直接导入。更靠谱的方式是直接拷贝XML文件。例如把public区域的规则从机器A同步到机器Bscp /etc/firewalld/zones/public.xml root目标机器IP:/etc/firewalld/zones/拷贝完成后在目标机器上执行firewall-cmd --reload规则就过去了。注意如果目标机器上原来有自定义zone也要一并拷贝否则引用缺失zone的网卡可能报错。另外如果两台机器的网卡接口名不同还得检查网卡和zone的绑定关系是否正确绑定关系配置在/etc/firewalld/zones/里的XML中或者在/etc/sysconfig/network-scripts/ifcfg-网卡名里通过ZONE字段指定。5. 常见问题与排查技巧实录防火墙这东西出问题时的表象千奇百怪但症结往往就那么几个。我把这些年遇到的高频问题整理了一下方便你遇到状况时快速定位。5.1 端口不通的排查链路开放了端口还是连不上别急着重启防火墙按照下面的顺序逐步排查基本都能找到原因。第一步确认服务本身在监听。执行ss -tlnp | grep 端口号看对应端口是否有LISTEN状态。如果压根没有监听那问题不在防火墙先把服务启动起来再说。另外注意有些服务默认监听在127.0.0.1上比如某些框架的开发模式外部网络访问这个IP是永远连不上的需要把监听地址改成0.0.0.0才能对外提供服务。这一步很多人会忽略明明防火墙全放开了还是不通最后发现是应用监听地址的问题。第二步确认防火墙放行状态。用firewall-cmd --query-port端口/tcp检查runtime规则。如果输出no用--add-port或者--permanent --add-port放行。这里提醒一点如果服务是用UDP协议通信的排查时要带上/udp很多人只放行了TCP导致UDP端口一直不通。第三步检查SELinux。CentOS默认开启SELinux它和防火墙不是一回事但同样会拦截网络访问。查看状态用getenforce如果是Enforcing状态可以临时用setenforce 0关闭再测试如果确认是SELinux拦截可以通过设置对应的布尔值来解决而不是直接关掉SELinux。比如允许httpd访问网络setsebool -P httpd_can_network_connect 1第四步检查云平台安全组。如果你用的是云服务器除了系统防火墙控制台里的安全组也会做过滤。很多情况下系统防火墙已经放行了但安全组入方向没放行对应端口一样连不上。这个排查点特别容易被忽略甚至有些老运维也会在这里卡住。云服务器的访问链路是“外部网络 - 安全组 - 系统防火墙 - 应用”安全组挂在最外层系统防火墙规则做得再完美安全组不放行也是白搭。第五步测试网络连通性。本地试一下ping 服务器IP不通的话可能是网络路由或者ICMP被拦截用telnet 服务器IP 端口测试指定端口是否通通的话会显示连接建立提示不通会卡住然后报错。有条件的话用手机流量试能排除本地网络环境的问题。整个排查链路我整理成了一张表方便你收藏排查步骤命令/操作可能原因服务监听检查ss -tlnp服务未启动、监听地址错误防火墙规则检查firewall-cmd --query-port未放行端口、未reloadSELinux检查getenforceSELinux拦截安全组检查云控制台入方向未放行网络连通性ping、telnet路由不通、ICMP被禁5.2 规则不生效的典型原因明明添加了永久规则也执行了reload为什么端口还是不通这类问题桌面运维也遇到过。常见原因有三类。第一类是网卡没有绑定到你配置规则的zone。用firewall-cmd --get-zone-of-interface你的网卡名查看网卡归属。比如你的网卡是eth0但eth0被分配到了internal zone而你是在public里加的规则那这个规则跟eth0一点关系都没有。可以通过firewall-cmd --zonepublic --change-interfaceeth0把网卡绑定到public或者直接往网卡所在zone加规则。第二类是规则顺序问题虽然firewalld的zone模型不像iptables那样严格要求顺序但富规则的优先级是高于普通端口规则的。如果你写了一条drop的富规则哪怕后来又用--add-port放行了端口drop规则依然会先拦截掉。所以在有富规则的场景下要检查断言关系别让两条规则“打架”。第三类是服务本身没有监听在所有网卡上。排查方法前面提过看ss -tlnp的监听地址。如果只监听127.0.0.1那无论防火墙怎么放行都没用因为数据包在到达应用之前系统根本不会把外部流量转发到loopback地址上。这种情况要去改应用的监听配置而不是折腾防火墙。5.3 防火墙要不要关安全与便利的平衡“防火墙关闭有影响吗”这个问题说实话得看场景。如果是开发环境、内网测试环境可以考虑在可控网络内关闭防火墙提升调试效率。但如果机器有公网IP哪怕只是挂一个简单的服务页面也不建议关防火墙。现在网络上的扫描工具横行全开放的服务器被入侵的案例太多了我见过不少因为图省事关防火墙结果数据库被人扫到弱密码直接拖库的悲剧。如果觉得防火墙规则太麻烦一个折中方案是保留防火墙开启状态设置默认拒绝所有未知入站流量只放行必要的服务和端口。常见的Web服务器放行80和443SSH登录放行22或者自定义端口数据库只对特定的内网IP段放行。这样即使某个服务有漏洞攻击者也无法从外部立刻访问到这个端口多了一层有效的缓冲。还有一个小技巧如果你经常在本地用SSH连接服务器而服务器IP又不是固定的可以考虑给SSH端口做成IP白名单。当然这会增加管理负担IP变了就得去控制台或者用其他方式重新配置规则所以大多数场景下不建议把所有端口都做IP限流保留服务端口开放用强密码加key登录更实际。6. 一些经验之谈关于防火墙的运维习惯最后说点个人体会我觉得比命令本身更值钱。一是养成“改前备份、改后验证”的肌肉记忆。不管是加规则还是删规则先备份/etc/firewalld目录操作后立刻用firewall-cmd --list-ports、firewall-cmd --list-all验证最好再用外部网络环境实际连接一次确认没有误伤。二是不要盲目复制网上的命令。网上的教程质量参差不齐有些命令直接照抄会出大问题。比如网上常看到一句话“永久关闭防火墙”直接systemctl disable firewalld这个在生产环境用非常危险。你要先判断自己的业务形态、网络环境再决定要不要执行。命令本身没有对错执行的人得清楚后果。三是定期审查防火墙规则。很多服务器上的防火墙规则是历史遗留物早期开放了某个端口做测试后来业务下架了规则却一直留着变成隐形风险。我建议每季度或者半年做一次规则审计把不用的端口规则删掉保持最小化原则。虽然麻烦但对安全的意义很大。四是把防火墙操作记入变更记录。这个习惯适合团队协作的场景。在配置变更时记一笔谁改的、改了哪个端口、为什么改、什么时候改的、对应的服务是什么。有时候一个问题排查不出来翻一下变更记录立刻能定位是哪次改动引入的问题比抓瞎强太多。如果你在配置防火墙时踩过什么奇怪的坑欢迎在评论区留个言大家一起避雷。
CentOS防火墙实战：firewalld与iptables全解析，端口开放与排查指南
说实话Linux服务器上最容易被折腾出问题的就是防火墙。尤其是CentOS用户刚装完系统高高兴兴把服务跑起来了结果外部访问死活不通要么就是各种“操作不当”把远程连接给整断了只能灰溜溜地去机房或者VNC控制台救火。今天就把CentOS防火墙的这些事一次性聊透从原理到实操从常见踩坑到排查链路都摊开讲清楚。这篇内容主要解决几类问题CentOS上的防火墙到底怎么开、怎么关、重启后怎么保证配置还在端口开放后为什么还是连不上防火墙规则和iptables、SELinux是什么关系以及日常运维里我见到频率最高的那些“玄学问题”的真实原因。不管是刚接触Linux的新手还是干了几年运维需要查漏补缺的老手这篇都能给你一些有价值的东西。1. CentOS防火墙到底是什么先搞清firewalld和iptables的关系很多人一提到防火墙就是“iptables”一说防火墙操作就是“service iptables stop”这个习惯到了CentOS 7以后其实已经过时了。CentOS 7开始系统默认的防火墙管理工具换成了firewalld它和iptables不是对立关系firewalld底层依然会调用iptables内核模块来下发规则只是在用户态换了一套更友好的管理接口。换句话说你用firewalld配置规则最后还是落在netfilter上但规则的管理方式、持久化方式、zone模型都和以前完全不一样了。1.1 两代防火墙机制的区别与选择CentOS 6时代大家习惯用iptables命令直接增删规则然后通过service iptables save把规则写入/etc/sysconfig/iptables文件。这套方式的逻辑是“顺序匹配”规则一行一条从上往下走匹配到就执行对应动作。优点是灵活强大缺点也很明显规则一多脑子里得维护一张“规则执行顺序图”稍不注意就会把规则加错位置导致流量被错误拦截或者错误放行。CentOS 7之后默认的firewalld采用了“zone”模型官方预置了trusted、home、internal、work、public、dmz、block、drop等几个区域。每个zone定义了不同的信任级别比如public默认拒绝绝大多数入站流量只放行跟出站连接关联的回包trusted默认放行所有流量。这种模型的好处是你不需要操心复杂的规则链只需要想清楚“这个网卡信任程度是哪个级别”然后往对应的zone里加规则就行。那能不能在CentOS 7上继续用iptables可以。你有两种选择一种是把firewalld停掉然后安装iptables-services另外一种是继续保留firewalld直接用iptables命令临时写规则但这样规则不会持久化重启就丢。我的建议是除非你有历史脚本和规范必须沿用iptables否则新环境直接习惯firewalld因为它对规则的处理确实更友善。而且大多数云厂商的安全组规则也是类似“放行清单”的思路上手没有违和感。1.2 防火墙的核心概念zone与默认行为zone是理解firewalld的门槛。系统里默认区域是public你可以通过firewall-cmd --get-default-zone查看当前默认zone。如果你的服务器只有一块网卡而且没有特别指定过zone那么这块网卡就属于默认zone。换句话说你平时执行firewall-cmd --add-port8080/tcp实际是在给public这个区域增加放行规则。每个zone自己维护一张规则清单包括放行的服务、端口、协议、源地址等。不同zone之间的规则互相独立比如你在public放行了8080但网卡如果绑定的是internal区域那你访问8080还是不通。这点特别容易被忽视很多人配置了半天规则最后发现网卡挂在别的zone上那前面做的全是无用功。另外还要澄清一点firewalld的默认策略是“放行出站、拦截入站”也就是说服务器主动往外发连接不受影响但外部主动访问服务器的连接默认会被拒。这也是为什么你开了服务本地测试没问题外部就是连不上——最大嫌疑就是防火墙没放行对应端口。理解了zone和默认策略之后我们再来看具体怎么操作思路就会清晰很多。2. 防火墙基础操作开启、关闭、重启与开机自启防火墙的基础操作看着简单但很多人对“临时操作”和“永久操作”分不清导致改完配置重启服务器之后又回到原样或者因为直接关了防火墙导致服务全裸奔。这一节把服务管理的各种细节展开讲照着做基本不会出岔子。2.1 管理防火墙服务状态的核心命令在CentOS 7及以上的系统里firewalld是一个系统服务通过systemd来管理。查看当前状态用systemctl status firewalld如果只想知道防火墙功能本身是否在运行可以执行firewall-cmd --state它会直接输出running或者not running比翻一堆journal日志更直观。启动防火墙用systemctl start firewalld停止用systemctl stop firewalld重启用systemctl restart firewalld。这些命令大家应该不陌生但有一个细节很多人会踩坑如果你修改了firewalld的配置或者手动编辑了zone的XML文件想让它生效不一定需要restart执行firewall-cmd --reload就够了。这个reload会重新加载永久的配置而且关键是不会中断已经建立的连接在线上环境非常实用。还有一个细节是systemctl stop firewalld和firewall-cmd --state之间的矛盾。某些情况下你明明执行了systemctl stop firewalld但再执行firewall-cmd --state时发现它提示running这是怎么回事多半是因为firewalld服务启动了自恢复机制或者你使用了一些直接操作iptables的工具导致状态判断异常。遇到这种情况别慌看systemctl status firewalld为准必要时systemctl mask firewalld彻底禁用防止其他进程把它拉起来。2.2 开机自启与临时关闭为什么建议用永久配置而不是一直disable把防火墙关了确实能一了百了端口直接全通但代价是服务器彻底暴露在网络上。如果机器是内网环境或者仅仅是本地开发机也许还能接受如果是公网服务器关了防火墙等于把大门敞开任何端口扫到就进这是拿安全性换省事风险极高。如果你只是需要临时调试某个服务可以用systemctl stop firewalld关闭调试完再systemctl start firewalld恢复。切忌用systemctl disable firewalld来“永久关闭开机自启”除非你有充足的网络层面隔离方案。disable的意思不只是本次关闭而是以后每次开机都不加载防火墙规则这个状态一旦忘了恢复服务器基本等于裸奔。正确的做法是保持防火墙服务常开用zone和端口规则来做精细化放行。这样即使以后有未知的新服务启动也不会因为你忘了关某个口子而直接被外部扫描到。在实际生产中我更倾向于在云平台上用安全组做第一层过滤再用系统防火墙做第二层防护双重保险比单靠哪个都稳妥。安全组负责大范围的进出口控制系统防火墙负责本机精细化规则比如只允许某个IP访问某个端口这种粒度安全组也能做但系统防火墙做起来同样顺手。3. 开放端口实战从命令到配置文件的完整路径这部分是大多数人最关心的。开放端口用命令无非就是firewall-cmd --add-port端口/协议但这里面的门道有不少。直接说结论不加--permanent的规则是临时规则重启或者reload之后就会消失加了--permanent才是永久规则但需要reload之后才会生效。这个机制让不少人懵过明明加了--permanent为什么执行了--add-port之后马上又用--query-port查询显示没有放行因为永久规则在reload之前不会加载到runtime环境里。3.1 最常用的firewall-cmd端口操作放行一个TCP端口的标准写法是firewall-cmd --permanent --add-port8080/tcp firewall-cmd --reload第一条命令把8080端口的TCP协议加入永久规则第二条命令让规则生效。如果你想放行UDP协议把tcp换成udp即可比如DNS解析常用的53端口就是UDP。查看当前已经放行的端口列表firewall-cmd --list-ports这个命令输出的是runtime环境里已经生效的端口规则。如果你刚加了--permanent但还没reload此时是看不到新规则的这属于正常现象别急着怀疑命令没执行成功。查询某个具体端口是否放行firewall-cmd --query-port8080/tcp输出yes表示放行no表示没有放行。这个命令同样查询的是runtime状态不是永久配置。很多人在这个细节上栽跟头永久配置明明写了但查询为no原因就是没reload。删除端口规则firewall-cmd --permanent --remove-port8080/tcp firewall-cmd --reload删除之后记得也要reload否则runtime里仍然保留着放行规则。这里我建议删规则的时候慎重尤其是公网服务器删了之后外部访问就会断最好在业务低峰期操作。3.2 通过配置文件开放端口手写XML与直觉式编辑firewall-cmd命令最终会把永久规则写入/etc/firewalld/zones/目录下的XML文件。以默认的public区域为例对应的文件是/etc/firewalld/zones/public.xml。如果你不想用命令也可以直接编辑这个XML文件加端口。一个典型的public.xml内容如下?xml version1.0 encodingutf-8? zone shortPublic/short descriptionFor use in public areas./description service namessh/ service namedhcpv6-client/ port port8080 protocoltcp/ /zone在zone标签里增加port port8080 protocoltcp/保存后执行firewall-cmd --reload就可以生效。不过说实话我不太推荐手动编辑XML文件。原因有几个第一XML语法有严格规范标签写错了半个字符firewalld直接起不来到时候只能进控制台恢复非常狼狈第二命令行的--add-port本身就是在帮你维护这个XML没必要自己去碰。但理解这个文件的机制是有用的比如你需要批量迁移防火墙规则、或者写脚本批量添加端口时直接操作XML反而更高效。如果你真的想手改XML我建议先备份原文件修改后用firewall-cmd --reload验证如果firewalld没有报错说明语法没问题再检查firewall-cmd --list-ports能否看到新规则。一旦firewalld启动失败立刻用备份文件恢复。3.3 端口区间、服务名与富规则进阶开放方式除了单个端口firewalld还支持端口区间、服务名和富规则。端口区间写法firewall-cmd --permanent --add-port10010-10020/tcp firewall-cmd --reload这段命令开放了从10010到10020之间的所有TCP端口适合一些使用动态端口范围的程序比如FTP被动模式、RTP媒体流服务等。服务名方式比端口号更语义化。比如你想开放HTTP服务不用记80端口直接firewall-cmd --permanent --add-servicehttp firewall-cmd --reloadfirewalld内置了很多常用服务定义用firewall-cmd --get-services可以查看完整列表。用服务名的好处是以后如果标准端口变了虽然不太可能你只需要更新系统服务定义不用改业务规则。富规则rich rule是firewalld里最灵活的手段适合做“只允许特定IP访问特定端口”之类的精细控制。比如只放行192.168.1.100这台机器访问本机的3306端口firewall-cmd --permanent --add-rich-rulerule familyipv4 source address192.168.1.100/32 port protocoltcp port3306 accept firewall-cmd --reload富规则的语法比较啰嗦但是表达能力强。类似的场景还有把某个IP段拉黑firewall-cmd --permanent --add-rich-rulerule familyipv4 source address10.0.0.0/8 drop firewall-cmd --reload使用富规则的人相对少因为很多公司直接用云安全组替代了这个功能。但在纯物理机或者内网环境富规则是唯一不需要额外工具就能实现“IP白名单”的方式。4. 配置留存与迁移让规则在重启后依然生效防火墙规则最怕的就是“配置一时爽重启火葬场”。很多人用--add-port放行端口后服务立刻通了一切正常结果某天重启服务器端口又连不上了。原因就是漏掉了--permanent参数。这一节我们把持久化和迁移的细节讲透。4.1 --permanent的作用与reload机制firewalld内部管理着两套规则一套是runtime规则也就是当前内存中生效的规则另一套是permanent规则也就是持久化在磁盘XML文件里的规则。firewall-cmd --add-port默认只改runtime不加--permanent就意味着规则不会写入XML文件重启服务或者重启系统之后就会丢失。而加了--permanent只是写入磁盘不会立刻在runtime里生效需要reload或者重启firewalld服务。理解这个机制之后你应该能推断出几种操作的结果。如果只执行了--add-port8080/tcp当前能访问重启后失效如果只执行了--permanent --add-port8080/tcp磁盘上有了记录但当前没生效需要reload如果两个都执行了这是最标准的“当前生效重启保留”方案。有些习惯用iptables的老手一开始很不适应这个两段式逻辑但用熟之后会发现它其实更安全——你可以在命令行里试错确认没问题了再永久化不至于一次误操作就把环境搞乱。firewall-cmd --reload和firewall-cmd --complete-reload是有区别的。前者保留运行时状态只是应用一下永久配置不会断掉现有连接日常用这个就够后者是完全重新加载等于把所有规则丢弃再重新加载一遍会导致现有连接全部中断。线上环境千万别用--complete-reload除非你有足够的心理准备面对一波工单。4.2 备份与迁移防火墙规则服务器防火墙规则的管理应当纳入变更流程就像代码一样需要可回滚。firewalld的规则都集中在/etc/firewalld/目录最简单粗暴的备份方式就是备份整个目录cp -r /etc/firewalld /root/firewalld-backup-$(date %F)恢复时把备份目录里的文件覆盖回去再reload即可。这个操作我建议在改动较大规则集之前做一次尤其是生产环境有了备份就算把规则改崩了几分钟之内就能恢复。如果要在多台机器之间迁移规则可以先在源机器上导出再到目标机器导入。可以用firewall-cmd --list-all-zones把所有zone的当前规则全部列出来但这只是人眼查看不适合直接导入。更靠谱的方式是直接拷贝XML文件。例如把public区域的规则从机器A同步到机器Bscp /etc/firewalld/zones/public.xml root目标机器IP:/etc/firewalld/zones/拷贝完成后在目标机器上执行firewall-cmd --reload规则就过去了。注意如果目标机器上原来有自定义zone也要一并拷贝否则引用缺失zone的网卡可能报错。另外如果两台机器的网卡接口名不同还得检查网卡和zone的绑定关系是否正确绑定关系配置在/etc/firewalld/zones/里的XML中或者在/etc/sysconfig/network-scripts/ifcfg-网卡名里通过ZONE字段指定。5. 常见问题与排查技巧实录防火墙这东西出问题时的表象千奇百怪但症结往往就那么几个。我把这些年遇到的高频问题整理了一下方便你遇到状况时快速定位。5.1 端口不通的排查链路开放了端口还是连不上别急着重启防火墙按照下面的顺序逐步排查基本都能找到原因。第一步确认服务本身在监听。执行ss -tlnp | grep 端口号看对应端口是否有LISTEN状态。如果压根没有监听那问题不在防火墙先把服务启动起来再说。另外注意有些服务默认监听在127.0.0.1上比如某些框架的开发模式外部网络访问这个IP是永远连不上的需要把监听地址改成0.0.0.0才能对外提供服务。这一步很多人会忽略明明防火墙全放开了还是不通最后发现是应用监听地址的问题。第二步确认防火墙放行状态。用firewall-cmd --query-port端口/tcp检查runtime规则。如果输出no用--add-port或者--permanent --add-port放行。这里提醒一点如果服务是用UDP协议通信的排查时要带上/udp很多人只放行了TCP导致UDP端口一直不通。第三步检查SELinux。CentOS默认开启SELinux它和防火墙不是一回事但同样会拦截网络访问。查看状态用getenforce如果是Enforcing状态可以临时用setenforce 0关闭再测试如果确认是SELinux拦截可以通过设置对应的布尔值来解决而不是直接关掉SELinux。比如允许httpd访问网络setsebool -P httpd_can_network_connect 1第四步检查云平台安全组。如果你用的是云服务器除了系统防火墙控制台里的安全组也会做过滤。很多情况下系统防火墙已经放行了但安全组入方向没放行对应端口一样连不上。这个排查点特别容易被忽略甚至有些老运维也会在这里卡住。云服务器的访问链路是“外部网络 - 安全组 - 系统防火墙 - 应用”安全组挂在最外层系统防火墙规则做得再完美安全组不放行也是白搭。第五步测试网络连通性。本地试一下ping 服务器IP不通的话可能是网络路由或者ICMP被拦截用telnet 服务器IP 端口测试指定端口是否通通的话会显示连接建立提示不通会卡住然后报错。有条件的话用手机流量试能排除本地网络环境的问题。整个排查链路我整理成了一张表方便你收藏排查步骤命令/操作可能原因服务监听检查ss -tlnp服务未启动、监听地址错误防火墙规则检查firewall-cmd --query-port未放行端口、未reloadSELinux检查getenforceSELinux拦截安全组检查云控制台入方向未放行网络连通性ping、telnet路由不通、ICMP被禁5.2 规则不生效的典型原因明明添加了永久规则也执行了reload为什么端口还是不通这类问题桌面运维也遇到过。常见原因有三类。第一类是网卡没有绑定到你配置规则的zone。用firewall-cmd --get-zone-of-interface你的网卡名查看网卡归属。比如你的网卡是eth0但eth0被分配到了internal zone而你是在public里加的规则那这个规则跟eth0一点关系都没有。可以通过firewall-cmd --zonepublic --change-interfaceeth0把网卡绑定到public或者直接往网卡所在zone加规则。第二类是规则顺序问题虽然firewalld的zone模型不像iptables那样严格要求顺序但富规则的优先级是高于普通端口规则的。如果你写了一条drop的富规则哪怕后来又用--add-port放行了端口drop规则依然会先拦截掉。所以在有富规则的场景下要检查断言关系别让两条规则“打架”。第三类是服务本身没有监听在所有网卡上。排查方法前面提过看ss -tlnp的监听地址。如果只监听127.0.0.1那无论防火墙怎么放行都没用因为数据包在到达应用之前系统根本不会把外部流量转发到loopback地址上。这种情况要去改应用的监听配置而不是折腾防火墙。5.3 防火墙要不要关安全与便利的平衡“防火墙关闭有影响吗”这个问题说实话得看场景。如果是开发环境、内网测试环境可以考虑在可控网络内关闭防火墙提升调试效率。但如果机器有公网IP哪怕只是挂一个简单的服务页面也不建议关防火墙。现在网络上的扫描工具横行全开放的服务器被入侵的案例太多了我见过不少因为图省事关防火墙结果数据库被人扫到弱密码直接拖库的悲剧。如果觉得防火墙规则太麻烦一个折中方案是保留防火墙开启状态设置默认拒绝所有未知入站流量只放行必要的服务和端口。常见的Web服务器放行80和443SSH登录放行22或者自定义端口数据库只对特定的内网IP段放行。这样即使某个服务有漏洞攻击者也无法从外部立刻访问到这个端口多了一层有效的缓冲。还有一个小技巧如果你经常在本地用SSH连接服务器而服务器IP又不是固定的可以考虑给SSH端口做成IP白名单。当然这会增加管理负担IP变了就得去控制台或者用其他方式重新配置规则所以大多数场景下不建议把所有端口都做IP限流保留服务端口开放用强密码加key登录更实际。6. 一些经验之谈关于防火墙的运维习惯最后说点个人体会我觉得比命令本身更值钱。一是养成“改前备份、改后验证”的肌肉记忆。不管是加规则还是删规则先备份/etc/firewalld目录操作后立刻用firewall-cmd --list-ports、firewall-cmd --list-all验证最好再用外部网络环境实际连接一次确认没有误伤。二是不要盲目复制网上的命令。网上的教程质量参差不齐有些命令直接照抄会出大问题。比如网上常看到一句话“永久关闭防火墙”直接systemctl disable firewalld这个在生产环境用非常危险。你要先判断自己的业务形态、网络环境再决定要不要执行。命令本身没有对错执行的人得清楚后果。三是定期审查防火墙规则。很多服务器上的防火墙规则是历史遗留物早期开放了某个端口做测试后来业务下架了规则却一直留着变成隐形风险。我建议每季度或者半年做一次规则审计把不用的端口规则删掉保持最小化原则。虽然麻烦但对安全的意义很大。四是把防火墙操作记入变更记录。这个习惯适合团队协作的场景。在配置变更时记一笔谁改的、改了哪个端口、为什么改、什么时候改的、对应的服务是什么。有时候一个问题排查不出来翻一下变更记录立刻能定位是哪次改动引入的问题比抓瞎强太多。如果你在配置防火墙时踩过什么奇怪的坑欢迎在评论区留个言大家一起避雷。
