Docker overlay 加密失效深度剖析：CVE-2026-115538 firewalld 重载导致 IPsec 规则丢失与生产加固实战

导语：Docker overlay 加密失效并非配置疏忽，而是 Moby overlay 网络驱动在 firewalld 重载后无法恢复 iptables 规则所引发的系统性安全缺陷——CVE-2026-115538 以 CVSS 7.0 的高危评级，暴露了加密 overlay 网络在防火墙动态变更场景下的静默降级风险。本文以一线架构师视角，拆解 D-Bus 信号缺失的根因链路，给出可落地的检测、缓解与加固方案。

一、Docker overlay 加密失效：一个被低估的高危静默降级

CVE-2026-115538 的核心描述非常克制：Moby 的 overlay 网络驱动在 firewalld 删除加密 overlay 网络的 iptables 规则后，不会主动恢复它们。与其他 Docker Engine 网络组件不同，overlay 驱动不通过 D-Bus 处理 firewalld 的 reload 或 start 信号。缺失的规则直接导致两个后果：出站 VXLAN 数据报绕过 IPsec 加密，以及入站明文 VXLAN 流量的防护被移除。

更危险的是它的“静默性”：dockerd 不会记录任何日志，该状态会一直持续，直到加密网络的最后一个本地 endpoint 被移除并重新添加，或者 dockerd 重启。每一次后续的 firewalld 事件都会重复触发该条件。对于依赖加密 overlay 网络做跨主机安全通信的 Swarm 集群而言，这意味着一次例行防火墙重载，就可能让加密链路在无人察觉的情况下退化为明文传输。

flowchart TD
    subgraph 触发层 ["防火墙事件触发层 (Firewalld Event Tier)"]
        A["firewall-cmd --reload / 服务重启"] --> B["firewalld 清空并重建 iptables 链"]
    end
    subgraph 信号层 ["D-Bus 信号分发层 (Signal Dispatch Tier)"]
        B --> C{"D-Bus Reloaded 信号广播"}
        C --> D["bridge / host 驱动: 监听并重建规则"]
        C --> E["overlay 驱动: 未注册监听, 静默忽略"]
    end
    subgraph 失效层 ["加密规则缺失层 (Rule Loss Tier)"]
        E --> F["IPsec ESP 放行规则丢失"]
        E --> G["明文 VXLAN 4789 拦截规则丢失"]
    end
    subgraph 影响层 ["数据面影响层 (Data Plane Impact)"]
        F --> H["出站 VXLAN 绕过 IPsec 明文外发"]
        G --> I["入站明文 VXLAN 被接受"]
        H --> J["跨主机通信静默降级, 无日志"]
        I --> J
    end
    subgraph 恢复层 ["人工恢复层 (Manual Recovery Tier)"]
        J --> K["移除并重建最后一个本地 endpoint"]
        J --> L["重启 dockerd"]
    end
  

二、根因拆解：为什么只有 overlay 驱动“听不见” firewalld

2.1 Docker 网络组件的 D-Bus 监听矩阵

Docker Engine 的网络子系统并非铁板一块。bridge、host 等驱动在启动时会向 firewalld 注册 D-Bus 监听，当 firewalld 发出 Reloaded 信号时，这些驱动会重新下发自己所需的 iptables 规则。而 overlay 驱动的加密规则（IPsec ESP 放行、VXLAN 明文拦截）是在网络创建或 endpoint 加入时一次性写入的，没有纳入 D-Bus 信号驱动的重建流程。

2.2 缺失的两条关键规则

加密 overlay 网络依赖两组 iptables 规则维持安全边界：其一是放行 IPsec ESP 协议流量，保证 VXLAN 封装后的数据报能走加密通道；其二是拦截 4789 端口的明文 VXLAN 流量，防止攻击者注入或窃听。firewalld 重载会清空自定义链，而 overlay 驱动不会重建，于是加密边界同时从“出”和“入”两个方向被打开。

三、影响面评估：谁真正暴露在风险中

并非所有 Docker 用户都受影响。触发条件需要同时满足三点：使用 Swarm 模式或手动创建 encrypted overlay 网络、宿主机运行 firewalld 并发生过 reload/start、以及跨主机存在 overlay 通信。满足条件的场景主要集中在政企私有云、金融隔离区与混合云 Swarm 集群。

