IP / CIDR 子网划分完全指南：从 /24 到 VPC 规划

CIDR 记号法 IP/N 中，N 代表前 N 位是网络地址，后 32-N 位可分配给主机。这种记号法比传统的「点分十进制」子网掩码更简洁易记。

例子：192.168.1.0/24 - /24 意味着前 24 位是网络部分，后 8 位是主机部分 - 子网掩码：255.255.255.0（前 24 位全是 1，后 8 位全是 0） - 可容纳主机数：2^8 - 2 = 254（减 2 是因为网络地址和广播地址不能分配给主机） - 网络地址：192.168.1.0，广播地址：192.168.1.255，可用主机：192.168.1.1-192.168.1.254

转换关系速查表： `` /8 → 255.0.0.0 → 1600 万主机 /16 → 255.255.0.0 → 6.5 万主机 /20 → 255.255.240.0 → 4094 主机 /24 → 255.255.255.0 → 254 主机 /25 → 255.255.255.128 → 126 主机 /26 → 255.255.255.192 → 62 主机 /28 → 255.255.255.240 → 14 主机 /30 → 255.255.255.252 → 2 主机（常用于点对点链接） /32 → 255.255.255.255 → 单个 IP（无法分配，但用于主机路由） ``

掌握这个映射关系很重要。面试中经常问「/25 网络能分多少主机」，快速反应的秘诀就是记住 2^(32-N) - 2 这个公式。二进制转换对于深层理解也很有帮助：/24 的最后 8 位都是 0，代表 256 个地址空间。

已知一个大网络，如何分割成若干小子网？核心思路是：用额外的位数来区分子网，剩余的位数分配给主机。

公式：要分 N 个子网，每个至少需要 K 个主机 - 要分 N 个子网，需多加 log2(N) 位 → 原掩码 +log2(N) - 每个子网至少 K 个主机，需保留 log2(K+2) 位给主机部分

实例详解：把 10.0.0.0/8 分成 4 个子网，每个约 1000 主机 - 4 个子网需要 log2(4)=2 位 → /8 +2 = /10 - 1000 主机需要 log2(1002)≈10 位 → /10 +10 = /20 - 四个子网具体分配： - 10.0.0.0/20（主机数：4094，地址范围 10.0.0.1-10.0.15.254） - 10.16.0.0/20（主机数：4094，地址范围 10.16.0.1-10.16.15.254） - 10.32.0.0/20（主机数：4094，地址范围 10.32.0.1-10.32.15.254） - 10.48.0.0/20（主机数：4094，地址范围 10.48.0.1-10.48.15.254）

验证原理：/10 允许 2^(32-10)=2^22 个 IP 地址，共 4194304 个。第三位从 0-63（64 个值），每个 /20 占 16 个值（2^4），64/16=4 恰好分成 4 个 /20 子网。这就是二进制的神奇之处。

RFC 1918 规定了三个私有地址段（内部网络专用，互联网上不路由）。选错了会在扩展时带来巨大麻烦。

• 10.0.0.0/8：最大，1600 万个 IP，拥有 256 个 /16 子网的空间，企业内网和大型云基础设施常用
• 172.16.0.0/12：中等，约 100 万个 IP，拥有 16 个 /16 子网，AWS 默认 VPC 常用
• 192.168.0.0/16：最小，6.5 万个 IP，拥有 256 个 /24 子网，家庭 WiFi 路由常用

补充：169.254.0.0/16（链路本地地址，DHCP 服务不可用时操作系统自动分配，用于应急）

企业选择建议： - 小公司（< 1000 人）：192.168.0.0/16 足够，分成 256 个 /24，每个 /24 有 254 个主机 - 中型公司（1000-10000 人）：172.16.0.0/12 较合适，拥有充足的扩展空间 - 大企业（> 10000 人）或需大量子网：10.0.0.0/8 是标准选择 - 多地部署时：以 /8 为基准，地域分配为 /16，可用区为 /24

