深入理解iptables：从四表五链到NAT转发与安全加固

1. iptables 防火墙到底是什么，别一上来就想着关

1.1 为什么新手总想“关掉防火墙”

遇到服务不通，很多人的第一反应是“把防火墙关了”。尤其搜出来的结果往往是“CentOS 7 关闭防火墙命令”，于是一顿操作：systemctl stop firewalld、systemctl disable firewalld，甚至还觉得不够痛快，直接敲一条 iptables -F 把所有规则清空。这样确实很快，但问题并没有被解决，只是从“端口被拦”变成了“主机裸奔”。等到下次重启，或者遇到真正的安全事件，才会意识到当初那个“关掉就好”的想法有多危险。

iptables 是 Linux 内核自带防火墙框架 netfilter 的管理工具，它管理的是每一个进出数据包的放行标准，而不是一个可以随意开关的软件服务。CentOS 7 上默认的 firewalld 只是前端管理工具，底层调用的仍然是 netfilter，只是规则组织方式不同。把 firewalld 停掉不代表防火墙不存在了，反而可能让你丢掉了原本有结构的规则管理。更合理的做法是先搞清楚服务为什么不通：先看服务监听在 127.0.0.1 还是 0.0.0.0，再用 ss -lntp 确认端口，最后才需要考虑防火墙规则。大多数“服务不通”的案例，其实只需要在 iptables 里放行一个端口，而不是把整道门拆掉。

1.2 iptables 能帮你解决的四个核心问题

先给 iptables 一个定位：它不只是一个“杀毒软件式”的防护工具，而是一套灵活的数据包处理框架。实际运维中，我主要用 iptables 解决四类问题。

第一是主机过滤，也就是最熟悉的黑白名单和端口控制。比如公司有固定出口 IP，只允许这个 IP 访问服务器的 SSH，其他人一律不接受，这能在很大程度上降低暴力破解风险。第二是端口映射，公网访问服务器的 80 端口，通过 DNAT 转发到内网某台机器上的 8080 端口，内网服务就这样被安全地暴露出去。第三是共享上网，内网一堆机器没有公网 IP，通过 SNAT 或 MASQUERADE 统一从一个出口 IP 访问互联网，这是企业内部网络最常见的用法。第四是安全加固，利用 limit、recent 等扩展模块限制请求频率，对 SSH 暴力破解、端口扫描做基础防御。

把这四类问题放在一起看，你会发现 iptables 的核心价值不是“有”和“没有”，而是“怎么把规则写得既安全又符合业务”。规则太松，等于裸奔；规则太紧，业务断掉。理解这一点，后面所有配置才谈得上合理。

2. 理解 iptables 规则引擎，先看数据包怎么走

2.1 四表五链的顺序，记不住也没关系

提到 iptables，就绕不开“四表五链”。这个词听起来像八股文，但它其实是理解规则的基础。五条链分别是 PREROUTING、INPUT、FORWARD、OUTPUT、POSTROUTING，表示数据包在内核中经过的五个检查点。四张表分别是 raw、mangle、nat、filter，表示不同种类的处理任务。数据包每经过一个检查点，就会去对应表里查找是否有需要执行的规则。

实际工作是复合的：数据包从网卡进来，先经过 PREROUTING，完成 NAT 目的地址转换、mangle 修改等，然后内核做路由判断——如果目的地是本机，就进入 INPUT 链，交给本地进程；如果目的地是别的机器，就进入 FORWARD 链，再由 POSTROUTING 做源地址转换后送出。本机自己发出的数据包则直接走 OUTPUT，再进 POSTROUTING。你不需要背下所有细节，但至少要清楚：本机访问别人要看 OUTPUT，别人访问本机要看 INPUT，转发流量要看 FORWARD，地址转换主要在 PREROUTING 和 POSTROUTING 上完成。

2.2 规则的匹配顺序和 ACCEPT、DROP、REJECT 怎么选

