1. 为什么Docker容器的iptables规则总是不生效？

很多运维同学在第一次接触Docker网络安全时都会遇到这样的困惑：明明用iptables添加了端口限制规则，为什么容器还是能被任意访问？我刚开始用Docker时也踩过这个坑。当时为了等保合规要求，需要限制某个MySQL容器的3306端口只允许内网特定IP访问，按照传统方式在INPUT链添加规则后，测试时却发现外网IP依然能连通，差点导致安全事件。

后来才发现，Docker的网络栈和传统Linux主机有本质区别。当安装Docker时，它会自动创建一组自定义的iptables链，其中最关键的就是DOCKER和DOCKER-USER这两个链。所有进出容器的流量都会被Docker劫持到这些特殊链进行处理，而不会经过我们熟悉的INPUT/OUTPUT链。这就是为什么直接在常规链上配置规则会失效。

具体来说，Docker的网络流量处理流程是这样的：

1. 外部请求到达主机网卡
2. 首先经过PREROUTING链
3. 然后被重定向到DOCKER-USER链（这是我们可以安全操作的第一道关卡）
4. 接着进入DOCKER链（由Docker自动管理，不建议手动修改）
5. 最后通过DNAT转发到具体容器

2. DOCKER-USER链的三大核心优势

2.1 规则持久化不丢失

Docker每次重启服务时都会重建自己的iptables规则，如果你把自定义规则放在DOCKER链里，这些规则会被无情覆盖。而DOCKER-USER链就是Docker官方留给用户的自定义规则区，它的位置在Docker自动生成规则之前，又不会被服务重启影响。我在生产环境实测过，即使执行systemctl restart docker，放在DOCKER-USER链的规则依然坚挺。

2.2 规则优先级更高

网络流量会先经过DOCKER-USER链的处理，然后才进入Docker自动管理的DOCKER链。这意味着我们可以在这里实现"先禁止所有，再逐个放行"的白名单策略。比如下面这个典型的生产环境配置：

# 先阻断所有访问Docker容器的流量
iptables -I DOCKER-USER -i eth0 -j DROP
# 再放行运维跳板机的SSH访问
iptables -I DOCKER-USER -i eth0 -s 10.10.1.100 -p tcp --dport 22 -j ACCEPT
# 允许监控服务器访问Prometheus端口
iptables -I DOCKER-USER -i eth0 -s 10.10.2.200 -p tcp --dport 9090 -j ACCEPT

2.3 支持更精细的匹配条件

通过结合iptables的各种模块，可以实现企业级的安全策略：

• 用-m iprange匹配IP段范围
• 用-m time实现工作时间访问控制
• 用-m connlimit防止CC攻击
• 用-m recent实现动态黑名单

比如我们要限制某个API容器每分钟最多接受60个新连接，超过就加入黑名单：

iptables -N DOCKER-API-LIMIT
iptables -A DOCKER-USER -p tcp --dport 8080 -m conntrack --ctstate NEW -m recent --set
iptables -A DOCKER-USER -p tcp --dport 8080 -m conntrack --ctstate NEW -m recent --update --seconds 60 --hitcount 60 -j DOCKER-API-LIMIT
iptables -A DOCKER-API-LIMIT -j LOG --log-prefix "API过度访问: "
iptables -A DOCKER-API-LIMIT -j DROP

3. 五种必须掌握的DOCKER-USER实战场景

3.1 基础IP白名单控制

这是最常见的需求，只允许特定IP访问容器服务。关键点是要把允许规则放在拒绝规则之前，因为iptables是顺序匹配的。我建议使用以下模板：

# 先放行内网网段
iptables -I DOCKER-USER -i eth0 -s 192.168.1.0/24 -j ACCEPT
# 放行特定公网IP
iptables -I DOCKER-USER -i eth0 -s 203.0.113.45 -j ACCEPT
# 最后拒绝其他所有流量
iptables -A DOCKER-USER -i eth0 -j DROP
# 不要忘记允许已建立的连接
iptables -I DOCKER-USER -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