关键陷阱：VPN 连接时，确保本地网络与远端 VPC 的私有地址段不重叠。例如公司内网用 10.0.0.0/8，阿里云 VPC 也用 10.1.0.0/16，两边就无法互通——这是网络规划最常见的坑。很多公司因为这个问题反复踩坑。

AWS 中一个 VPC 对应一个私有网络。多个 VPC 要通过 VPC Peering、Transit Gateway 或 VPN 相互连接。科学的 CIDR 规划可以避免将来的重构。

典型规划（跨地域大型项目）： `` 总体架构：10.0.0.0/8（公司总网段，保留 10.0-10.255） ├─ VPC-A（北京）：10.0.0.0/16（保留 10.0.0-10.0.255） │ ├─ 公有子网 A1：10.0.1.0/24（互联网网关、NAT Gateway） │ ├─ 公有子网 A2：10.0.2.0/24（负载均衡、跳板机） │ ├─ 私有子网 A3：10.0.10.0/24（应用服务、ECS） │ ├─ 私有子网 A4：10.0.11.0/24（应用服务副本） │ └─ 私有子网 A5：10.0.20.0/24（数据库、缓存） ├─ VPC-B（上海）：10.1.0.0/16（保留 10.1.0-10.1.255） │ ├─ 公有子网 B1：10.1.1.0/24 │ ├─ 私有子网 B2：10.1.10.0/24 │ └─ 私有子网 B3：10.1.20.0/24 ├─ VPC-C（广州）：10.2.0.0/16（保留 10.2.0-10.2.255） │ └─ ... └─ VPC-D（香港）：10.3.0.0/16 └─ ... ``

设计要点： - 每个地域的 VPC 用不同的第三位（0、1、2、3...），便于记忆和路由策略 - 单个 VPC 内部 /16 足够大多数场景（65536 - 2 = 65534 个可用 IP） - 同一 VPC 内不同子网用不同的第四位（子网掩码 /24），典型分配：1-9 公有，10-19 应用，20-29 数据库 - 预留空间：别把整个 /8 都分配完，留足将来扩展的余地（10.4-10.255 备用） - 公有子网数量：每个 /16 VPC 分 2-3 个 /24 公有子网足够（冗余） - 私有子网数量：根据应用部署数量定（一般 3-5 个 /24）

现实项目中经常遇到多层网络叠加的问题。阿里云 VPC 选了 172.16.0.0/12，本地 Docker 默认桥接网络用 172.17.0.0/16，两端主机无法直接通信。这是因为 172.17.0.0/16 被包含在 172.16.0.0/12 范围内！

1. ip route 或 route -n 查看本地路由表，找到 Docker 桥接网络的网关
2. docker network inspect bridge 查看 Docker 默认网络的 IP 范围
3. 阿里云控制台检查 VPC CIDR，看是否与 Docker 网络重叠
4. 若重叠，编辑 Docker daemon 配置（/etc/docker/daemon.json）改 bip 为其他段，如 192.168.0.1/16，然后 systemctl restart docker

完整的网络隔离方案： `` 公司内网（办公室）：10.0.0.0/8 VPC（云端）：172.16.0.0/12 Docker 本地桥接：192.168.0.0/16 Kubernetes Pod 网络：10.100.0.0/8（pod CIDR） Kubernetes Service 网络：10.200.0.0/8（service CIDR） ``

三个网络段完全不重叠，各司其职。如果还有 VPN 客户端拨号，再加一个 OpenVPN 网络 172.31.0.0/16，确保也不重叠。

当网络数量增多时，路由表会变得巨大。超网是将多个小网络合并成一个大网络的技术，用于简化路由。

例子：如果有以下四个 /24 网络： - 10.0.0.0/24 - 10.0.1.0/24 - 10.0.2.0/24 - 10.0.3.0/24