iptables 的规则是按顺序匹配的，一条规则匹配成功后，后面的规则就不再执行。这意味着规则顺序直接决定最终效果。很多人踩过这样的坑：先加了一条“拒绝所有来源”的默认策略，再加一条“允许某个 IP 访问”的放行规则，结果放行规则根本不生效，因为包在走到放行规则之前就已经被前面那条拒绝策略拦掉了。正确做法是把更具体的放行规则放在前面，把通用策略放在后面，或者把默认策略设置成 DROP，然后追加明确的 ACCEPT 规则。

动作的选择也需要经验。ACCEPT 就是放行，没什么可纠结。DROP 是直接丢弃数据包，表现是客户端一直卡在那里直到超时；REJECT 是拒绝并返回错误信息，表现是客户端很快收到 connection refused。从安全角度，很多人喜欢用 DROP，因为攻击者不容易判断端口到底是关闭还是被过滤；但从用户体验角度，内网服务更建议用 REJECT，至少让调用方快速失败，而不是等一肚子超时。我自己的一般原则是：对外暴露的服务入口多用 DROP，减少信息泄露；内部服务的错误访问用 REJECT，便于快速发现问题。

2.3 门禁保安的例子：一条规则是怎么生效的

把服务器想象成一个大楼，iptables 就是大楼门口按顺序排列的保安。每个访客（数据包）过来，保安从第一张纸条开始看：纸条上写着“某某公司的人可以直接进”，于是放行；第二条写着“推销人员拒绝入内”，于是拦下；如果访客都不匹配，就看最后一条兜底策略，“没有预约的一律不让进”。有了这个类比，你就明白为什么规则顺序很重要——如果第一张纸条就写着“所有人都不许进”，那后面“某某公司的人可以进”完全失去意义。这也是为什么大多数生产环境会采用“默认拒绝 + 白名单放行”的模式：把默认策略放在最后，把例外放行放在前面，既安全又明确。

3. 从最常问的“黑白名单”开始的实操配置

3.1 查看和保存 iptables 规则，先学会这四组命令

学习 iptables 不需要一上来啃整本书，先把最常用的命令练熟，后面再慢慢扩展。查看规则用这条：

iptables -L -n -v --line-numbers

-L 表示列出规则，-n 表示不做反向解析（避免因为 DNS 查询变慢），-v 显示流量计数，--line-numbers 显示行号。查 NAT 表则要指定表名：

iptables -t nat -L -n -v --line-numbers

添加规则用 -A 追加到链尾，插入到最前面用 -I，删除用 -D 加行号。这些命令本身不难，真正容易被忽略的是“保存规则”。iptables 规则默认只存在于内存，重启系统后全部丢失。 CentOS 7 上如果你确实想用 iptables 而不是 firewalld，需要先安装 iptables-services，然后停止并禁用 firewalld，再启动 iptables，最后把规则保存到文件：

yum install -y iptables-services systemctl stop firewalld systemctl disable firewalld systemctl enable iptables systemctl start iptables iptables-save > /etc/iptables/rules.v4

如果你只是想临时测试，不打算持久化，那至少要记住：所有手工添加的规则在重启前都是“临时工”。

3.2 白名单模式：默认拒绝，按需放行

白名单模式的思路是先把所有流量设为拒绝，再一步步放开明确允许的流量。适合公网服务器、数据库服务器、管理平台等安全性要求较高的场景。典型的操作顺序如下：

# 1. 设置默认策略为 DROP iptables -P INPUT DROP iptables -P FORWARD DROP # 2. 放行回环接口，避免本地程序受干扰 iptables -A INPUT -i lo -j ACCEPT # 3. 放行已建立的连接和关联连接 iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # 4. 放行指定管理 IP 访问 SSH iptables -A INPUT -s 10.0.0.0/8 -p tcp --dport 22 -j ACCEPT # 5. 放行 Web 服务端口 iptables -A INPUT -p tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j ACCEPT

