Iptables是Linux内核内置的报文过滤防火墙,它通过操作规则表来允许或拒绝数据包进出,掌握它,你就能精准掌控服务器的每一条流量去向。这篇文章从零梳理iptables的核心概念到落地配置,不绕弯子,直接讲透。
iptables 和 firewalld 到底怎么选,才能让服务器既安全又不卡
很多刚接触Linux服务器的朋友会问,iptables 和 firewalld 有什么区别,简单说,firewalld是动态防火墙,适合频繁变更规则的桌面或云主机场景,它按区域管理流量,配置起来更像“填空”,而iptables是静态规则集,每一条规则都按顺序匹配,匹配到就停止,效率极高,资源占用极低,多数生产环境下的Linux老手,尤其跑着Nginx、MySQL的服务器,仍然偏向iptables。
坦白说,两者并不冲突,但一台机器上同时启用两个防火墙服务会导致规则互相覆盖,排查问题时容易让人抓狂,如果你的Linux版本是CentOS 7或以上,系统自带firewalld,也可以手动切换回iptables:
systemctl stop firewalld
systemctl disable firewalld
yum install -y iptables-services
systemctl start iptables
systemctl enable iptables
为何国内服务器运维仍偏爱 iptables 做流量入口管控
去各大IDC机房转一圈,或翻看技术社群的讨论,你会发现大量云服务器在Nginx前置层、数据库访问层仍用iptables做白名单,原因很直接:iptables规则生效是内核态直接处理,不经过用户态转发,延迟极低,脚本化部署方便,写一段shell即可在批量服务器上同步规则,而firewalld的XML配置在批量场景下反而不太直观。
iptables 规则怎么添加:从四表五链到你的第一条规则
要上手,得先理解它的骨架,iptables包含四张表和五条链,表是功能的分类,链是报文流经的关卡,四张表分别是:
- filter表:核心的过滤功能,允许或拒绝数据包,最常用。
- nat表:网络地址转换,端口映射、共享上网靠它。
- mangle表:修改数据包的服务类型、TTL等特殊字段。
- raw表:用于配置NOTRACK,跳过连接跟踪。
五条链则对应数据包在内核中的五个挂载点:
- PREROUTING:报文进入路由决策之前。
- INPUT:报文发给本机进程。
- FORWARD:报文需本机转发。
- OUTPUT:本机进程发出报文。
- POSTROUTING:报文即将离开网卡前。
第一道指令:查看当前规则与清空规则
执行iptables -L -n --line-numbers,即可看到服务器当前的规则列表,注意-n表示不做反向域名解析,速度更快也更清晰,若机器刚买回来,规则大概率是空的,此时不要急着加规则,先执行
iptables -F清空默认规则,避免旧配置干扰后续调试。
第二道指令:放行SSH,避免自己把自己锁在门外
给服务器配防火墙最怕的是规则顺序写错,把自己拒之门外,很多人在配置iptables的实战演练中都会踩这个坑,务必在添加任何拒绝规则之前,先将SSH端口放行,假设你修改过SSH端口,假设是22026,那应该执行:
iptables -A INPUT -p tcp --dport 22026 -j ACCEPT
这行命令的意思:追加一条规则到INPUT链,匹配TCP协议且目标端口为22026,动作为接受,这里有一个通用建议,端口号在规则里一定要用22端口还是22026,取决于你实际改过的配置,别照抄网络教程不带脑子。
第三道指令:配置默认策略
默认策略是整个规则的兜底,如果规则全部没匹配上,走默认策略,安全角度建议将INPUT链默认策略设为DROP,但在设置前确保已经有了放行规则:
iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT
设定之后你会发现,这台服务器只有你显式放行的流量能进来,这就是iptables使用教程中最核心的“白名单思维”。
Linux iptables 配置实战:端口转发与NAT场景
NAT表与mangle表在真实业务中高频应用,尤其在公网IP不足或内网服务隔离的场景,下面是两个业内最常见的配置场景。
端口映射,把内网MySQL服务暴露给指定公网IP
假设内网有一台数据库服务器,IP为192.168.1.100,运行在3306端口,防火墙服务器有两块网卡,公网网卡eth0,内网网卡eth1,操作为:
iptables -t nat -A PREROUTING -d 公网IP -p tcp --dport 3306 -j DNAT --to-destination 192.168.1.100:3306 iptables -t nat -A POSTROUTING -s 192.168.1.100 -p tcp --sport 3306 -j SNAT --to-source 公网IP iptables -A FORWARD -p tcp -d 192.168.1.100 --dport 3306 -j ACCEPT iptables -A FORWARD -p tcp -s 192.168.1.100 --sport 3306 -j ACCEPT
需要注意,做完DNAT之后还要确保FORWARD链没有拦截,多数运维新手在这里漏掉FORWARD规则,导致内网服务通了但数据包没被转发,这也是nginx 做反向代理时 iptables 规则怎么配这类问题里经常被提及的坑,反向代理机器本身也要放行相应端口。
共享上网,让内网机器统一走一台服务器出口
办公室或家里有多台内网设备,不想每台都配公网IP,直接用一台Linux盒子做网关:
echo 1 > /proc/sys/net/ipv4/ip_forward iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE
这样内网所有机器把网关指向这台服务器即可自然上网,MASQUERADE适合动态获取IP的出口线路,若是固定IP,建议用SNAT指定具体源IP,性能更好,整体而言,
iptables端口转发机制适用于链路层以上的流量控制,但内核生产版本更推荐直接使用nftables替代旧命令集,不过这是后话。
iptables 规则保存:重启不丢的三步操作
新手最常见的疑惑:明明配置好了规则,重启服务器或者重启iptables服务后,规则全没了,因为iptables规则的默认状态是内存态,重启即失。
正确的保存姿势:
- CentOS 6或较早版本:执行
/etc/init.d/iptables save - CentOS 7及以上版本:先安装iptables-services,执行
service iptables save,规则会写入/etc/sysconfig/iptables。 - 通用备份方式:执行
iptables-save > /root/iptables.rules,恢复时用iptables-restore < /root/iptables.rules。
生产环境建议把规则文件纳入版本管理,修改前先备份,每次变更后执行iptables-save,做到重启不慌、回滚有据。
iptables 常见疑难排查与错误处理
规则已放行,流量仍无法到达服务
按顺序排查三个层面,先用iptables -L -v -n查看规则命中计数,若计数为0,说明数据包根本没走到这条链,此时需要检查数据包是否被前面的DROP规则拦截,或者流量压根没到达本机。别忘检查系统里是否还有firewalld在运行,两个防火墙服务并存会导致规则互相覆盖又不报错,是排障中最隐蔽的源头。
配置了端口转发,内网访问不正常
多数情况下是回程流量没有做SNAT,DNAT只改了目标地址,如果出口报文源地址仍是内网机器的私有IP,对端响应时无法正确回包,解决办法是追加POSTROUTING链的SNAT规则。
iptables服务启动失败且无报错
检查内核模块是否加载:lsmod | grep ip_tables,若输出为空,执行modprobe ip_tables,云服务器厂商的控制台安全组也要确认已放行对应端口,有时规则没错,但云平台安全组把流量挡在了外面。
iptables 删除规则与规则优化技巧
删除规则有两种方式。方法一:按规则编号删除,先iptables -L -n --line-numbers查看规则序号,再iptables -D INPUT 3,含义为删除INPUT链第3条规则。方法二:按规则内容精确匹配删除,例如iptables -D INPUT -p tcp --dport 22 -j ACCEPT,后者适合脚本中动态删除某条已知规则的场景。
优化方面,行业内共识是把高命中率的规则放在链的前面,每条规则被匹配就会产生CPU开销,链越长,线性匹配耗时越大,一个常见做法是:将同类别规则聚合,多个端口可合并为连续端口范围,减少规则条目数。
iptables -A INPUT -p tcp -m multiport --dports 80,443,8080 -j ACCEPT
若规则条目动辄上百条,且需要频繁变更,建议考虑使用ipset配合iptables,ipset能大幅提升集合匹配性能,尤其适合封禁大量IP的场景,值得注意的是,即使遇到复杂场景也切莫偏离基础逻辑,iptables命令本身依然是所有上层工具的最终执行者。
iptables 和 nftables 演变趋势,2026年还值得学吗
Linux内核早已用nftables逐步替代iptables框架,但iptables命令在不少存量服务器上仍长期存在,从结局看,iptables被nftables完全取代是趋势,但存量规模庞大,2026年主流发行版依然默认兼容iptables命令集,学习iptables的价值并不局限于命令本身,它让你理解报文在内核中经过的路径和挂载点,这个底层概念在理解nftables、ebtables乃至云原生网络插件时依旧适用,可以按时间预算分配,先熟练掌握iptables再过渡到nftables,而非跳过基础。
常见问题解答:iptables 详解周边疑问
修改iptables规则后,连接中的TCP会话会立即断开吗?
不会,iptables是基于连接跟踪状态的机制,修改规则仅影响新建立连接的报文匹配,已经处于ESTABLISHED状态的连接,只要没有显式删除对应的状态放行规则,通常不会被立刻切断,但若执行iptables -F清空所有规则,则状态跟踪表也会丢失上下文,导致会话中断,需要应用层重连。
docker容器端口映射与iptables规则冲突,网站为何无法访问?
Docker在启动时会动态写入iptables的DOCKER链,许多软件在安装防火墙规则时习惯添加-I INPUT将规则插入最前,从而拦截了Docker的FORWARD流量,排查方法是执行iptables -L -n查看FORWARD链和DOCKER链的位置关系,解决办法是通过iptables -A追加规则而非强制插入最前,或为Docker流量单独放行。
规则都是正确的,为何本机访问公网IP的映射端口不通,其他机器却正常?
这通常被称为“NAT回环”问题,本机发出的数据包若经过PREROUTING的DNAT规则,源地址是本机,出口为lo接口,实际并不经过eth0,导致回包时无法正确匹配源地址,业内专家指出,解决思路有两种:一是添加内部访问的独立DNAT规则指向内网IP;二是在POSTROUTING链为本机地址追加一条SNAT规则。
最终的判断标准很简单,将filter链的默认策略设为DROP后,你需要的服务端口全部显式放行,规则顺序清晰可读,这就是一份合格的iptables配置,从内核报文路径到实战命令,养成配置、验证、保存的闭环习惯,防火墙不再是绊脚石。
首发原创文章,作者:王坚,如若转载,请注明出处:https://idctop.com/article/588637.html