• 直接暴露：跨主机 VXLAN 流量以明文传输，违反等保与数据不出域的合规要求。
• 攻击面扩大：入站明文 VXLAN 被接受，攻击者可在同网段伪造 VXLAN 帧注入 overlay 网络。
• 可观测性盲区：dockerd 无日志，常规容器监控无法发现，平均发现时间可能以周计。
• 重复触发：每次 firewalld 事件都会重置状态，人工修复后仍可能再次失效。

四、检测与应急：三步确认你的集群是否已降级

4.1 检查加密 overlay 网络的 iptables 规则是否存在

#!/usr/bin/env bash
# 检测 encrypted overlay 网络的 IPsec / VXLAN 规则是否完整
set -euo pipefail

NETWORKS=$(docker network ls --filter driver=overlay -q)
FAIL=0

for net in $NETWORKS; do
  encrypted=$(docker network inspect "$net" --format '{{ index .Options "encrypted" }}' 2>/dev/null || true)
  if [ "$encrypted" != "true" ]; then
    continue
  fi

  esp_rules=$(iptables-save | grep -c "$net.*esp" || true)
  vxlan_drop=$(iptables-save | grep -c "$net.*4789" || true)

  if [ "$esp_rules" -eq 0 ] || [ "$vxlan_drop" -eq 0 ]; then
    echo "[CRITICAL] network=$net encrypted=true 但 IPsec/VXLAN 规则缺失 (esp=$esp_rules, vxlan=$vxlan_drop)"
    FAIL=1
  else
    echo "[OK] network=$net 规则完整"
  fi
done

exit $FAIL

4.2 验证 VXLAN 是否已走明文

在跨主机通信期间抓包，若看到 4789 端口存在未封装的 VXLAN 载荷且无 ESP 头，即可确认加密已失效。建议在维护窗口执行，避免影响生产流量。

# 1. 抓包确认 VXLAN 是否明文（观察是否有 ESP 头）
tcpdump -i any -nn -c 50 'udp port 4789' -w /tmp/vxlan.pcap

# 2. 查看当前 overlay 相关 iptables 规则
iptables-save | grep -E '4789|esp'

# 3. 应急恢复：移除并重建最后一个本地 endpoint（会短暂中断该 endpoint）
#    先找到目标网络上的本地 endpoint
docker network inspect  --format '{{range .Containers}}{{.Name}} {{end}}'
#    断开并重新连接一个容器
docker network disconnect  
docker network connect  

# 4. 或重启 dockerd（影响该节点全部容器网络，谨慎）
systemctl restart docker

五、生产加固：从临时缓解到架构级闭环

5.1 短期缓解：避免 firewalld 无感重载

在官方修复落地前，最直接的手段是降低 firewalld 重载频率，并在每次重载后触发规则校验。可将 firewalld 的 reload 纳入变更流程，重载后自动执行 4.1 的检测脚本，失败则告警并触发 endpoint 重建。

5.2 中期方案：用 systemd 钩子补齐规则重建

为 firewalld 服务添加 ExecStartPost 或独立的 path/timer 单元，在 firewalld 启动或重载后自动重建 overlay 加密规则。规则内容可从 docker network inspect 的 Options 推导，或直接固化到配置管理模板中。

[Unit]
Description=Restore Docker encrypted overlay iptables rules after firewalld reload
After=firewalld.service docker.service

[Service]
Type=oneshot
ExecStart=/opt/scripts/check-overlay-ipsec-rules.sh

[Install]
WantedBy=multi-user.target

5.3 长期架构决策：加密链路的可验证性

CVE-2026-115538 给出的架构教训是：安全边界不能依赖“驱动自动兜底”的假设。建议在集群层面引入持续校验——将 overlay 加密规则纳入 Prometheus 自定义指标或安全基线巡检，任何规则缺失在 5 分钟内触发告警。对于强合规场景，可评估用 WireGuard 等独立加密层替代 overlay 内置 IPsec，将加密责任从 Docker 网络驱动中解耦。