iptables四表五链实战：从原理到规则不生效与故障排查

最近常有人问我：“iptables防火墙怎么关了反而连不上网？”“iptables规则明明是加上了，为什么就是不生效？”说实话，这些问题我都踩过。前几天帮一个客户排查故障，一台业务服务器无预警失去响应，查了半天才发现，是之前维护时有人把一条拒绝规则写在了所有ACCEPT规则前面，导致内网回包整个被丢。iptables就是这样——它不声不响地待在内核里，规则错一条，影响一大片，排错却要翻遍整条链。

如果你在维护任何基于Linux的服务器、容器节点或者虚拟化平台，iptables一定是绕不开的那道坎。它既是Linux内核Netfilter框架的标准防火墙配置工具，也是Docker、Kubernetes这些容器网络方案底层依赖的转发与隔离机制。所谓“防火墙”并不是一台独立设备，而是一组内核钩子函数，iptables只是命令行操作界面，真正干活的，是内核里挂接在协议栈处理路径上的规则表。下面把这块内容从头捋一遍，从四表五链的原理讲起，再到黑白名单、反向放行、屏蔽应用程序联网、eNSP里模拟华为防火墙登录、双机热备等实操场景，最后把重启丢规则、ping不通、规则不生效这类典型故障一锅端。

适合谁看？第一类，刚接触服务器运维、被防火墙问题折磨得头大的新手；第二类，要配置容器网络、NAT转发、端口映射的DevOps工程师；第三类，准备做网络自动化或合规整改，需要把防火墙策略文档化的网络工程师。下面的内容尽量不摆教科书脸，直接讲我实际操作中验证过的东西。

1. 一上来先分清“表”和“链”：iptables的底层原理

1.1 四张表五条链，到底谁先谁后

很多人学iptables，第一关就死在“表和链”的组合上。其实一句话就能概括：链是数据包必经的检查点，表是检查点上的规则集合。四张表分别是filter、nat、mangle、raw，五条链分别是PREROUTING、INPUT、FORWARD、OUTPUT、POSTROUTING。不是每条链都会经过所有表，数据包每走到一个检查点，只会执行挂在这条链上的规则，而同一张链上的规则还要按“表优先级”排队：raw最高，然后是mangle、nat、filter，最后是security。也就是说，一个数据包进到INPUT链，如果这条链上同时挂了mangle、nat、filter的INPUT规则，它们不会混在一起，而是按这个固定顺序分别执行。

为什么设计成这个顺序？因为职责是递进的。raw表管连接跟踪的豁免，它必须在conntrack之前决定“这个包要不要被跟踪”；mangle表管标记和修改报文，比如改变TOS字段、设置路由策略标记，这些动作需要在后续决策之前完成；nat表管地址转换，它对源地址或目的地址动手，直接影响路由走向；filter表才是真正的“审判”——放行还是丢弃。所以你配置防火墙策略时，绝大多数情况只需要碰filter表，偶尔碰nat表，mangle和raw用得很少。

还有个容易绕晕的点：表是在内核里固定注册的，你用iptables -t filter指定的是表，用-A INPUT指定的才是链。默认情况下不加-t参数操作的永远是filter表，这正是很多NAT规则“加上没反应”的根源——规则加到了filter表里，而数据包在nat表转了一圈根本不会去filter表的NAT位置找它。

1.2 数据包从进到出，走的是哪条路线

搞懂数据包之旅，排错时能省一半时间。数据包从网卡进来，先到PREROUTING链做第一轮处理，然后内核做一次路由判断：如果目的地址是本机，就进入INPUT链，最终交给上层应用；如果目的地址不是本机，就进入FORWARD链走转发路径。本机自己发出的数据包走OUTPUT链，发出之前还要经过POSTROUTING链做最后的源地址修正。

这里有个极易踩坑的点：FORWARD与INPUT是平行关系，不是前后关系。很多新手在服务器上配置了iptables NAT，结果发现内网机器能出去但响应回不来，就是规则挂错链了——放行转发流量的规则必须挂在FORWARD链，挂到INPUT链上的规则只管“进入本机”的数据包。另一个常见误解是“防火墙关闭有影响吗”，如果这台机器只是做普通桌面或单机测试，关掉可能影响不大；但只要这台机器承担了端口转发、容器网络、路由网关中的任何一项功能，防火墙链上就挂着NAT或转发规则，关掉后要么转发失效，要么规则全部丢失，影响面立刻暴露。所以我一般不建议直接关闭防火墙，而是把默认策略改成放行，或按需关停特定链，比整体拆除干净得多。

