CentOS 7生产环境iptables企业级实战：从选型到故障排查-北京尧图网络

前阵子同行群里有人问新上一批CentOS 7服务器到底是用firewalld还是换回iptables提问的人说得很实在——公司好几套运维脚本、基线检查文档全是基于iptables写的换firewalld等于把现有体系推翻重来。这个场景我太熟悉了。这些年经手的企业服务器里CentOS 7上跑iptables的比例一直不低docker、nginx、mysql这些服务堆在一起防火墙配置没处理好一次上线能把人折腾到凌晨。所以我想把CentOS 7上iptables的企业级应用案例整理成一篇文章从选型、规则设计到故障排查完整讲透适合正在接手或维护CentOS 7生产环境的运维同学参考。1. 企业为什么还离不开iptables1.1 firewalld和iptables实际是同一套内核CentOS 7默认装的是firewalld但很多刚入行的人没有搞清楚它和iptables的关系。firewalld只是一个前端管理工具真正干活的是内核里的Netfilter框架iptables命令和firewalld都在这个框架上操作数据包过滤逻辑。firewalld引入了zone概念按信任级别把网卡、来源地址分组管理而iptables就是最经典的五链四表模型规则一条条从上到下匹配逻辑非常直白。对企业里写惯了脚本的老运维来说iptables的规则文件直观、稳定、好排错一条iptables -L -n -v就能看全量规则这是它能继续打天下的核心原因。另外还需要注意CentOS 7上默认没有iptables服务想用iptables做开机自启和统一管理必须安装iptables-services这个包。它和firewalld是二选一的关系不能同时跑两套防火墙管理工具否则规则互相覆盖排障的时候会非常痛苦。1.2 企业为什么宁可“返祖”也要用iptables经常有人觉得从firewalld切回iptables是技术倒退但从企业实际运维角度看这个选择背后有一堆现实考量存量脚本和文档。很多公司从CentOS 6时代积累下来的初始化脚本、安全基线检查项都是iptables命令切成firewalld等于全员重新培训还要重写几百台机器的自动化脚本。Docker叠加场景多。Docker会在iptables的nat表和filter表自动写入规则比如端口映射、容器间通讯用iptables查看时能直观看到Docker写入的链和规则排障很方便。firewalld的zone抽象反而会把Docker的规则藏起来看的时候总觉得隔了一层。安全审计和等保要求容易对上。外部测评时iptables规则文件可以一行行解释清楚这个端口为什么开、来源是谁、匹配顺序是什么很好打点。巡检效率高。一条命令下来开哪些端口、放行了哪些来源IP一目了然比在firewalld的多个zone之间反复切换直接得多。兼容性因素。部分老业务中间件的部署文档明确要求iptables甚至安装包会直接去改/etc/sysconfig/iptables文件这种情况下不用iptables反而要额外适配。2. 环境准备从firewalld切换到iptables的完整流程2.1 装系统先看底子版本、防火墙、yum源装CentOS 7.9或其他7.x版本时生产环境我一般选Minimal安装最小化安装能减少不必要的服务暴露面。装完系统后先做三件事确认系统版本、确认内核版本、确认当前防火墙状态。cat /etc/redhat-release uname -r systemctl status firewalld systemctl status iptables如果是批量装机建议先把可用的yum源配好比如阿里云镜像或清华镜像因为iptables-services、conntrack-tools这些包都要从源里装。离线环境就需要提前下载好rpm包拷进内网安装时要注意依赖关系iptables-services这个包会依赖iptables主包最好把整组rpm都下载齐全再离线装。这里有个容易忽略的点有的机器是二手的可能已经被前人手动加过iptables规则也可能firewalld并没有真正停掉。如果不看现状直接清空规则容易把别人正在用的放行策略干掉这在接手旧服务器时特别常见。2.2 停用firewalld启用iptables-services确认现状之后执行切换操作systemctl stop firewalld systemctl disable firewalld yum install -y iptables-services systemctl enable iptables systemctl restart iptables systemctl status iptables这个顺序不要乱。先停firewalld再装iptables-services因为两个负责防火墙的服务不能同时活跃会出现规则互相覆盖、链被清空的混乱局面。iptables-services装好之后会自动生成/etc/sysconfig/iptables和/etc/sysconfig/ip6tables两个规则文件systemd服务通过它们来管理iptables的持久化。首次启动后规则是空的三条链INPUT、FORWARD、OUTPUT都是默认ACCEPT策略。这时候不要急着加规则先把放行设计想清楚再动手写否则很容易出现“加着加着把自己SSH断了”的情况。2.3 规则文件规范备份、注释、分组/etc/sysconfig/iptables是企业里最重要的一个文件。它的格式和iptables-save输出一致顶部是*filter表示filter表后面跟着:INPUT DROP [0:0]这种链默认策略声明。在正式动手之前先做一个带日期的备份这是运维的基本素养cp /etc/sysconfig/iptables /etc/sysconfig/iptables.bak.$(date %F)规则文件里可以用#写注释我习惯在每个业务端口前加一行说明比如# 对外Web端口 80/443。多人维护的服务器上注释和备份就是命根子不然出了事都不知道规则是谁在什么时候改的。另外建议保持系统默认链名不去自定义新链除非你对iptables的自定义链机制已经非常熟练。自定义链在规则多了之后确实清爽但一旦不熟误操作的概率会直线上升。3. 企业级案例实操三层业务服务器的防火墙规则集3.1 先讲清场景和需求假设公司有一台CentOS 7服务器同时承担三个角色Nginx对外提供网站服务开放80和443端口任何来源都可以访问内部API服务监听8080端口只允许内网应用网段10.10.0.0/16访问SSH远程管理端口从默认22改成了2222只允许办公网192.168.10.0/24连接。服务器有两块网卡eth0接公网出口eth1接内网。这种“一套服务器、多个角色”的业务模型在企业里相当普遍防火墙规则必须按照角色做最小化放行而不是图省事全端口放开。3.2 基础规则回环、状态连接、默认策略先清空现有规则避免旧配置干扰iptables -F iptables -X回环接口必须放行很多本地进程通过127.0.0.1互相通信比如Nginx反代到本机的PHP-FPMiptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT然后是状态连接规则。这一步非常关键放行ESTABLISHED和RELATED状态后服务器主动对外发起的连接它的响应包才能正常回来iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT最后设置默认策略。这里注意操作顺序建议先添加放行规则最后再设置DROP策略。如果一开始就把默认策略设成DROP中间几秒钟所有新连接都会被丢弃SSH可能当场断开iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT3.3 业务端口放行来源、网段、端口三维度控制SSH端口改成2222后需要同时满足两个条件才能放行来源在办公网段内、目标端口是2222iptables -A INPUT -p tcp -s 192.168.10.0/24 --dport 2222 -j ACCEPT iptables -A INPUT -p tcp --dport 2222 -j DROP这里第一条ACCEPT指定了来源网段第二条是多余的因为最终默认策略就是DROP但写上也无妨可以防止以后有人把默认策略改成ACCEPT时SSH变成裸奔。Web端口完全对外开放iptables -A INPUT -p tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j ACCEPT内网API端口只允许内网应用网段访问iptables -A INPUT -p tcp -s 10.10.0.0/16 --dport 8080 -j ACCEPT iptables -A INPUT -p tcp --dport 8080 -j DROP所有规则添加完后保存到文件否则重启后全部丢失iptables-save /etc/sysconfig/iptables改SSH端口后还有一个高频坑SELinux没有放行新端口。即使iptables放行了2222SSH服务依然可能起不来或连不上因为SELinux会拦截。需要执行semanage port -a -t ssh_port_t -p tcp 2222很多运维改完22端口后排查了半天防火墙最后才发现是SELinux的端口上下文没加这个顺序一定要记住。3.4 conntrack实战限制DNS 53端口突发请求热词里有一条“iptables conntrack封禁53端口”我在企业里确实遇到过类似场景。某台DNS服务器突然被内网一个异常客户端疯狂查询请求数每秒上千条直接把出口带宽打满正常用户的DNS解析也受到了影响。这时候就要用conntrack模块限制单个IP的新建查询速率。UDP 53不能用connlimit有效限制connlimit主要用于TCP连接数。UDP场景推荐用recent模块配合conntrack的NEW状态iptables -A INPUT -p udp --dport 53 -m conntrack --ctstate NEW -m recent --set --name dnsquery iptables -A INPUT -p udp --dport 53 -m conntrack --ctstate NEW -m recent --update --seconds 60 --hitcount 30 --name dnsquery -j DROP第一条规则把每个新到的UDP 53请求记入一个名为dnsquery的列表第二条规则检查如果1分钟内同一个来源的新建请求数超过30次就丢弃后续包。这样正常用户的DNS查询完全不受影响异常客户端的洪峰流量会被限住。对于TCP 53也就是DNS over TCP的场景可以用connlimit限制并发连接数iptables -A INPUT -p tcp --dport 53 -m connlimit --connlimit-above 50 -j REJECT为什么这里要匹配conntrack的NEW状态而不是直接匹配--dport 53因为如果直接匹配端口已经建立的请求也会被计算在内很可能把持续查询的正常用户误伤。只有NEW状态的包才代表一次新的查询请求统计口径更准。UDP本身没有真正的连接概念但conntrack会为UDP交互维护临时的连接记录所以用NEW状态限速也是可行的。4. 企业级运维日常改规则、持久化、防锁死4.1 改规则的标准操作流程企业环境里改防火墙不能随手敲一条iptables命令就算完事。我自己的标准流程是这样先备份当前运行规则iptables-save /etc/sysconfig/iptables.bak.时间戳在内存里加临时规则测试连通性。比如要放行新网段访问8080端口用-I插入到指定行号避免加在DROP规则后面不生效iptables -I INPUT 5 -s 192.168.20.0/24 -p tcp --dport 8080 -j ACCEPT测试确认没问题后保存到文件iptables-save /etc/sysconfig/iptables修改配置文件后用systemctl reload iptables或iptables-restore /etc/sysconfig/iptables重新加载这里有个经典型的坑只保存到内存没写文件重启后规则全丢或者只改了配置文件没有reload旧规则还在内核里运行。运维必须时刻分清楚“运行中的规则”和“文件里的规则”是两个东西一条生效一条未必生效很多人就是死在这个认知上。4.2 iptables配置后需要重启程序吗这个问题的答案很明确不需要。iptables工作在内核的Netfilter框架在IP层做数据包过滤应用进程根本感知不到防火墙的变化。你改了规则对已经建立的TCP连接没有任何影响新连接才会按新规则匹配。所以Nginx、MySQL、Redis这些服务都不用动。唯一需要注意的是NAT规则。如果修改的是DNAT或SNATconntrack表里可能还保留着旧连接的记录已建立的连接会继续走老路径导致新规则看起来没生效。这种情况可以用conntrack工具删除对应连接记录或者等表项自然超时。改完NAT后有时需要重启Docker容器或让业务重连原因就在这里。4.3 用配置文件管理已开放的TCP端口热词里“centos防火墙开放tcp端口配置文件”指的就是/etc/sysconfig/iptables。开放一个端口的格式很简单-A INPUT -p tcp --dport 3306 -j ACCEPT比如要开放MySQL的3306端口编辑配置文件在INPUT链里按顺序加入这一行然后reloadvim /etc/sysconfig/iptables systemctl reload iptables查看当前完整规则iptables -L -n --line-numbers需要特别注意的是配置文件里的规则顺序和iptables -L显示的顺序是一致的ACCEPT规则必须放在DROP规则或默认策略之前否则永远不会被匹配到。另外企业口径上不建议手动改文件后直接systemctl restart iptables因为restart会先停后启中间存在短暂的空窗期reload更平滑不影响已建立的连接。4.4 常见端口与表链对照场景表:链规则示例SSH远程管理filter:INPUT-A INPUT -p tcp -s 办公网段 --dport 2222 -j ACCEPTWeb服务filter:INPUT-A INPUT -p tcp --dport 80 -j ACCEPTMySQL内网访问filter:INPUT-A INPUT -p tcp -s 10.0.0.0/8 --dport 3306 -j ACCEPT内网机器上网NATnat:POSTROUTING-A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE公网端口转发到内网nat:PREROUTING-A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.0.0.10:80这张表覆盖了企业里最频繁用到的几个iptables场景。NAT部分属于nat表和filter表不是一回事排查的时候要记得带上-t nat参数。5. 踩坑实录网络不通的排查与救援5.1 ping不通网关先从网络本身查起“centos ping不通网关”是运维群里出现频率极高的问题。很多人第一反应是清空iptables但实际上八成的情况跟防火墙没有关系。我排查这个问题有一套固定顺序ip addr ip route arp -n ping 网关IP先看网卡IP和掩码是否配对了再看默认路由是否指向正确网关再看ARP能不能解析到网关MAC最后才考虑防火墙层面。有些安全基线确实会配置丢弃ICMP的规则比如iptables -A INPUT -p icmp --icmp-type echo-request -j DROP这种情况下ping不通是正常的但业务流量不一定受影响。另外在虚拟机或云环境里安全组和虚拟交换机也可能拦截ICMP和系统防火墙毫无关系。所以排查顺序一定要自下而上不要上来就清防火墙规则否则会越查越乱。5.2 规则顺序ACCEPT必须抢在DROP前面iptables规则是顺序匹配先命中先生效。很多人写规则时习惯把DROP集中写在开头再把特定来源的ACCEPT写在后面结果特定IP也被拦截了。因为数据包从链头部开始匹配遇到DROP规则后就结束处理后面的ACCEPT规则根本没有机会执行。查看规则行号iptables -L INPUT -n --line-numbers调整顺序时先删掉错误的规则再按正确顺序插入iptables -D INPUT 5 iptables -I INPUT 5 -s 192.168.1.100 -p tcp --dport 8080 -j ACCEPT企业里我习惯把所有ACCEPT规则集中在链的前半部分所有DROP和REJECT规则集中在链尾中间放日志和限速规则。这样排错时只需要从上往下扫一遍就能快速定位逻辑清晰。5.3 误封SSH后的三种抢救姿势这个坑我踩过不止一次。安全基线要求在服务器上做SSH来源限制结果把办公网IP写错了或者加规则时把默认策略直接设成DROPSSH当场断开。抢救办法按优先级排列第一看机器有没有带外管理。物理服务器通常有BMC或IPMI云服务器有控制台VNC登录后执行iptables -F清空所有规则再执行iptables -P INPUT ACCEPT恢复默认策略。这是最直接的救援方式。第二没有带外管理但之前设置了计划任务兜底。等计划任务执行后规则自动释放。第三人在机房现场直接接显示器键盘登录同样执行iptables -F。吃过几次亏之后我现在养成了一个保命习惯重大规则变更前用at命令加一个限时清空任务echo iptables -F; iptables -P INPUT ACCEPT | at now 5 minutes这样即使自己把自己锁在门外5分钟后规则也会自动恢复给自己留一条退路。小技巧关键时刻真的能救命。5.4 高频排查命令速查表想做的事命令查看所有规则带行号iptables -L -n --line-numbers查看详细统计iptables -L -n -v查看nat表iptables -t nat -L -n保存当前规则iptables-save /etc/sysconfig/iptables从文件加载规则iptables-restore /etc/sysconfig/iptables清空filter表规则iptables -F删除指定行规则iptables -D INPUT 行号查看conntrack连接记录conntrack -L清空conntrack表conntrack -F最后说点个人体会。我在生产环境里维护iptables这么多年最深的感触是iptables本身并不难难的是在一堆业务规则、Docker规则、安全组规则混在一起时还能清楚知道“当前这台机器到底放行了什么”。所以我每次处理完一批CentOS 7服务器都会顺手做两件事一是把/etc/sysconfig/iptables的备份文件按日期归档二是在规则文件最前面留一行注释写清楚这台机器是什么角色、放行了哪些来源、变更人和日期。等过几个月再回头看这些注释能帮你省下大量回忆成本。如果你也在维护类似的机器建议从今天开始给防火墙规则加个注释和备份的习惯这个动作做不了吃亏做不了上当。

CentOS 7生产环境iptables企业级实战：从选型到故障排查

相关推荐

Vetur 装了 .vue 仍不补全？让走 TaoToken 的 Codex 改 emmet.syntaxProfiles

千兆网口EMC标准电路设计与PCB布局实战指南

直流电机控制电路设计全攻略：从PWM调速到H桥驱动

更多资讯

Anthropic 的 18 个岗位插件跑起来，Claude Code 的 Token 走 TaoToken

窗函数法FIR带阻滤波器：从原理到工程落地

知识图谱与 Agent Harness 跑可解释推理任务：LLM Key 用 TaoToken

OpenClaw Windows 本地部署，设置里的模型 Base URL 填 TaoToken

从零开始写第一篇技术博客：动机、选题与持续输出指南

terraform-provider-aws 的 aws_redshift_cluster 数据源：完整参考与源码级解读

今日更新

校园网认证计费模式详解：AAA与代拨架构、原理及排障

Spring Boot+Vue垃圾分类毕设：分层、权限与排错实战

把 Cline 的 Base URL 改到 TaoToken 之后，DeepSeek 仍能修调试配置

本周精选

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？