注意第 3 步非常关键。如果没有放行 ESTABLISHED,RELATED，你明明写了允许 SSH 连接，但 SSH 的回应包会被当成新连接丢掉，表现就是连上就断。第 4 步要用你的真实管理网段替换，千万不要无条件放行整个互联网访问 22 端口。白名单模式的优点是安全性高，漏洞面小；缺点是规则容易漏，一个新服务上线忘了放行，业务就会悄悄挂掉。所以每一次变更都要记录到变更清单，别只靠脑子记。

3.3 黑名单模式：默认放行，精确拦截

黑名单模式和白名单模式正好相反，默认放行所有流量，只针对已知的恶意 IP、恶意网段、特殊端口做拦截。适合内网环境、物理办公网络这类本身信任度比较高的地方，或者用来临时封一批扫描 IP。基础命令很简单：

# 在 INPUT 链最前面插入一条封禁规则 iptables -I INPUT 1 -s 203.0.113.9 -j DROP # 封禁一个网段 iptables -I INPUT 1 -s 203.0.113.0/24 -j DROP # 封禁某个 IP 访问本机 443 端口 iptables -I INPUT 1 -s 203.0.113.9 -p tcp --dport 443 -j DROP

用 -I INPUT 1 是为了让规则插到最前面，确保如果后面有更宽松的放行规则，这条封禁也能先执行。黑名单模式的隐患在于：你只能拦截“已知”的攻击者，而真正的攻击往往来自不断变化的 IP 池。一直在后面加封禁规则，规则数量会越来越长，维护成本也高。所以我在生产环境很少用纯黑名单做主策略，更推荐默认拒绝加白名单，黑名单只作为临时应急手段。

3.4 NAT 端口映射和共享上网

NAT 是 iptables 里最实用也最容易出错的部分。先说共享上网，场景是内网有多台机器但只有一个公网 IP，需要让内网流量统一从这台 Linux 服务器出去。先开启内核转发：

sysctl -w net.ipv4.ip_forward=1 echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf

然后配置 SNAT，把源地址改为本机的公网 IP：

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE

动态拨号环境下建议用 MASQUERADE，它会自动取网卡当前 IP；固定 IP 环境下用 SNAT 性能更好：

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j SNAT --to-source 203.0.113.10

端口映射则是另一个方向：外部用户访问服务器公网 IP 的某个端口，需要转发到内网某台机器的内部端口。在 PREROUTING 链上做目的地址转换：

iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 80 -j DNAT --to-destination 192.168.1.10:8080

这里有个特别容易踩的坑：做完 DNAT 后，很多人忘了放行 FORWARD 链，结果流量根本到不了内网机器。你需要再补上 FORWARD 放行规则：

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -d 192.168.1.10 -p tcp --dport 8080 -j ACCEPT

第一句保证回应包能回来，第二句保证转发请求包能过去。缺少任何一句，端口映射都会表现为外部访问不通。

4. 再进一步：状态检测、限速和防暴力破解

4.1 conntrack 状态匹配：只放行“回头包”

很多教程都会让你加这样一条规则：

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

但没几个人解释为什么。Linux 内核有连接跟踪机制（conntrack），它会记录当前活跃的连接。一个 TCP 连接里，第一个 SYN 包是 NEW 状态，后续的握手包、数据包、挥手包都是 ESTABLISHED 状态，和这个连接相关的附加协议（比如 FTP 数据连接）则是 RELATED 状态。如果不放行这些包，即使你明确允许了入站方向的 8000 端口，客户端连上来以后发数据服务器确实能收到，但服务器返回的数据包在出口方向可能没问题，回到客户端时却可能被网关上一步的 INPUT 策略拦掉。这也就是“连得上但发不出数据”的典型原因。

我习惯把这条状态规则放在白名单规则的最前面，和回环接口放行放一起。它不会削弱安全性，因为 ESTABLISHED 只匹配你已经主动放行的连接，攻击者不可能凭空建立一条“已建立”的连接。真正要小心的是不要随手加一条-m state --state NEW -j ACCEPT，那样等于把门全部打开。

4.2 limit 和 recent 模块：限速与防爆破

