Oracle OCI 上的 Proxmox VE 双栈网络重构：SDN 分段、独享公网 IP 与可维护运维

本文记录 2026 年 9 月在 Oracle Cloud Infrastructure（OCI）ARM64 Proxmox VE 主机上实际落地并验证的最终方案。文章中的公网地址、主机名和可识别前缀已脱敏，私网结构保留为可复用示例。

一、最终目标

这次调整追求的是长期稳定和容易维护：

普通 LXC 使用 IPv4 SNAT 出网，同时保留原生 IPv6。
需要独立公网入口的 LXC 直接使用 OCI 分配的 IPv4 和 IPv6。
每个容器只保留一块网卡和一组默认路由。
地址全部静态配置，不引入 DHCP、IPAM 或 Host-Managed。
不增加路由虚拟机、自定义同步器、Hookscript 或额外 NAT 服务。
PVE 宿主机与容器分别维护自己的防火墙职责。

最终只保留两张 PVE SDN 网络：guestnet 和 pubnet。

二、最终拓扑

OCI VCN
   │
   └── enp0s6（宿主机通过 OCI DHCP/RA 联网）
          │
          ├── guestnet / localnet
          │      └── 普通 LXC：静态 IPv4 + 静态 IPv6
          │
          └── pubnet / pubzone
                 └── 独享公网 LXC：静态 IPv4 + 静态 IPv6

网络	用途	IPv4	IPv6	NAT
`guestnet`	普通双栈容器	`10.20.0.0/24`	OCI 路由的 /80 前缀	仅 IPv4 SNAT
`pubnet`	独享公网容器	OCI 路由的 /28 私网段	OCI 路由的 /120 前缀	无

原有的 mgmtnet 已删除。容器数量很少且不会频繁变动，因此单独维护管理网、DHCP 和 IPAM 只会增加状态和排障路径。

三、guestnet：普通双栈网络

guestnet 对应 SDN Zone localnet。

IPv4 网段：10.20.0.0/24
IPv4 网关：10.20.0.1
IPv4 出口：由 PVE SDN SNAT 到宿主机主 VNIC 地址
IPv6：使用 OCI 分配并路由到宿主机的 /80 前缀
IPv6 网关：前缀内的 ::1
IPv6 出口：原生路由，不做 NAT
地址分配：全部静态填写

普通容器只需要一块连接 guestnet 的 eth0。IPv4 和 IPv6 默认路由都通过这块网卡，不会出现多网卡抢默认路由的问题。

以 CT101 为例：

eth0 → guestnet
IPv4 → 10.20.0.24/24，网关 10.20.0.1
IPv6 → OCI /80 前缀中的固定地址，网关为该前缀的 ::1

宿主机应只存在一条针对 10.20.0.0/24 的 SNAT 规则。

四、pubnet：独享公网网络

pubnet 对应 SDN Zone pubzone，用于需要固定公网入口的容器。

OCI 侧为它准备：

一个路由到 PVE 主 VNIC 的私网 /28；
一个映射到容器私网地址的 Reserved Public IPv4；
一个路由到 PVE 主机的 IPv6 /120 前缀；
已关闭主 VNIC 的源/目的检查。

PVE 负责充当该路由子网的网关，不对 pubnet 做 DNAT 或 SNAT。

以 CT100 为例：

eth0 → pubnet
IPv4 → /28 中的固定地址，网关为 PVE 的 pubnet IPv4
IPv6 → /120 中的固定地址，网关为 PVE 的 pubnet IPv6

CT100 的 IPv4 和 IPv6 默认路由都走 eth0。公网 IPv4 的一对一映射由 OCI VNIC 维护，IPv6 直接端到端路由。

如果 CT100 需要反向代理 PVE Web，可以直接访问 pubnet 网关的 TCP 8006，不需要再增加管理网卡。

五、为什么删除 mgmtnet、DHCP 和 IPAM

三张网络和自动地址管理适合容器经常创建、删除或批量扩容的环境。本机容器数量少、地址长期固定，自动化层反而带来更多维护点：

PVE IPAM 中的租约；
dnsmasq 的动态配置和 ethers 记录；
Host-Managed 地址；
多块网卡和多个默认路由；
删除容器后可能遗留的租约或 MAC 记录。