3.2 端口级访问控制

对于暴露多个端口的容器，我们需要更精细的控制。比如一个Nginx容器同时提供HTTP(80)和HTTPS(443)，但只想对外开放HTTPS：

# 允许所有人访问443端口
iptables -I DOCKER-USER -p tcp --dport 443 -j ACCEPT
# 但80端口只允许内网访问
iptables -I DOCKER-USER -p tcp --dport 80 -s 192.168.1.0/24 -j ACCEPT
# 拒绝其他所有80端口的请求
iptables -A DOCKER-USER -p tcp --dport 80 -j DROP

3.3 防御端口扫描

生产环境经常遇到端口扫描探测，我们可以用recent模块实现自动封禁：

iptables -N DOCKER-ANTISCAN
iptables -A DOCKER-USER -m recent --name ATTACKER --rcheck --seconds 3600 -j DOCKER-ANTISCAN
iptables -A DOCKER-USER -m recent --name ATTACKER --set
iptables -A DOCKER-ANTISCAN -j LOG --log-prefix "端口扫描攻击: "
iptables -A DOCKER-ANTISCAN -j DROP

3.4 多租户隔离

在K8s或Swarm集群中，可能需要隔离不同租户的容器网络。假设我们有租户A(10.0.1.0/24)和租户B(10.0.2.0/24)：

# 租户A只能访问自己的MySQL
iptables -I DOCKER-USER -s 10.0.1.0/24 -d 10.0.1.100 -p tcp --dport 3306 -j ACCEPT
# 租户B只能访问自己的Redis 
iptables -I DOCKER-USER -s 10.0.2.0/24 -d 10.0.2.100 -p tcp --dport 6379 -j ACCEPT
# 默认禁止跨租户访问
iptables -A DOCKER-USER -j DROP

3.5 时间维度控制

有些场景需要限制访问时间，比如测试环境只允许工作时间访问：

iptables -I DOCKER-USER -m time --timestart 09:00 --timestop 18:00 --weekdays Mon,Tue,Wed,Thu,Fri -j ACCEPT
iptables -A DOCKER-USER -j DROP

4. 规则管理的四个最佳实践

4.1 规则持久化方案

默认情况下iptables规则重启后会丢失，在生产环境必须配置持久化。不同Linux发行版方法不同：

对于CentOS/RHEL：

service iptables save
# 或者
iptables-save > /etc/sysconfig/iptables

对于Ubuntu/Debian：

apt install iptables-persistent
netfilter-persistent save

4.2 规则调试技巧

当规则不生效时，可以按这个流程排查：

1. 查看完整规则列表：iptables -L -n -v --line-numbers
2. 检查DOCKER-USER链：iptables -L DOCKER-USER -n -v --line-numbers
3. 开启日志记录临时规则：iptables -I DOCKER-USER -j LOG --log-prefix "DOCKER-USER: "
4. 查看系统日志：tail -f /var/log/syslog | grep DOCKER-USER

4.3 规则优化建议

当规则数量超过50条时，性能会明显下降。建议：

1. 合并相同目标的连续规则
2. 使用ipset管理大量IP地址
3. 把高频匹配的规则放在前面
4. 定期清理无效规则

比如用ipset优化大型白名单：

ipset create ALLOWLIST hash:ip
ipset add ALLOWLIST 192.168.1.100
ipset add ALLOWLIST 203.0.113.45
iptables -I DOCKER-USER -m set --match-set ALLOWLIST src -j ACCEPT

4.4 容器网络诊断命令

这些命令能帮你理解Docker网络架构：

# 查看Docker网络详情
docker network inspect bridge
# 查看NAT规则
iptables -t nat -L -n
# 追踪数据包路径
tcpdump -i docker0 -nnvvv
# 检查路由表
route -n