2. 黑白名单与反向放行：策略设计的两种思路

2.1 默认允许还是默认拒绝

搭建规则之前，先想清楚自己的策略基线。白名单思路是“默认拒绝，明确放行”，对应iptables就是把INPUT链默认策略设为DROP，只放行明确指定的IP、端口和服务。白名单的优势是安全性最高，未知流量一律进不来，适合数据库服务器、核心业务节点；代价也很直观，配置量成倍增加，每加一个服务就要补一条规则，而且容易把自己锁在外面。

黑名单思路是“默认放行，明确拒绝”，对应INPUT链默认策略ACCEPT，仅拒绝已知恶意IP或异常端口。这种模式适合内网办公区、临时调试环境，碰到新威胁大概率是后知后觉，安全性弱很多。现实中最稳的是混合策略：对外网流量走白名单，对内部可信网段走黑名单，把“谁可信”与“谁应被拒”分开管控。

黑白名单的选择没有绝对的对错，完全看你对这台机器暴露面的接受程度。我自己的习惯是：凡是能直接对外提供服务的节点，一律白名单起步；凡是纯内网或开发调试用的，默认ACCEPT，用黑名单兜底。这样切分的最大好处是，一旦策略被攻击者拿到，从默认策略就能判断出对方的安全水位——白名单环境里，只要漏一条就该被拦，安全监控也会更容易发现异常。

2.2 反向允许的优雅实现：conntrack状态机制

很多人配完白名单，第一条规则就写iptables -A INPUT -p tcp --dport 22 -j ACCEPT，然后发现SSH能连，但经常卡住甚至超时。原因很简单：对外服务端口确实放行了，但连接建立后返回方向的数据包，在INPUT链上被默认DROP拦掉了一部分。你可能想，那我补一条“放行所有回包”不就行了吗？对，这正是conntrack状态机制存在的意义。

标准做法是加一条状态规则：

bash复制iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

翻译成人话就是：凡是已建立连接的数据包、以及与已有连接相关的附加连接（比如FTP的数据连接、ICMP的错误回包），都直接放行。它的核心价值在于“反向允许”的实现——你不用为每个出站请求逐一配置回包放行规则，内核的conntrack表会记录连接状态，回包一到，状态匹配，直接通过。这也是有经验的工程师配置白名单时，第一件事先把这条STATE规则插在最前面，再考虑具体放行哪些端口的原因。

老的写法用-m state --state ESTABLISHED,RELATED，新内核推荐-m conntrack --ctstate ESTABLISHED,RELATED，我建议直接切换到ctstate写法，因为conntrack模块支持的状态类型更全面，还能配合--ctstate INVALID做异常拦截，把状态不明的包一律丢掉。加上INVALID状态的拦截规则后，很多扫描探测包在第一轮就被干掉了，能明显降低系统被试探的频率。

3. 三个高频实战场景，照着抄就行

3.1 屏蔽指定程序联网：以acrobat.exe为例

热搜词里有一条“先去防火墙建立出入站规则屏蔽acrobat.exe联网”，这其实是Windows防火墙的常用操作——在高级防火墙里新建出站/入站规则，直接指定程序路径即可。但Linux环境里想屏蔽某个特定程序的联网，思路完全不同。iptables工作在IP层，本身不识别进程名，它只看IP、端口、协议。所以要拦截某个进程的流量，得先从“这个进程是谁、在哪个用户下运行、访问哪些目标”三个角度切入。

实践中最常用的是owner模块，按用户ID匹配。比如服务器上某个用户uid是1003，它的程序经常外联可疑IP，想完全禁止它联网：

bash复制iptables -A OUTPUT -m owner --uid-owner 1003 -j REJECT
iptables -A OUTPUT -m owner --uid-owner 1003 -j LOG --log-prefix "uid1003-block: "

注意规则要挂在OUTPUT链，因为OUTPUT管的是本机发出的数据包，如果把规则误挂到INPUT链，只会拦截进入本机的包，对本机程序主动外发毫无作用——这正是“方向匹配”里最容易混淆的典型场景。另一个坑是，很多程序会以服务账号运行（systemd服务里指定的User），查看uid时要先确认：