调整后，每个容器只有一块网卡，地址直接写在 LXC 配置中。新增容器时，从维护清单中选择未占用的 IPv4 和 IPv6 即可。

SDN dnsmasq 已停用，旧配置已归档，不再参与运行。

六、OCI 侧配置原则

OCI 只负责云网络的可达性：

主 VNIC 保留 OCI DHCP 和 IPv6 RA。
为独享公网容器配置 Secondary Private IPv4 和 Reserved Public IPv4 映射。
将 guestnet 和 pubnet 使用的 IPv6 前缀路由到 PVE 主 VNIC。
对需要由 PVE 转发的 VNIC关闭源/目的检查。
IPv4 和 IPv6 默认路由指向 Internet Gateway。
安全列表或 NSG 只开放实际需要的协议和端口。
IPv6 必须允许必要的 ICMPv6，否则邻居发现和路径 MTU 可能异常。

OCI 安全列表、PVE 防火墙和容器防火墙各自承担不同职责，不需要在三层重复实现 NAT。

七、防火墙的实际分工

PVE 宿主机

PVE 数据中心防火墙处于启用状态，节点防火墙服务正常运行。节点入站策略为默认拒绝，只允许管理所需的 ICMP/ICMPv6、SSH、SPICE 和 PVE Web 端口。

这组规则保护的是 PVE 宿主机本身。

CT100：由容器自行维护

CT100 的 PVE 网卡参数设置为 firewall=0，这是有意设计。

它的 veth 直接接入 pubnet，不经过 PVE 为容器建立的防火墙桥。CT100 内部由 1Panel 和 iptables-nft 规则维护 SSH、Web、邮件以及 Docker 转发端口。

即使 /etc/pve/firewall/100.fw 文件仍然存在，在 firewall=0 时也不会应用。关闭 CT100 的 PVE 容器防火墙不会影响 PVE 节点防火墙。

CT101：已接入 PVE 防火墙框架

CT101 的网卡设置为 firewall=1，流量会经过 fwbr101i0。

但 firewall=1 只表示接入 PVE 的容器防火墙路径。若没有 CT101 自己的防火墙规则文件，就不会自动产生端口白名单或默认拒绝策略。需要限制 CT101 时，应在 PVE Web 中为 CT101 明确设置入站策略和允许规则。

八、迁移后的验证

迁移完成后已验证：

CT100 和 CT101 均正常启动；
两台容器的 IPv4、IPv6 和 DNS 正常；
guestnet 只有一条 IPv4 SNAT；
pubnet 没有 IPv4 或 IPv6 NAT；
CT100 的 Docker 服务全部启动；
CT100 的 IPv4/IPv6 Web、SSH 和邮件服务可达；
CT101 可以通过 IPv6 访问；
CT100 到 PVE Web 的反向代理正常；
PVE 节点防火墙规则已加载并产生实际匹配计数；
宿主机无需重启。

九、日常维护清单

修改网络、升级 PVE 或重启宿主机后，检查：

guestnet 和 pubnet 两张 VNet 是否存在。
每个容器是否只保留预期的一块网卡。
LXC 配置中的静态 IPv4、IPv6 和网关是否正确。
guestnet 是否只有一条 IPv4 SNAT。
pubnet 是否没有 NAT。
OCI VNIC 的 Secondary IP、公网映射和源/目的检查是否正确。
PVE 节点防火墙服务和默认拒绝策略是否仍然生效。
CT100 内部防火墙与 Docker 发布端口是否符合业务需求。
CT101 如需限制入站，是否已配置专属 PVE 防火墙规则。
从外部网络分别验证 IPv4 和 IPv6 的必要业务端口。

十、结论

最终方案的职责很清楚：

OCI 提供公网映射和路由；
PVE SDN 提供 guestnet 与 pubnet 两个网络；
guestnet 的 IPv4 使用 SNAT，IPv6 原生路由；
pubnet 为指定容器提供独享双栈入口；
容器使用静态地址，每个容器只有一块网卡；
PVE 防火墙保护宿主机，并可按需保护启用容器防火墙的 LXC；
CT100 明确由容器内部维护防火墙；
不使用 DHCP、IPAM、Host-Managed、同步脚本或 Hookscript。

对少量、长期固定的容器来说，这套结构比三网卡和自动地址管理更直观，也更容易在故障时判断问题位于 OCI、PVE 还是容器内部。