iptables 自带的 limit 模块可以控制日志或匹配的速率，常用于防止日志刷屏。比如我只希望把访问 22 端口的失败尝试记录下来，但不希望日志被刷爆：

iptables -A INPUT -p tcp --dport 22 -m limit --limit 5/min --limit-burst 10 -j LOG --log-prefix "SSH_TRY: "

这里的--limit 5/min表示每分钟最多记录 5 条，--limit-burst 10表示允许短时间内的突发峰值 10 条。不加 limit 的 LOG 规则在遇到扫描时会在一分钟内写下几千条日志，直接把磁盘打满，这是一个非常容易忽视的风险。

比限速更强的是 recent 模块，它可以基于时间段内匹配次数做动态封禁。下面这套规则是针对 SSH 暴力破解的常见写法：

iptables -A INPUT -p tcp --dport 22 -m recent --name ssh_brute --update --seconds 60 --hitcount 5 -j DROP iptables -A INPUT -p tcp --dport 22 -m recent --name ssh_brute --set -j ACCEPT

第二句把每个访问 22 端口的 IP 记录到名为 ssh_brute 的名单里并放行，第一句则检查该 IP 在最近 60 秒内是否出现了 5 次及以上的访问，如果是，直接丢弃。实际使用时还可以配合 fail2ban 这类工具，但 iptables 原生的 recent 模块已经能应付很多基础场景，而且不依赖额外的软件包。

4.3 ipset 替代大量单条规则

当需要封禁的 IP 很多时，比如一次安全事件拉到了几千个恶意 IP，再用-I INPUT -s x.x.x.x -j DROP逐条添加，规则链会变得很长，匹配性能也下降。这时候用 ipset 更合适。ipset 是内核提供的一个集合管理工具，你可以把所有要封的 IP 放进一个集合，然后用一条 iptables 规则引用整个集合。

简单用法如下：

# 安装 ipset yum install -y ipset # 创建一个名为 blacklist 的集合，类型为 hash:ip ipset create blacklist hash:ip timeout 0 # 添加恶意 IP ipset add blacklist 203.0.113.9 ipset add blacklist 198.51.100.0/24 # 用一条 iptables 规则引用该集合 iptables -A INPUT -m set --match-set blacklist src -j DROP

ipset 的另一个优势是支持 timeout，创建集合时指定timeout 600，IP 加入后 600 秒会自动过期删除，非常适合临时封禁。比如 emergency 封禁时设置短超时，时间一到自动解除，能避免误封后还要手工解封的尴尬。规则持久化时需要同时保存 ipset 集合，否则重启后集合为空，iptables 规则会因找不到集合而报错。这点很多人会忽略，实际踩坑率很高。

5. 防火墙双机热备，iptables 高可用的落地思路

5.1 为什么业务需要防火墙双机热备

单台 iptables 网关服务器也可以正常上网、端口映射，但它是一个明显的单点。硬件故障、系统崩溃、网络维护都会导致整个出口中断，业务直接停摆。双机热备的目标很明确：两台防火墙节点互为备份，对外提供一个虚拟 IP（VIP），正常情况下主节点处理流量，备节点处于待命状态；主节点故障后，VIP 漂移到备节点，流量自动切换到备机，用户几乎无感知。

iptables 本身没有高可用能力，它只是规则引擎，所以我们要借助外部组件，最常见的是 keepalived 加 conntrackd。keepalived 负责 VIP 漂移，conntrackd 负责同步连接状态。这个组合在很多中小型 IDC 环境里被验证过，配置不算复杂，但需要注意的细节不少。

5.2 keepalived + iptables 双机热备的配置思路

两台服务器，分别称为 node-a 和 node-b，业务网卡都是 eth0，VIP 用 192.168.100.100。两台机器上安装 keepalived，并保证 iptables 规则完全一致。最简单的方式是把规则脚本放到相同路径，分别执行，或者用版本库统一分发。

node-a 的 keepalived 配置核心部分：

vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass mysecret } virtual_ipaddress { 192.168.100.100/24 } }