bash复制ps -eo pid,user,uid,cmd | grep -E 'acrobat|Adobe'

如果找不到固定uid，或者程序走的是随机端口、动态域名，那就退一步：先看它解析到哪些域名或IP，在OUTPUT链上直接封目标IP段；如果目标域名固定，还可以配合DNS拦截，把这几个域名解析到一个不可达地址，或者把对应目标IP封禁。如果你的程序走的是HTTP明文、且特征字符串固定，还能用iptables的string模块在应用层做关键词拦截：

bash复制iptables -A OUTPUT -m string --string "/badpath" --algo bm -j REJECT

相当于做了七层关键词拦截，但只对明文流量有效，HTTPS加密流量就无能为力了。这几个手段组合起来，基本能把一个管不住的小程序按在本地。

3.2 开启防火墙后ping不通的排查

“开启防火墙后ping不通”这条热搜，命中率极高。原因很直接：很多默认策略一上来就把INPUT链DROP了，而ICMP协议（也就是ping使用的协议）没有被单独放行。有个经典案例，有朋友给服务器配置了白名单，SSH、Web、数据库端口都放行了，结果运维同事一ping，时通时不通，查到最后才发现是ICMP被DROP掉。最让人懵的是，如果不看iptables规则，光看网络状况，几乎猜不到是防火墙干的。

排查顺序可以固定成这样：

bash复制iptables -L INPUT -n -v    # 看INPUT链现有规则和默认策略
ping -c 3 127.0.0.1        # 先确认本地回环通不通
ping -c 3 目标IP           # 再确认远端通不通
iptables -I INPUT -p icmp --icmp-type echo-request -j ACCEPT

正常情况下，ping本机回环地址不受防火墙影响；如果回环正常而外部ping不通，八九不离十就是ICMP被规则拦了。我建议不只放行echo-request，干脆把echo-reply也一起放行，否则回包方向也可能被卡。补上规则后，对比一下前后状态。这里说句经验之谈：我不推荐把整条ICMP协议全部放行，更稳的做法是只放行echo-request和echo-reply两种，其它ICMP类型（比如重定向、超时）按需放行，这样既保证日常连通性检测，又不把暴露窗口开得太大。

3.3 eNSP里模拟华为防火墙：Web登录配置

热搜里连着几条都提到eNSP——华为的网络模拟平台，可以虚拟出交换机、路由器，还有USG系列防火墙。很多人用eNSP做实验，卡就卡在防火墙的Web登录上，命令敲了，接口IP配了，浏览器就是访问不进云。这个问题的本质是：防火墙默认只在“local”安全域放行对自身的访问，其它域的流量默认拒绝，你想从GigabitEthernet口访问防火墙自身，就必须先把接口加入安全域，并放行该域到local域的访问策略。

在eNSP里USG防火墙上，最小可用配置大致是这样：

bash复制# 进入接口视图，配置管理IP
system-view
interface GigabitEthernet1/0/0
 ip address 192.168.1.1 24
 quit

# 把接口加入trust域
firewall zone trust
 add interface GigabitEthernet1/0/0

# 放行trust域到local域的流量
security-policy
 rule name allow_web
  source-zone trust
  destination-zone local
  action permit

# 开启HTTPS服务，并创建管理员账号
web-manager enable
aaa
 local-user admin password cipher Admin@123
 local-user admin privilege level 15
 local-user admin service-type http

配置完成后，电脑网卡改成192.168.1.2/24，浏览器访问https://192.168.1.1就能打开登录页。这里有个非常隐蔽的坑：华为防火墙的Web管理默认监听HTTPS协议，你在浏览器里输http://192.168.1.1，大概率是打不开的，还容易误判成“配置没生效”。另外，如果加了安全策略仍然登录失败，检查三件事：接口有没有加入trust域、安全策略方向有没有写反、管理PC的网关是不是指向了防火墙接口。这三件事能解决eNSP里九成的登录问题。顺带说一句，不同厂商的设备命令差异很大，锐捷、H3C、西门子都有各自命令行体系，但安全域、放行策略这些底层逻辑是相通的，把华为这套配置思路吃透，迁移到其它品牌只是命令翻译的问题。

4. 防火墙双机热备的原理与落地

