🐧 UFW 与 libvirt 桥接网络冲突的终极解决方案

一、故障现象

1.1 客户报障

【紧急】宿主机升级后，所有 KVM 虚拟机网络中断
- 宿主机：Ubuntu 22.04 LTS
- 虚拟化：libvirt + KVM
- 网络模式：桥接网络（br0）
- 影响范围：生产环境 15 台 VM 全部无法通信
- 变更历史：系统更新后重启，UFW 自动启用

1.2 故障表现

# 宿主机 ping 虚拟机 - 通
ping 192.168.1.101  # ✅ 正常

# 虚拟机 ping 外网 - 不通
ping 8.8.8.8  # ❌ Request timeout

# 虚拟机之间互 ping - 不通
ping 192.168.1.102  # ❌ Request timeout

# 宿主机 UFW 状态
sudo ufw status verbose
# 输出：Status: active (默认 FORWARD 策略：DROP)

二、问题定位过程

2.1 第一步：确认网络拓扑

# 检查网桥状态
brctl show
# 输出：
# bridge name     bridge id               STP enabled     interfaces
# br0             8000.000c29123456       no              ens33
#                                                         vnet0
#                                                         vnet1

结论：网桥配置正常，虚拟机网卡已正确挂载到 br0。

2.2 第二步：检查防火墙规则

# 查看 UFW 规则
sudo ufw status numbered

# 查看 FORWARD 链默认策略
sudo iptables -L FORWARD -n -v
# 输出：
# Chain FORWARD (policy DROP 0 packets, 0 bytes)

关键发现：FORWARD 链默认策略是 DROP，桥接流量被阻断。

2.3 第三步：检查内核参数

# 查看桥接过滤参数
sysctl net.bridge.bridge-nf-call-iptables
# 输出：net.bridge.bridge-nf-call-iptables = 1

根因确认：bridge-nf-call-iptables = 1 表示桥接流量会经过 iptables 过滤，而 UFW 的 FORWARD 默认策略是 DROP，导致虚拟机通信被阻断。

三、问题根源分析

3.1 系统启动流程

系统启动流程：
┌─────────────────────────────────────────────────────────────┐
│  1. 内核启动                                                 │
│  2. UFW 服务启动（早期）                                      │
│     ├─ 尝试加载 bridge 模块 → ❌ 尚未加载                      │
│     └─ 尝试设置 bridge-nf-call-* 参数 → ❌ 失败/无效           │
│  3. 网络服务启动                                             │
│     └─ bridge 模块加载 → 内核参数恢复默认值 1                  │
│  4. libvirt 启动                                             │
│     └─ 创建网桥和虚拟机网卡                                   │
│  5. 虚拟机启动                                               │
│     └─ 桥接流量经过 iptables → 被 UFW DROP 策略阻断            │
└─────────────────────────────────────────────────────────────┘

3.2 为什么默认值会覆盖？

当 bridge 内核模块加载时，内核会将相关参数设置为默认值：

问题：UFW 在 bridge 模块加载前尝试设置这些参数，设置无效；模块加载后，默认值 1 覆盖了 UFW 的配置。

四、解决方案

4.1 步骤 1：修改 /etc/default/ufw

sudo vim /etc/default/ufw

找到这一行：

IPT_MODULES=""

改为：

IPT_MODULES="bridge"

作用：告诉 UFW 在启动时主动加载 bridge 内核模块，确保后续 sysctl 配置可以成功应用。

4.2 步骤 2：修改 /etc/ufw/sysctl.conf

sudo vim /etc/ufw/sysctl.conf

在文件末尾追加：

# 禁用桥接流量的 netfilter 过滤（解决 libvirt 桥接网络冲突）
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

作用：显式禁止桥接流量经过 iptables/netfilter 过滤。设置为 0 后，桥接层的数据包将直接转发，不再被宿主机防火墙规则检查。

4.3 步骤 3：重新加载 UFW 配置

sudo ufw reload

作用：使上述两个修改同时生效。

4.4 验证修复效果

# 验证 1：检查内核参数
sysctl net.bridge.bridge-nf-call-iptables
# 预期输出：net.bridge.bridge-nf-call-iptables = 0 ✅

# 验证 2：虚拟机 ping 外网（在虚拟机内执行）
ping 8.8.8.8
# 预期：✅ 正常通信

# 验证 3：重启后确认永久生效
sudo reboot
sysctl net.bridge.bridge-nf-call-iptables
# 预期输出：net.bridge.bridge-nf-call-iptables = 0 ✅

五、技术原理深入

5.1 为什么需要桥接过滤？

Linux 内核设计桥接过滤的初衷是安全：

• 传统桥接（无过滤）：流量直接转发，防火墙无法检查
• 桥接过滤（启用）：流量经过 iptables 检查，可应用防火墙规则

5.2 性能影响分析

六、经验总结

6.1 关键教训

• 系统更新后检查服务状态：Ubuntu 更新可能自动启用 UFW，生产环境需确认
• 虚拟化环境特殊配置：libvirt/KVM 需要调整默认防火墙行为
• 内核参数依赖加载顺序：bridge 模块必须在设置参数前加载
• 验证要覆盖重启场景：临时生效的配置不是真修复

6.2 一键修复命令

# 一键修复 UFW 与 libvirt 桥接冲突
sudo bash -c '
# 1. 修改 UFW 默认配置
sed -i "s/^IPT_MODULES=.*/IPT_MODULES=\"bridge\"/" /etc/default/ufw

# 2. 追加 sysctl 配置
cat >> /etc/ufw/sysctl.conf << EOF

# libvirt 桥接网络优化
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
EOF

# 3. 重新加载 UFW
ufw reload

# 4. 验证
echo "=== 验证结果 ==="
sysctl net.bridge.bridge-nf-call-iptables
'

七、扩展阅读

• Ubuntu Bug #573461 - 原始问题报告（2010 年）
• libvirt 网络文档
• UFW 官方文档