90%人没理清的 iptables 核心：七表五链实战指北

本文链接：https://blog.csdn.net/2201_75340297/article/details/147246886

$M oo n ey F a ll s, A Z, U S A$

每日语录： “It’s a job that’s never started that takes the longest to finish.”

$引言$

今天就围绕这个问题，来探讨下，这个问题能完全回答上来的没有几个。工作中用到的不多，但是这是每一个 Linux 工程师都需要知道的底层知识。

如果文章哪里有问题，还望指出。

最后有相关的学习群，有兴趣可以加入。

$开始$

在 Kubernetes 集群中，当某个节点突然无法转发流量时，你可能会在日志中看到 iptables rules conflict 的报错——这背后隐藏的是 Linux 网络层最核心的流量控制机制：iptables。作为 Linux 内核级防火墙工具，iptables 通过 七张表（Tables） 和 五条链（Chains） 的组合，实现了从网络层到应用层的精细化流量控制。本文将从底层原理、核心架构、实战命令三个维度，拆解 iptables 的设计哲学。

一、先导知识：数据包的“人生旅程”

当一个数据包进入Linux系统时，它会经历多个“检查站”，每个检查站都有不同的决策规则。这个过程类似于快递分拣：

入境检查（PREROUTING）：判断包裹是否要转运（NAT）或直接派送。
本地派送（INPUT）：决定是否签收（交给本机应用）。
跨境运输（FORWARD）：中转包裹到其他机器。
出境准备（OUTPUT）：处理本机发出的包裹。
出境登记（POSTROUTING）：记录包裹最终去向。

二、七张表：不同职能的“决策部门”

注意：传统说法中的“七表”实际是历史版本的概念，现代Linux内核（4.x+）常用五张表：raw、filter、nat、mangle、security。此处以生产环境常用表解析。

1. raw表（原始数据裁决所）

职能：在连接跟踪（conntrack）之前处理数据包，决定是否跳过状态跟踪。
应用场景：
- 对特定流量禁用连接跟踪（如高并发场景优化性能）。
- 标记不需要NAT的流量。

# 禁用对80端口的连接跟踪
iptables -t raw -A PREROUTING -p tcp --dport 80 -j NOTRACK

2. filter表（流量安检门）

职能：决定是否允许数据包通过（ACCEPT/DROP/REJECT）。
核心链：INPUT、FORWARD、OUTPUT。
经典规则：

# 允许已建立的连接
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# 阻止所有入站SSH暴力破解
iptables -A INPUT -p tcp --dport 22 -m recent --name SSH --set
iptables -A INPUT -p tcp --dport 22 -m recent --name SSH --update --seconds 60 --hitcount 3 -j DROP

3. nat表（地址翻译局）

职能：修改数据包的源/目标地址（SNAT/DNAT）。
核心链：PREROUTING、OUTPUT、POSTROUTING。
典型配置：

# 将外部访问1.1.1.1:80转发到内网10.0.0.2:80（DNAT）
iptables -t nat -A PREROUTING -d 1.1.1.1 -p tcp --dport 80 -j DNAT --to 10.0.0.2:80
# 内网机器通过网关上网（SNAT）
iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j SNAT --to-source 2.2.2.2

4. mangle表（数据整形科）

职能：修改数据包头部信息（如TTL、TOS、MARK）。
应用场景：
- 基于QoS标记流量优先级。
- 实现策略路由（结合iproute2）。

# 标记所有HTTP流量为优先级1
iptables -t mangle -A PREROUTING -p tcp --dport 80 -j MARK --set-mark 1

5. security表（强制安检室）

职能：实现强制访问控制（如SELinux策略）。
使用频率低：多数企业依赖上层防火墙或AppArmor/SELinux。

三、五条链：数据包的“必经关卡”

1. PREROUTING链（入境登记处）

触发时机：数据包进入网卡后，路由决策前。
常用表：raw、nat、mangle。
典型操作：DNAT、流量标记。

2. INPUT链（本地签收台）

触发时机：数据包目标为本机进程。
常用表：filter、mangle。
经典防御：过滤恶意扫描、限制ICMP洪水攻击。