可以合并为一个 /22 网络 10.0.0.0/22（因为 4 个 /24 = 2^2 = /22）。这样路由表就只需一条规则指向这个 /22，而不是四条分别指向每个 /24。

聚合条件：待合并的网络必须连续，且数量是 2 的幂次（2、4、8、16...）。

在企业中的应用： - BGP 路由中，运营商通常聚合多个 /24 为 /16 对外通告，减少全球路由表大小 - 云中的安全组规则：把多个内部 /24 聚合为 /16 写入出站规则，减少规则数量 - VPN 部署：总部 10.0.0.0/16 可以聚合为 10.0.0.0/16 通过 IPsec 隧道，分支机构只需一条黑洞路由

IPv6 用 128 位地址，理论上永不枯竭（3.4×10^38 个）。但由于设备与网络支持参差不齐，全球迁移缓慢，预计还需 5-10 年才能广泛部署。

IPv6 CIDR 记号：同样的逻辑但地址更长。例如 2001:db8::/32 是公共文档前缀。实际分配：一个运营商可能分到 2001:db8:1234::/48，然后分配给企业 2001:db8:1234:1::/64（一个子网）。

过渡方案： - 双栈（Dual Stack）：IPv4 与 IPv6 并行，最稳妥。主机同时有 IPv4 和 IPv6 地址 - 4in6 隧道：IPv4 流量封装在 IPv6 包内跨越纯 IPv6 网络 - NAT64：IPv6 客户端通过代理访问 IPv4 服务

现状（2026）：大多数企业还在纯 IPv4。只有谷歌、Facebook 等巨头与部分运营商开始大规模部署 IPv6。中国运营商对 IPv6 的支持仍在试点阶段。除非你的项目面向运营商或国际业务，暂时不用急着深入学 IPv6——但要知道它的存在和基本概念。

真实项目中的血泪教训：

错误 1：VPC 间地址重叠。AWS 账号 A 和账号 B 的 VPC 都用 10.0.0.0/16，后来要 Peering 就完蛋。需要提前在组织层面制定统一的 CIDR 分配规则（如账号 A 用 10.0.0.0/16-10.0.255.0/24、账号 B 用 10.1.0.0/16-10.1.255.0/24）。最好在 wiki 或 Confluence 里维护一个全局 CIDR 分配表，每次新建 VPC 前检查一遍。

错误 2：子网划分过细。一个 /25 子网只有 126 个 IP，看起来不浪费，但 AWS 实际可用更少（因为路由网关、DHCP 服务等保留了几个）。建议：团队少于 50 人用 /24；少于 250 人用 /23；否则频繁加子网很麻烦，而且浪费管理员时间。

错误 3：忘记保留地址。IPv4 /25 子网 10.0.1.0/25：主机范围是 10.0.1.1-10.0.1.126，不是 10.0.1.0-10.0.1.127！前者 10.0.1.0 是网络地址，后者 10.0.1.127 是广播地址，都不能分配给主机。这个错误导致过多次故障。

错误 4：跨地域时没规划好路由。VPC 多地扩展时，如果没有清晰的 CIDR 分层设计（公司级 /8、地域级 /16、可用区级 /24），后续 BGP 路由和故障排查会一团糟。最佳实践是从一开始就按这个结构规划，即使当时只有一个地域。

错误 5：忽视文档。网络规划必须文档化。用 Excel 或 Confluence 维护一张 CIDR 分配表，包括网络名称、用途、分配人、分配日期、备注。否则 6 个月后没人记得 10.42.0.0/16 是干什么的。

最佳实践清单： - 制定组织级的 CIDR 分配政策 - 维护全局 CIDR 分配表（定期审查） - 新建子网前检查是否与其他网络重叠 - 预留 20-30% 的地址空间以备后用 - 用 /24 作为最小可用子网（除非是点对点链接用 /30） - 定期检查路由表是否有冗余或错误条目