4.1 主备切换的关键：会话同步与故障探测

防火墙双机热备这个词，在B端项目里听到的概率很高。思路不复杂：两台防火墙，一台主一台备，主设备故障后业务流量自动切到备机。但难点不在于“切换”，而在于“切换后连接不中断”。普通的HTTP请求受影响还好，重连一下就能恢复；像数据库长连接、SSH会话、视频流这类长时间连接，一旦主设备宕机，即便网络层面切到备机，原来建立的会话表也丢了，对端仍然收不到数据。

所以生产级的双机热备方案，核心是两件事：故障探测和会话同步。故障探测常用VRRP（虚拟路由冗余协议），两台防火墙组成一个虚拟路由器，对外共享一个虚拟IP，主设备通过组播周期性发送VRRP通告，从设备连续几个周期没收到通告，就触发切换。会话同步则是主备之间通过专用心跳链路，把每条会话的状态实时复制到备机，主设备一异常，备机直接用已同步的会话表接管流量，用户基本无感知。

在华为USG防火墙上，双机热备叫HRP（Huawei Redundancy Protocol），最小配置：

bash复制hrp interface GigabitEthernet1/0/2 remote 192.168.0.2
hrp enable

启用后，两条防火墙之间通过指定接口同步会话信息，还可以配置hrp standby-device让备机处于监听状态。注意心跳接口不要复用业务接口，主备之间的会话同步数据量不大但要求低延迟，建议用独立的二层互联端口直连，别和业务流量挤在一起，否则一次突发流量就可能把心跳拖超时，导致主备频繁切换，比不切还难受。

4.2 从Keepalived到硬件防火墙：两种落地方式

软件环境里没有华为防火墙硬件，用什么实现双机热备？我最常用的组合是Keepalived加iptables，再加两个实例的规则同步。Keepalived负责VRRP虚拟IP的漂移，两边各跑一套iptables规则，主备之间通过心跳判断状态，主挂了虚拟IP漂到备机，备机的规则原本就配好，流量自然被接管。

这里有一个容易被忽略的细节：iptables的状态信息默认不会同步，备机的conntrack表是空的，即便网络层切换成功，已建立的连接也会断。所以软件方案要做会话同步，要么用conntrackd，要么选用设计上不依赖长连接的业务（比如定时重连的应用）。如果你的业务能接受几秒钟的连接中断，Keepalived加iptables方案足够；如果要求会话无损切换，就得回到硬件防火墙，或者引入专门的高可用中间件。两种方式对比：

热搜里还有一条“防火墙ips waf自动切换原理”，这种场景通常是防火墙后面还串了IPS、WAF等安全设备，每层设备都要高可用。整体思路是相通的：每层设备一台主一台备，各层之间通过心跳感知对端状态，切换时还要考虑上下层设备的联动——比如防火墙切换到备机后，WAF也要能感知到新的防护对象。这种多层联动对配置一致性要求极高，部署前最好先画一张流量走向图，明确每一层的主备角色和切换顺序，再逐层配置，别一头扎进命令里。

5. 典型故障与排查技巧速查

5.1 规则不生效？先检查这三件事

“iptables规则明明加上了，就是不生效”是群里出现频率最高的问题。按我的排障习惯，从三个方向入手。第一，规则挂的链对不对。进站流量看INPUT，转发流量看FORWARD，出站看OUTPUT，方向错了直接白搭。第二，规则顺序对不对。iptables的规则是从上到下逐条匹配的，匹配到第一条就直接执行，不再往下看，把ACCEPT写在DROP下面，那这条ACCEPT等于没写。第三，有没有改错表。默认情况下iptables -A不加-t参数操作的是filter表，如果你做的是端口转发，需要操作的是nat表，少了-t nat，规则还是加上了，但它根本不在期望的位置。

提示：想确认一条规则到底有没有被流量命中，别只看规则内容，用iptables -L -n -v看输出的pkts列。那一列如果一直是0，说明规则虽然存在，但根本没匹配上——方向、顺序、表位置三个因素里必有一个出了问题。

还有一个更隐蔽的点：默认策略。有时你看到规则里确实放行了某个端口，但流量还是进不来，记得敲一句iptables -L -n -v看看每条链的policy。默认策略是DROP的话，如果放行规则没有匹配到，也会被默认策略拦掉。很多次帮人排障，检查到最后，问题不是规则错了，而是策略和规则之间的交互出了岔子。