3. FORWARD链（跨境中转站）

触发时机：数据包需要转发到其他机器。
常用表：filter、mangle。
核心用途：实现Linux网关或容器网络流量控制。

4. OUTPUT链（出境安检口）

触发时机：本机进程发出的数据包。
常用表：raw、filter、mangle、nat。
特殊场景：限制本机程序对外访问（如禁止MySQL客户端连接外网）。

5. POSTROUTING链（出境登记处）

触发时机：数据包发送到网卡前，路由决策后。
常用表：nat、mangle。
核心操作：SNAT（源地址转换）。

四、优先级与规则执行顺序

1. 表的处理顺序（从高到低）

raw → mangle → nat → filter → security

2. 链的执行流程

[ 数据包进入网卡 ]
        │
        ▼
   PREROUTING链
        │
        ▼
 路由决策（判断去向）
        │
        ├─目标为本机─────→ INPUT链 ───→ 本地应用
        │
        └─需要转发─────→ FORWARD链 ───→ POSTROUTING链
        │
[ 本地应用发送数据包 ] 
        │
        ▼
    OUTPUT链
        │
        ▼
   POSTROUTING链
        │
        ▼
[ 数据包离开网卡 ]

五、生产环境实战案例

案例 1：Kubernetes 节点流量转发异常

现象：Pod 跨节点通信失败，iptables-save 显示大量 KUBE-SVC 规则
根因：nf_conntrack 表满导致丢包

解决方案：

# 调整 conntrack 表大小
echo 524288 > /proc/sys/net/netfilter/nf_conntrack_max

# 添加 raw 表规则绕过跟踪（需评估安全影响）
iptables -t raw -A PREROUTING -p tcp --dport 80 -j NOTRACK

案例 2：防御 SSH 暴力破解

动态封禁策略：

# 使用 recent 模块记录攻击者 IP
iptables -A INPUT -p tcp --dport 22 -m recent --name ssh_attack --update --seconds 3600 -j DROP
iptables -A INPUT -p tcp --dport 22 -m recent --name ssh_attack --set -j ACCEPT

六、性能优化技巧

1. 减少规则数量

合并同类规则，如用IP集合（ipset）替代多个-s参数：

ipset create blacklist hash:ip
ipset add blacklist 192.168.1.100
iptables -A INPUT -m set --match-set blacklist src -j DROP

2. 调整表优先级

高频规则放在raw或mangle表，尽早拦截无效流量：

# 在raw表丢弃无效连接
iptables -t raw -A PREROUTING -p tcp --tcp-flags ALL NONE -j DROP

3. 关闭不需要的功能

停用无用的内核模块（如nf_conntrack_ftp）以减少计算开销：

echo 0 > /proc/sys/net/netfilter/nf_conntrack_helper

七、常见误区与排坑指南

误区1：“规则顺序无所谓”

问题：iptables规则按从上到下的顺序匹配。
反例：先ACCEPT all再DROP ssh会导致SSH未被阻断。
正解：严格规则在前，通用规则在后。

误区2：“DROP比REJECT更安全”

陷阱：DROP会静默丢弃数据包，导致客户端长时间等待。
建议：对已知恶意IP用DROP，对误操作用户用REJECT。

误区3：“nat表能过滤流量”

真相：nat表仅用于地址转换，过滤必须依赖filter表。

错误配置：

iptables -t nat -A POSTROUTING -s 10.0.0.5 -j DROP  # 无效！

结语

当你在 Kubernetes 集群中看到 kube-proxy 生成的数千条 iptables 规则时，不必感到恐惧——这正是七表五链设计灵活性的体现。掌握本文内容后，你可以：

精准定位生产环境中的网络策略冲突
为特定业务定制高性能流量控制规则
写出比 Kubernetes 默认实现更优雅的 CNI 插件

记住：真正的高手不是记住所有命令，而是理解数据包在 Linux 内核中的旅程。

$结语$

以上就是我们今天的内容，希望可以帮助到大家。

在这里插入图片描述