node-b 的配置类似，只是 state 改为 BACKUP，priority 改为 90。正常运行时，node-a 持有 VIP，所有外部访问都进到 node-a；当 node-a 故障，node-b 通过 VRRP 通告发现主节点失联，就会把 VIP 绑定到自己的 eth0 上，继续处理流量。这里有个坑：主备两台机器的 iptables 规则必须一致，否则主节点挂了，备节点接管后规则缺失，服务照样不通。所以不要把双机热备理解成“两台机器随便配配”，规则一致性才是核心。

5.3 conntrack 同步：主备切换时连接不掉

如果只做 VIP 漂移，会发现切换瞬间新连接可以正常建立，但原本已经建立的 TCP 连接会断开。原因是 conntrack 状态表没有跟着切换过去，备机的防火墙不知道这些连接是合法的，直接把它当成新连接处理，而默认策略通常是拒绝新连接，于是连接被切断。

解决方案是使用 conntrackd 同步两边的连接状态表。配置思路是这样的：节点 A 和 B 都运行 conntrackd，主节点上的连接状态变化会通过多播发送给备节点，备节点更新自己的 conntrack 表。当主节点宕机，备节点已经提前知道了所有活跃连接，VIP 漂移后依然能根据旧的 conntrack 表放行这些连接，从而保持 TCP 会话不断。conntrackd 的配置比较复杂，但这里强调的是这个方向：双机热备不是简单地“主备网卡切换”，连接状态同步才是真正让用户无感知的关键。有条件的话，一定要在测试环境切几次电源、拔几根网线，观察 SSH、数据库长连接、视频流三类典型业务的表现，再上生产。

6. 常见故障与避坑实录：别让防火墙背锅

6.1 “防火墙关了还是提示服务异常”是怎么回事

经常有人在论坛问：“我已经把 firewall 关了，为什么服务还是提示异常？”这种问题大概率不是因为防火墙服务本身，而是没有分清“服务进程”和“规则链”。firewalld 停了，iptables 规则可能还在；甚至你根本没装 iptables-services，但系统里有 Docker，Docker 会自己往 iptables 里写一堆 FORWARD 链规则，和你的业务规则混在一起。另一个常见原因是服务只监听了 127.0.0.1，外部请求到达不了；还有 SELinux 拦截，虽然防火墙是放开的，但 SELinux 会把端口访问挡在应用层之外。

排查顺序建议是：先ss -lntp看监听地址，再看iptables -L -n看当前规则，然后用curl -v从本机和其他机器分别访问，把范围一步步缩小。Windows 上出现过类似现象，比如防火墙错误代码 0x800706d9，那是 Windows Defender Firewall 依赖服务异常导致的报错，和 Linux 上的“服务关了还提示异常”看起来不同，但本质都是一个道理：错误提示不等于根因，要顺着依赖关系一层层查。

6.2 规则重启后丢失？保存规则的正确姿势

规则重启丢失是另一个高频问题。如果系统默认用的 firewalld，你手动加了一堆 iptables 命令，但没安装 iptables-services，重启后这些命令当然不会自动加载。正确做法是把规则保存到文件并在开机时恢复。可以用：

iptables-save > /etc/iptables/rules.v4 iptables-restore < /etc/iptables/rules.v4

配合 systemd 的话，也可以写一个简单的 service 单元，在启动时执行 iptables-restore。还有一个容易踩的坑是 Docker 环境：Docker 启动时会重建 iptables 规则，如果你手写了规则又执行了 iptables-save，可能会把 Docker 动态生成的规则也保存进去，之后 Docker 再启动时两边冲突，容器网络直接异常。所以 Docker 主机上的 iptables 操作要格外小心，尽量用 Docker 的 network 配置或云平台安全组，而不是直接改宿主机规则。

6.3 误封自己 IP 导致 SSH 断开的自救方法

