4. IP地址规划与子网设计
混合云VPC互联工程中，IP地址规划是最先落地、也最难返工的一环。物理专线、VPN隧道、云企业路由器、对等连接一旦按某个网段建立路由，后续再改地址往往意味着重建连接、迁移实例、重写安全策略。因此本章的核心不是“怎么划子网”，而是“怎么在多个云、多个IDC之间划出一套不冲突、可聚合、可扩展、可NAT兜底的地址体系”。
一、CIDR：把地址规划变成可计算的数学问题
CIDR（无类别域间路由）用“网络前缀/长度”表示一个地址块，例如 10.20.0.0/16。前缀长度决定可用地址数：主机位数 = 32 − 前缀长度，可用主机地址 = 2^主机位数 − 2（扣除网络地址与广播地址）。云厂商VPC通常还会额外保留每个子网的前几个地址（网关、DNS、保留地址），例如AWS每个子网保留5个地址，因此在云上做子网容量计算时不能只按 −2 估算。
规划时建议先确定“地址块层级”，再逐层切分：
- 顶层：为每个云区域、每个IDC分配一个 /16 或 /14 的“地址池”，例如阿里云华东1用 10.10.0.0/16，腾讯云广州用 10.20.0.0/16，自建IDC用 10.30.0.0/16。
- 中层：在地址池内按业务域或环境切 /20 或 /22，例如生产 /20、测试 /22、管理 /24。
- 底层：在环境内按可用区切子网，例如 10.10.0.0/20 再切为 10.10.0.0/24、10.10.1.0/24、10.10.2.0/24。
一个常见的教学示例：某企业规划三个云上VPC与一个IDC互联，地址分配如下表。表中参数为示例假设，用于说明规划方法，不代表任何真实环境实测值。
| 位置 | 地址池 | 用途 | 可聚合前缀 |
|---|---|---|---|
| 阿里云 华东1 | 10.10.0.0/16 | 生产VPC | 10.10.0.0/16 |
| 腾讯云 广州 | 10.20.0.0/16 | 生产VPC | 10.20.0.0/16 |
| AWS 新加坡 | 10.40.0.0/16 | 灾备VPC | 10.40.0.0/16 |
| 自建IDC 北京 | 10.30.0.0/16 | 核心数据库 | 10.30.0.0/16 |
这样做的价值在于：跨云路由表里只需要写 10.10.0.0/16、10.20.0.0/16、10.30.0.0/16、10.40.0.0/16 四条聚合路由，而不是几十条 /24 明细路由。聚合路由减少路由条目、降低收敛时间，也减少人为写错的机会。
二、地址重叠：混合云互联最常见的“隐形炸弹”
地址重叠指两个待互联的网络使用了相同或包含关系的网段。例如IDC使用 10.10.0.0/16，而某云VPC也使用 10.10.0.0/16，两者建立对等连接或专线后，路由表无法判断 10.10.1.5 到底在本地还是对端，结果就是部分流量被黑洞、部分流量走错路径。重叠有三种典型形态：完全相同、一方包含另一方、部分交叉。其中“包含”最隐蔽，因为表面看前缀不同，实际路由会按最长前缀匹配把流量导向错误方向。
处理重叠有三条路径：
- 改地址：最彻底，但成本最高，适合新规划阶段或业务尚未大规模上线时。
- NAT：不改地址，通过源NAT或目的NAT把重叠网段映射成唯一地址，适合无法改地址的存量系统。
- 隔离：不建立直接路由，通过代理、网关或应用层转发，适合少量特定服务互通。
三、NAT策略：重叠场景下的地址翻译设计
NAT在跨云互联中主要解决两类问题：一是地址重叠，二是私网地址不想暴露给对端。常见策略有源NAT（SNAT）和目的NAT（DNAT）。
以IDC 10.10.0.0/16 与云VPC 10.10.0.0/16 重叠为例，可以在云侧网关或IDC侧防火墙上配置双向NAT：
# 示例：IDC侧访问云VPC时的目的NAT映射（示例参数）
# 云VPC真实地址 10.10.1.10 映射为 192.168.100.10
# IDC侧路由：10.10.1.0/24 -> 192.168.100.0/24
# 云侧网关：目的地址 192.168.100.10 -> 10.10.1.10
# 云VPC访问IDC时的源NAT映射
# IDC真实地址 10.10.2.20 映射为 192.168.200.20
# 云侧路由：10.10.2.0/24 -> 192.168.200.0/24
# IDC侧网关：目的地址 192.168.200.20 -> 10.10.2.20设计NAT策略时要明确三件事：谁做NAT（云网关、IDC防火墙还是专线CPE）、NAT方向（源还是目的）、映射地址池（必须与两端都不重叠）。映射地址池建议单独规划，例如 192.168.100.0/24 和 192.168.200.0/24，不要从已有业务网段里临时借用。
NAT的代价也要提前评估：源IP被改写后，对端日志、审计、访问控制列表看到的都是NAT地址，排障时难以定位真实来源；某些协议（如IPsec、SIP、FTP主动模式）在NAT后需要ALG或额外配置。因此NAT应作为兜底手段，而不是首选方案。
四、跨云地址管理：把规划变成可维护的台账
跨云地址管理的关键是“单一事实来源”。建议维护一份地址分配台账，至少包含：地址块、所属云/IDC、VPC/子网ID、用途、负责人、状态、是否与其他网段重叠、NAT映射关系。台账不必复杂，但必须随变更同步更新，否则半年后没人说得清 10.10.0.0/16 到底分给了谁。
在工程实践中，还可以用IPAM（IP地址管理）工具或云厂商自带的地址管理能力做自动分配与冲突检测。无论用工具还是表格，判断标准是一致的：任意两个已分配地址块之间，要么完全不相交，要么有明确的NAT映射关系，不能存在“看起来不重叠但路由会打架”的模糊地带。
回到工程落地，建议把地址规划拆成四个可检查的动作：第一，为每个云区域和IDC分配独立地址池，并预留至少50%扩展空间；第二，在地址池内按环境、可用区、业务域逐层切分，子网大小按实际主机数上浮一档；第三，互联前做一次全量重叠检测，包含关系也要查；第四，对确认重叠且无法改地址的网段，设计NAT映射并记录在台账中。做到这四点，跨云网络在地址层面就具备了可扩展、可排障、可审计的基础。