在云计算时代，网络故障排查变得前所未有的复杂。最近在 Oracle Cloud (OCI) 上部署宝塔面板时遇到的“公网无法访问”问题，典型地反映了云原生双层防火墙模型带来的认知困境。本文以此案例为切入点，深度解析云防火墙与系统防火墙的冲突根源及最佳实践。
一、案例复盘：从现象到本质
现象：
– OCI 安全组 (NSG/Security List) 已放行所有端口。
– 宝塔面板进程正常，监听 0.0.0.0:22558。
– 本地 curl 127.0.0.1 正常，但 curl 公网 IP 报错 No route to host。
– 浏览器访问超时。
本质：
流量通过了云厂商的网络层，但在进入操作系统协议栈的最后一跳，被 netfilter/iptables 规则 DROP。
二、云原生双层防火墙模型
现代公有云 (AWS, OCI, Azure) 均采用双层防御体系：
1. 第一层：云防火墙 (Cloud Firewall)
- 实现位置： Hypervisor 层或虚拟交换机层。
- 配置方式： 安全组 (Security Group), NSG, ACL。
- 特点： 有状态 (Stateful)，默认拒绝入站，允许回包。
2. 第二层：主机防火墙 (Host Firewall)
- 实现位置： Guest OS 内核 (iptables/nftables)。
- 配置方式： UFW (Ubuntu), firewalld (CentOS), iptables 手动。
- 特点： 无状态 (默认)，规则复杂，易与云防火墙冲突。
冲突根源： 很多运维人员只配置了第一层，认为“云安全组放行=网络通”，忽略了第二层默认策略往往是 DROP。
三、为什么 Ubuntu 默认开启 UFW？
Ubuntu 从 10.04 开始默认集成 UFW (Uncomplicated Firewall)，旨在为物理机或无云防火墙环境提供基础防护。但在公有云场景下，这导致了：
- 冗余防护： 云安全组已提供网络隔离，UFW 显得多余。
- 规则冲突： 云安全组动态变化时，UFW 静态规则可能成为瓶颈。
- 排查困难： 如本次案例，现象极具迷惑性（本地通，公网不通）。
四、最佳实践：公有云该不该关 UFW？
在社区和业界，对此有两种观点：
观点 A：保留 UFW (纵深防御)
理由： 即使云安全组配置错误，UFW 仍能提供最后一道防线。适合对安全要求极高的金融/政企场景。
观点 B：关闭 UFW (简化架构)
理由：
– 云厂商隔离已足够： OCI/AWS 的网络安全由硬件卸载，性能和安全性强于软件防火墙。
– 减少复杂度： 避免“两层皮”导致的规则不一致。
– 兼容性好： Docker, K8s, FRP 等工具需要动态操作 iptables，UFW 常导致端口映射失败。
结论： 对于 95% 的中小企业和个人开发者，建议关闭 UFW，完全依赖云安全组。
五、决策矩阵
| 场景 | 建议 | 理由 |
|---|---|---|
| 公有云 (OCI/AWS/Azure) | 关闭 UFW | 云防火墙已足够，避免冲突 |
| 私有云/物理机 | 开启 UFW | 无云防火墙，需系统层防护 |
| 混合云 | 按需开启 | 本地节点开启，云上节点关闭 |
| 运行 Docker/K8s | 必须关闭 | 避免 iptables 规则冲突导致网络不通 |
六、标准化修复流程
一旦确认是 UFW 问题，执行以下标准化操作：
# 1. 停止服务
systemctl stop ufw
systemctl disable ufw
# 2. 禁用防火墙
ufw disable
# 3. 清洗 iptables 规则 (防止残留)
iptables -F && iptables -X
iptables -t nat -F && iptables -t nat -X
# 4. 设置默认策略
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT总结
云计算改变了运维的边界。在云原生时代，理解“云防火墙”与“主机防火墙”的边界至关重要。对于大多数场景，做减法（关闭 UFW���比做加法（双层配置）更明智。
更多云原生架构深度分析：https://mjj.728.hk/