这个坑几乎每个运维都踩过。在远程服务器上执行了一条类似iptables -A INPUT -s 你的IP -j DROP的规则后，当前 SSH 连接可能立即断开，再也连不上。最稳妥的自救方式是提前预防：在改动任何有风险的防火墙规则之前，先加一条定时清空规则的任务，比如：

echo "iptables -F" | at now + 2 minutes

这样即使误封，两分钟后规则也会自动清空，不至于把自己锁在门外。如果已经断了，就需要通过云控制台的 VNC、带外管理、或者机房的管理口登录，进入系统后执行iptables -F清空规则。如果是物理机且没有带外管理，那只能找同事或现场人员帮忙了。所以我的习惯是：远程操作 iptables 时永远先备份当前规则，再操作，操作完立刻检查iptables -L -n --line-numbers，确认没有错误规则后再继续。

6.4 品牌防火墙与 iptables 的关系：eNSP、锐捷、H3C、山石怎么对照

很多人在学 iptables 之前，可能先接触过华为 eNSP 模拟器里的防火墙，或者锐捷、H3C、山石的硬件防火墙。这些商业防火墙的配置方式和 iptables 差别很大：它们更多采用“安全区域 + 安全策略”模型，比如把接口划分到 trust、untrust 区域，再定义从哪个区域到哪个区域允许什么服务。配置界面有的是 Web，有的是专用命令行，和 Linux 的iptables -A INPUT -s ...完全是两套语法。

但底层逻辑是相通的：无非是源地址、目的地址、源端口、目的端口、协议、动作这几个要素。在 eNSP 里练熟区域策略模型后，再看 iptables 的 INPUT 链、OUTPUT 链，会更容易理解流量方向的概念。反过来也一样，玩透了 iptables 的四表五链，再去配置商业防火墙，也不会觉得陌生。遇到具体设备时，不要凭记忆硬套，先查官方命令手册或 Web 界面上的帮助，因为各个厂商的关键字差异很大。

7. 写在最后：维护 iptables 的几条经验

7.1 给规则做注释和版本管理

iptables 的规则默认是没有注释的，三个月后回看，很可能想不起来某条规则是干什么的。建议在每条规则上加注释，用 comment 模块：

iptables -A INPUT -s 10.20.0.0/16 -p tcp --dport 3306 -j ACCEPT -m comment --comment "allow internal app access mysql"

更重要的是把规则写成脚本并纳入版本管理。不要每次变更都在命令行手工敲，而是修改脚本文件，走一次评审，再执行。这样规则变更历史清晰，出问题也能回滚。我的习惯是维护一个/etc/firewall/rules.sh，里面按功能分段写清规则，配合一个 backup 目录保存每次变更前的iptables-save结果。

7.2 先模拟，后停机，再放量的操作习惯

生产环境操作 iptables 要养成三个习惯。第一，变更前先iptables-save > /data/backup/iptables-$(date +%F).bak做一次完整备份；第二，在测试环境用同一套规则跑一遍，验证默认策略对业务无影响；第三，生产变更选择低峰期，并准备一条回滚命令，比如iptables-restore < /data/backup/iptables-xxx.bak。如果一次要变更十几条规则，可以先用iptables-restore --test检查语法，避免一条错误导致整个规则集加载失败。别嫌麻烦，绝大多数线上事故都是“临时改一下”惹出来的。

7.3 我的个人体会

说实话，iptables 的语法并不复杂，难的是规则设计和对流量的理解。我踩过最深的坑是“只放行入站，忘了放行回包”；最狼狈的时刻是在一台海外服务器上误封了自己的管理 IP，最后靠经销商后台重启才解决。踩过几次之后，我现在维护防火墙的原则很简单：能不开的端口尽量不开，能在云安全组或前置防火墙完成的拦截尽量在前置完成，iptables 只保留业务必须的最小规则集。规则不是越多越好，而是越少越稳；每一条规则都要让未来的自己看得懂。你可以在实际使用中保留一套自己的规范，但记住一句话：任何规则写完，先站在“三个月后的自己”角度问一问，这条规则能不能一眼看明白？想不明白，就说明还没写清楚。