如果你在服务器上装了 Docker又习惯自己手写 iptables 规则大概率经历过这种场景明明已经用防火墙脚本把 FORWARD 链默认策略设成了 DROP也开放了该放的端口结果某天重启了一下 docker 服务再执行iptables -L -n发现规则里多了一堆 DOCKER 开头的链FORWARD 链默认策略甚至变成了 ACCEPT。有些朋友一开始以为是配置没生效反复检查防火墙脚本其实根源只有一个Docker 默认会自动修改主机的 iptables 规则。这篇文章就把这个问题一次讲透为什么 Docker 要对 iptables“越权”如何阻止 Docker 自动改规则关掉之后网络会出现哪些问题以及如何手动把端口映射、容器出网、网段隔离这些能力补回来。内容面向已经能独立操作 Linux 的开发者、运维和自建服务的同学属于可直接照做的实战向配置不是原理堆砌。1. 为什么我的防火墙规则总被 Docker 覆盖——默认网络模型拆解1.1 Docker 默认 bridge 网络对 iptables 的三类依赖Docker 之所以会主动改 iptables不是因为“手贱”而是因为它默认创建的 bridge 网络就是那个最常见的 docker0以及你通过docker network create创建的自定义 bridge 网络在设计上就把 netfilter 当成了基础组件。单机 Docker 要想提供以下三个能力几乎都要靠 iptables 来实现。第一是端口映射。当你执行docker run -p 8080:80时Docker 会在 NAT 表的 PREROUTING 链里加一条 DNAT 规则把到达宿主机 8080 端口的流量转发到容器 IP 的 80 端口。没有这条规则宿主机端口上即使有进程在监听外部流量也未必能按预期到达容器。第二是容器出网。docker0 网段默认是私网网段比如 172.17.0.0/16容器访问外网时Docker 会在 POSTROUTING 链加一条 MASQUERADE 规则让容器流量“伪装”成宿主机 IP 出去。这个行为很多人平时感觉不到因为它是自动完成的。第三是容器间隔离。Docker 需要控制不同 bridge 网络之间的流量是否互通比如两个自定义网络之间默认是隔离的这部分逻辑同样落在 FILTER 表的 FORWARD 链上Docker 会建立 DOCKER-ISOLATION-STAGE-1/2 这样的链来做判断。所以只要 Docker daemon 在运行并且没有明确告诉它“不要动防火墙”它就会按照自己的需求追加规则。这里的矛盾点在于Docker 追加规则用的是-A追加到链尾但它还会顺手创建自己的链并且经常把系统 FORWARD 链的默认策略改成 ACCEPT这就会和你已有的安全策略产生冲突。1.2 Docker 到底改了哪些链和规则我把常见版本的 Docker 在启动时会产生的 iptables 变更整理成了表方便你对照排查表链Docker 的典型动作filterFORWARD创建 DOCKER-USER、DOCKER、DOCKER-ISOLATION-STAGE-1/2 等链并把 FORWARD 链默认策略改为 ACCEPTfilterDOCKER追加容器相关的过滤规则主要是控制端口映射后的访问路径filterDOCKER-USER预留给用户自定义规则的链Docker 不会清理它natPREROUTING为每个-p/--publish端口追加 DNAT 规则natPOSTROUTING为 bridge 网段追加 MASQUERADE 规则natDOCKER维护端口映射对应的 DNAT 标记供 PREROUTING 链调用注意 FORWARD 链默认策略这一点。绝大多数安全基线里都会把 FORWARD 策略设为 DROP因为主机本身不需要做路由转发不需要放行无关流量。但 Docker 为了保证容器网络可用在启动阶段会执行类似iptables -P FORWARD ACCEPT的操作。这个动作单独说起不到什么决定作用可一旦你的规则脚本里没有强制指定 FORWARD 策略或者策略是后执行的就会被 Docker 覆盖掉。1.3 正确认识 DOCKER-USER 链它不是摆设很多人在网上看到“想限制容器流量就写 DOCKER-USER 链”但没完全理解这个链的价值。在 Docker 默认管理 iptables 的前提下你直接在 FORWARD 链里手动加规则规则顺序很容易被 Docker 接下来的操作打乱或者插入位置不对导致一直不生效。DOCKER-USER 链是 Docker 专门留给用户写自定义过滤规则的地方它的特点就是Docker 每次刷新自己的规则时不会清掉这个链里的内容并且会保证所有经过 Docker 相关转发路径的流量都会先经过 DOCKER-USER 链。所以如果你现阶段并不打算关闭 Docker 的 iptables 管理但又想限制某些容器地址的访问最稳妥的办法是在 DOCKER-USER 链里加规则而不是在 FORWARD 主链里硬刚。不过这里要提前打个预防针一旦你在后文按我的方案把 Docker 的 iptables 管理关掉了DOCKER-USER 链可能就不会再被自动创建了。手动补齐规则时就不要再指望有一个“既不会被清理又会自动生效”的现成链位需要自己规划规则插入位置。这是好多人在关闭 Docker 的 iptables 管理后踩坑的第一站。2. 从 daemon.json 下手全局关闭 vs 按网络关闭2.1 最直接的方案iptables 与 ip6tables 双关闭想阻止 Docker 自动修改主机的 iptables 规则最通用的做法是在 Docker 的配置文件里把iptables开关关掉。Linux 上 Docker daemon 的主配置路径是/etc/docker/daemon.json如果这个文件不存在你就直接新建一个。打开这个文件加入如下配置{ iptables: false, ip6tables: false }然后重启 Dockersystemctl restart dockeriptables和ip6tables两个字段的含义不同iptables管 IPv4 规则ip6tables管 IPv6 规则。如果你只关iptables而 Docker 又启用了 IPv6 相关网络那 ip6tables 里的 NAT/FORWARD 规则依然可能被 Docker 修改。最省心、最彻底的做法就是两个都置为 false。配置生效后你再用iptables -L -n查看会发现 DOCKER 链、DOCKER-ISOLATION-STAGE-1/2 这类链不再新增重启 docker 服务也不会再把 FORWARD 链默认策略改成 ACCEPT。这个方案对绝大多数单机 Docker 场景都够用也是下面所有手动配置的基础。2.2 全局关闭后先观察这三个现象配置完不要急着高兴关闭 Docker 的 iptables 管理并不等于“网络照旧只是防火墙干净了”。通常你会立刻遇到以下三种情况中的至少一种。第一种容器端口映射效果变得不可控。前面说过-p映射依赖 NAT 规则关掉后 Docker 不再帮你生成 DNAT外部访问宿主机端口是否还能转到容器取决于你的系统里是否还残留旧规则以及 docker-proxy 是否还在工作。同一套配置在不同发行版上的表现可能不一样甚至会出现 localhost 能访问、外网访问不通这种“半通”状态。别慌这不是玄学第三章会给你完整的手动规则补齐方法。第二种容器访问外网或宿主机网络时出现不通、半通的情况。因为 POSTROUTING 链上的 MASQUERADE 规则也需要你手动维护否则容器里的流量发不出去或者发出去之后回包到不了容器。第三种自定义 bridge 网络之间的隔离管理也需要你自己接管。Docker 不再自动创建 DOCKER-ISOLATION 链如果你对容器间隔离有硬性要求就得在自己的防火墙脚本里写相应规则。所以如果你只是想解决某个特定容器不要干扰 iptables而不是想完全接管整个 Docker 网络体系我更推荐按网络维度关闭也就是下面的方案。2.3 精细化控制让指定 bridge 网络不碰 iptablesDocker 的 bridge 驱动支持一个网络标签可以在创建网络时指定不要启用 iptables 管理。这个标签是com.docker.network.bridge.enable-iptables。新建网络时可以这样指定docker network create \ -o com.docker.network.bridge.enable-iptablesfalse \ mybridge这样创建出来的mybridgeDocker 不会为它自动生成端口映射规则、MASQUERADE 规则和隔离链。但问题在于Docker 对其他网络的规则管理仍然是开启的也就是说这台主机上若还有其他默认 bridge 网络它们依然会影响 FORWARD 链。所以这适合“某个网络必须走自己的防火墙逻辑其他网络保持 Docker 默认行为”的场景。如果容器已经跑在某个自定义网络里你没法在现有网络上直接改这个标签一般需要新建同名网络并迁移容器或者在主机侧的防火墙规则里给现有网段单独补规则。按网络关闭的方案比全局关闭更精细代价是很容易在 docker network 重构时漏掉配置反而不如全局关闭 自定义脚本来得清爽。我的建议是测试环境用按网络关闭去验证业务影响生产环境如果有完整防火墙基线直接全局关闭然后手动补齐网络规则一劳永逸。3. 关闭 iptables 后端口映射失效了手动补齐 NAT 与转发规则3.1 先搞清楚流量路径出网、入站、容器间手动补规则之前先有一个清晰的网络路径概念。容器网络流量主要分三条路径每条路径需要管的规则不同。容器访问外网也就是出网方向流量从容器网卡发到 docker0 或自定义 bridge 网卡再经过主机的路由表转发到物理网卡。这里有两个关键点第一主机的内核 IP 转发功能要开启否则流量在 FORWARD 链上就会被丢弃跟 iptables 规则无关第二POSTROUTING 链上要有为容器网段做的 MASQUERADE这样外部回包才能找到容器所在的主机。外部访问容器服务也就是入站方向流量会先从物理网卡进入 PREROUTING 链Docker 原本的 DNAT 规则会把目标地址改成容器 IP然后走 FORWARD 链转发到容器。关闭 Docker 管理后DNAT 丢了甚至 FORWARD 链策略如果不是 ACCEPT流量就会被丢在这个环节。容器间通信相对特殊。同一个 bridge 网络里的容器互通通常依赖二层链路也就是交换 MAC 地址不一定要过 iptables 的 FORWARD 链但如果内核参数net.bridge.bridge-nf-call-iptables为 1桥接流量还是会经过 iptables 过滤。不同网络之间的容器通信大多会被 FORWARD 链的规则管住。要记住即使 iptables 规则不报错也不代表所有流量都能通内核转发开关和数据包走向都可能是瓶颈。3.2 手动补最小可用规则集假设你的宿主机物理网卡名是eth0Docker 默认 bridge 网段是172.17.0.0/16。关闭 Docker 的 iptables 管理后至少需要这么几条规则才能让容器正常出网# 开启内核转发 sysctl -w net.ipv4.ip_forward1 # 允许来自 docker0 网段的流量转发到外部网卡 iptables -A FORWARD -i docker0 -o eth0 -j ACCEPT # 允许来自外部网卡的流量转发到 docker0 网段 iptables -A FORWARD -i eth0 -o docker0 -j ACCEPT # 容器出网时做 IP 伪装 iptables -t nat -A POSTROUTING -s 172.17.0.0/16 -o eth0 -j MASQUERADE如果要发布一个容器端口比如宿主机 8080 端口映射到容器172.17.0.2的 80 端口需要再加一条 DNAT 规则并且在 FORWARD 链上放行对应流量# 把发到宿主机 8080 端口的流量 DNAT 到容器 IP iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 172.17.0.2:80 # 放行目标为容器 IP 且目标端口为 80 的转发流量 iptables -A FORWARD -d 172.17.0.2 -p tcp --dport 80 -j ACCEPT这里有几个细节容易忽略。第一DNAT 规则放在 PREROUTING 链但如果你同时对该端口有防火墙 INPUT 链限制还要确保 INPUT 链放行了宿主机 8080 端口的入站流量否则数据包可能在进入本机前就被丢掉了。第二如果 FORWARD 链默认策略是 DROP上面两条 FORWARD 规则必须放在所有 DROP 规则之前用-I插入到链头比较保险。第三如果使用了自定义 bridge 网络且 IP 网段不是172.17.0.0/16要把规则里的网段和网卡名改成实际的。3.3 容器重建导致 IP 变化的自动化方案手动规则最大的问题不是写不对而是容器 IP 不固定。你开开心心写好了指向172.17.0.2的 DNAT 规则结果某天不小心把容器重新创建了一遍它的 IP 可能就变成了172.17.0.3规则立刻失效。所以生产环境里必须配合固定 IP 或者同步脚本。最简单的做法是在创建容器时就固定 IP。Docker 原生支持给容器指定静态 IP前提是该 IP 属于对应网络的地址范围而且没有被占用docker network create --subnet172.20.0.0/24 mybridge docker run -d --network mybridge --ip 172.20.0.10 --name myapp myapp-image之后手动 iptables 规则全部用172.20.0.10这个地址就不用担心重建导致 IP 漂移了。需要注意--ip只在容器创建时生效如果你的启动编排工具不允许固定 IP就要走脚本同步。如果你确实没法固定 IP可以写一个小脚本去自动刷新规则。核心思路是先通过docker inspect拿到容器当前 IP再清理旧的同端口 DNAT 规则最后插入新的 DNAT 规则。下面这个片段可以直接用 shell 实现CONTAINER_IP$(docker inspect -f {{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}} myapp) # 如果已有旧规则先删掉避免重复 iptables -t nat -C PREROUTING -p tcp --dport 8080 -j DNAT --to-destination $CONTAINER_IP:80 2/dev/null \ iptables -t nat -D PREROUTING -p tcp --dport 8080 -j DNAT --to-destination $CONTAINER_IP:80 iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination $CONTAINER_IP:80这个脚本建议结合容器生命周期事件来触发比如用docker events监听container start/restart事件或者在每次容器更新后手动执行。不用做得太复杂能保证“容器 IP 变了就去刷规则”这个逻辑闭环就可以了。4. 一次真实的排查FORWARD 策略从 DROP 变 ACCEPT 的问题定位与修复4.1 问题现场还原我曾在一台承担内部网关任务的测试机上处理过这个问题。系统上预先写好了一个防火墙脚本FORWARD 链默认策略明确是 DROP只放行指定网段之间的转发。某运维同学在这台机器上装了 Docker 并跑了一个内部管理容器隔天我检查iptables-save时发现 FORWARD 链策略变成了 ACCEPT同时多了一堆 DOCKER 链。当时第一反应是怀疑有人把防火墙脚本执行坏了。但回看脚本逻辑里面已经特意加了一句iptables -P FORWARD DROP而且要放在最后。按理说脚本只要重新执行一遍策略就会被修正回来。实际执行后策略确实恢复了但只要 Docker daemon 重启一次策略又变回 ACCEPT。这个“反复横跳”的现象让我确定问题出在 Docker 启动时对 iptables 的管理而不是脚本语法问题。4.2 逐步定位从现象到根因我把排查链路梳理出来你可以照着走一遍。先保存当前规则和一份启动 Docker 前的规则做对比。如果你已经重启过好几轮可以先把防火墙脚本里的规则存到一个干净的基准文件里iptables-save /tmp/iptables-baseline.rules systemctl restart docker iptables-save /tmp/iptables-after-docker.rules diff -u /tmp/iptables-baseline.rules /tmp/iptables-after-docker.rules执行 diff 后你大概率能看到几类变更FORWARD 策略从 DROP 变成 ACCEPT新增-N DOCKER、-N DOCKER-USER等链NAT 表新增 DOCKER 链和相关 DNAT 规则。这就已经能确认变更来自 Docker 了。如果还不够直接可以再缩小范围。执行iptables -t nat -L -n以及iptables -L DOCKER -n查看这些链的规则内容。Docker 生成的 DNAT 规则目标通常都会指向容器 IP 加端口若这些规则全部对应你正在运行的容器基本就坐实了 Docker daemon 是修改者。想从进程层面确认也行用ps -ef | grep docker找到 dockerd 进程再看/proc/PID/cmdline或者日志文件不过通常到这一步已经不需要再往下挖了。定位的重点是分清“防火墙脚本自己写坏了”和“外部程序接管了防火墙”前者只需要改脚本后者需要在配置层面关闭 Docker 的接管行为。4.3 修复方案与事后验证确认根源是 Docker 后我按第二章的方法修改了/etc/docker/daemon.json写入{ iptables: false, ip6tables: false }重启 Docker 后我重新执行iptables-save对比确认新的 DOCKER 链和 DNAT 规则不再出现FORWARD 链默认策略也保持在 DROP。然后又按第三章的方案手动补了三条规则允许docker0与eth0之间的 FORWARD 流量以及 POSTROUTING 链上的 MASQUERADE。容器里的服务因为只有一个端口需要暴露就单独手动加了 DNAT 和对应 FORWARD 放行。这里有一个很关键的验证细节不要只看容器是否启动成功而是要同时测两条链路。第一是容器访问外网在容器里执行ping 8.8.8.8或者访问一个外部域名第二是外部访问容器端口建议在宿主机外部找一个独立 IP 去访问而不要只在本机用curl localhost:8080验证。很多人在这个环节被 docker-proxy 迷惑本机访问通了就以为一切正常结果真正从其他机器访问时才发现 FORWARD 链路有问题。5. 更省心的替代路线host 网络、macvlan 与 DOCKER-USER 的正确姿势5.1 用 host 网络直接绕开 NAT如果你只是想在单机 Docker 上发布一个端口又不想手动管理 iptables最粗暴的思路是让容器直接用 host 网络docker run -d --network host myapphost 网络模式下容器共享宿主机的网络命名空间不存在 docker0 转发也不需要在 PREROUTING 链做 DNAT。应用直接监听宿主机端口防火墙规则和普通进程一样管理。但代价也很明显容器之间没有网络隔离端口冲突要靠你自己人肉保证多容器编排时 IP 也从“容器自己的 IP”变成了“宿主机 IP”很多依赖容器网络粒度的功能会受影响。所以 host 网络适合对端口安全性要求不高、单容器部署的场景不适合跑一整套微服务集群。5.2 用 macvlan 让容器直接出现在局域网macvlan 是另一个典型的绕开 iptables 的方案。容器在宿主机上创建虚拟网卡直接桥接到物理网络相当于把每个容器变成局域网里的独立“小主机”各自拥有独立 IP和宿主机在一个二层网络内。这样外部访问容器端口时不需要 Docker 去做 DNAT宿主机防火墙也不需要额外放行容器流量。macvlan 的代价是网络依赖更强。如果物理交换机、路由器配置了端口安全或 MAC 限制macvlan 容器可能会连不上网络宿主机和 macvlan 容器之间的通信也不同于普通 bridge部分网络拓扑下需要额外添加虚拟网卡才能互通。macvlan 适合按“每个容器一个独立 IP”这类需求来设计不适合只想快速发布端口的小规模场景。5.3 如果你仍然想让 Docker 管规则那就不要把规则写在 FORWARD 主链最后一个建议给那些决定不关闭 Docker 的 iptables 管理、但又想守住安全底线的朋友。既然 Docker 默认提供的 DOCKER-USER 链就是用来兼容自定义规则的那就把自定义过滤规则统一写进 DOCKER-USER 链。Docker 每次维护自己的规则时不会清空这条链也没有别的机制会覆盖它。比如你想限制所有容器访问某个网段iptables -I DOCKER-USER -s 172.17.0.0/16 -d 10.10.10.0/24 -j DROP这样做比直接操作 FORWARD 链稳定得多因为 Docker 在新增或删除自己规则时不会因为链不存在或顺序变化导致你的过滤逻辑失效。缺点是这些规则只能通过 iptables 手动管理容器网络变化频率越高越容易累积出陈旧规则需要定期同步和清理。我个人在实际操作中的习惯是这样如果这台机器只跑两三个容器、端口映射也不多就让 Docker 管 iptables我只在 DOCKER-USER 链里加必要的限制如果这台机器是一个边界设备或安全基线严格的主机那我直接全局关闭 Docker 的 iptables 管理把手动规则写进自己的防火墙脚本用配置管理工具统一推送。这样既能保住防火墙策略的确定性也不会让容器网络变成“状态不可查”的黑盒。另外再分享一个调试时很有用的小技巧。在确认 Docker 到底改了什么规则之前先执行一遍iptables-save保存现场再执行systemctl restart docker之后就很容易 diff 出变化。最小化复现环境比在复杂的生产环境里瞎猜要高效得多尤其在处理防火墙这类容易“复发”的问题时一份干净的规则文件比什么都管用。