5.2 重启后规则全没？这套持久化方案拿走

iptables规则的宿命是“改完即忘”——所有通过命令添加的规则都存在内存里，重启一下就全没了。Docker和容器平台每次重启都会自动重建NAT规则，但你自己加的那些规则不会。生产环境里给服务器配好规则后，一定要记得持久化。

Debian/Ubuntu系的常规做法是安装netfilter-persistent：

bash复制apt install iptables-persistent netfilter-persistent
iptables-save > /etc/iptables/rules.v4
ip6tables-save > /etc/iptables/rules.v6
systemctl enable netfilter-persistent

RHEL/CentOS系则可以用iptables-services，或者直接在/etc/sysconfig/iptables里维护规则。如果你的服务器同时跑IPv6，别忘了把ip6tables规则也一起导出保存，很多设备的IPv6防火墙规则是独立管理的，漏配会导致IPv6流量不受控制或干脆不通。更工程化的做法是写一个开机自启脚本，把规则按模块用函数整理，交给systemd执行。脚本化还有个额外好处：规则表可以放进版本库，变更走评审，出问题时翻历史就能看到谁在什么时候改了哪条规则——对需要合规整改的单位来说是刚需。不过要注意，脚本里规则写入之前先执行iptables -F清空，再重新写入，确保每次启动都是干净状态，别和旧规则叠加。

5.3 端口转发与“请检查您的防火墙和端口转发规则”

“请检查您的防火墙和端口转发规则”这句提示，是很多内网穿透、端口映射场景下的经典报警文案。iptables做端口转发的标准套路是DNAT加SNAT配合，缺一不可：

bash复制# 开启内核转发
sysctl -w net.ipv4.ip_forward=1

# 外部访问本机8085端口，转发到内网192.168.1.100的80端口
iptables -t nat -A PREROUTING -p tcp --dport 8085 -j DNAT --to-destination 192.168.1.100:80

# 修改源地址，保证回包能回到防火墙
iptables -t nat -A POSTROUTING -p tcp -d 192.168.1.100 --dport 80 -j SNAT --to-source 本机出口IP

这里最常见的失误是只写DNAT忘了SNAT。DNAT把目的地址改了，数据包转发给内网机器之后，内网机器回包的源地址还是它自己，它会直接回复给访问者，可访问者发起连接时用的目标是防火墙的地址，结果就出现“能连上但响应超时”的诡异现象。加上SNAT把回包源地址改成防火墙地址，连接才能顺利建立和关闭。另外记得在FORWARD链上放行相关流量，内网转发的数据包走的不是INPUT链，而是FORWARD链，这里的坑和前面1.2节讲的方向问题一脉相承。还有个顺手要查的点是sysctl net.ipv4.ip_forward，很多系统默认是0，不打开的话即使NAT规则是对的，数据包也根本不会转发。

5.4 附带一提：防火墙关了还是提示服务异常

还看到一条热搜“防火墙关了还是提示服务异常”。出现这个问题，通常说明问题不只是防火墙这一层。提示服务异常的软件，要么依赖的端口被其它进程占用，要么它用的是随机高位端口而某些规则没放行，要么它本身依赖的某个服务没启动。防火墙只是链路层的拦截者，它关了但故障依旧，就要把排查方向转到端口监听状态、服务进程状态、以及网络连接日志上去。用一条命令就能看全：

bash复制ss -lntp | grep -E '8080|8443'

同时看一下服务本身的日志，很多时候答案就在错误日志的前几行里。防火墙和“服务异常”是两套故障体系，别把所有问题都归到防火墙上，那样会浪费大量时间在错误的方向上。

最后再分享一点我的体会。操作iptables，最稳妥的不是背命令，而是养成三个习惯：第一，改动前先iptables-save做一份快照，任何变更都可回滚；第二，每条规则尽量带注释（-m comment --comment "xxx"），三个月后再回来看规则文件，能省下大量脑细胞；第三，先小范围测试再全量执行，尤其是默认策略从ACCEPT改成DROP这种动作，一个回车下去可能就是生产事故。iptables不是洪水猛兽，只要把它运行的原理摸透，再复杂的策略本质上都是在回答三个问题：这个包从哪来、到哪去、该不该放行。