3、网络隔离基础：VPC/虚拟网络设计、子网划分与路由策略、安全组与网络ACL
聊到多云安全，网络隔离是绕不开的第一道防线。说白了，云上的网络跟传统机房最大的区别是什么？是「软件定义一切」。你不再需要去机房跳线、插网线，但你需要用代码和配置来定义你的网络边界。
我个人习惯把网络隔离比作「盖房子」：VPC 就是你的宅基地，子网就是不同的功能区（卧室、客厅、厨房），路由策略就是走廊和门，安全组和网络 ACL 就是每个房间的门禁和小区保安。嗯，这个比喻虽然老套，但很管用。
3.1 VPC/虚拟网络设计：你的云上宅基地
VPC（虚拟私有云）是所有网络隔离的基础。你在云上申请一个 VPC，就等于圈了一块完全属于你的、逻辑隔离的网络空间。在这个空间里，你可以自由定义 IP 地址段、划分网段、配置路由。
设计 VPC 时，我建议你重点关注三个维度：
- CIDR 块规划：别贪大，也别太小。我见过有人直接开一个 /8 的网段，结果后面想跟本地 IDC 做专线互联时，发现 IP 地址重叠了，那叫一个头疼。一般建议生产环境用 /16 或 /20，留足扩展空间。
- 多 Region 多 AZ 设计：如果你做多云，每个云厂商的 Region 之间天然隔离。但同一个 Region 内，我建议至少用两个可用区（AZ）。为什么？因为 AZ 之间是物理隔离的，一个 AZ 挂了，另一个还能扛着。
- 环境隔离：我习惯把开发、测试、生产环境放在不同的 VPC 里。虽然可以用同一个 VPC 加子网隔离，但说实话，VPC 级别的隔离更彻底，误操作的风险更低。
核心原则：VPC 的 CIDR 一旦确定，后期修改非常困难。所以，设计阶段一定要考虑未来 3-5 年的业务增长，以及跟其他云、本地 IDC 的互联需求。
我的小技巧：在规划 IP 地址时，我会预留一段「过渡网段」。比如 /16 的 VPC，我只用前半段 /17，后半段留着给未来可能的新业务或容器网络插件用。这样即使后面要扩容，也不用推倒重来。
3.2 子网划分与路由策略：功能区与走廊
VPC 圈好了，接下来就是划分子网。子网是 VPC 内部的逻辑分段，每个子网必须绑定一个可用区。你想想看，如果你把所有资源都塞在一个子网里，那跟没隔离有什么区别？
子网划分的常见模式：
- 公有子网 vs 私有子网：公有子网挂载互联网网关，里面的实例可以直接访问外网；私有子网没有，只能通过 NAT 网关或代理出去。我在项目中遇到过，有人把数据库放在了公有子网里，结果被扫描到端口，差点出事。嗯，数据库一定要放私有子网。
- 按业务功能划分：比如 Web 层、应用层、数据层各用一个子网。这样不仅方便管理，也方便后续配置安全策略。
- 按敏感等级划分：高敏感数据（如用户隐私、支付信息）放在独立的子网里，严格控制进出流量。
路由策略：子网之间默认是互通的，但你可以通过路由表来控制。每个子网关联一个路由表，路由表里定义了「目标网段 -> 下一跳」的规则。
# 典型的路由表配置示例（伪代码）
路由表 A（关联公有子网）：
目标：0.0.0.0/0 -> 下一跳：互联网网关
目标：10.0.0.0/8 -> 下一跳：VPC 内本地路由
路由表 B（关联私有子网）：
目标：0.0.0.0/0 -> 下一跳：NAT 网关
目标：10.0.0.0/8 -> 下一跳：VPC 内本地路由
我曾经踩过的坑：有一次配置路由，我把私有子网的默认路由指向了互联网网关，结果所有实例都变成了「公网可访问」。虽然安全组没放行，但暴露了管理接口。从那以后，我每次配完路由都会做一次「路由可达性检查」，确保没有意外暴露。
3.3 安全组与网络 ACL：门禁与保安
安全组和网络 ACL 是云上网络隔离的「最后一公里」。很多人搞不清两者的区别，我简单说一下：
- 安全组：实例级别的防火墙，有状态。你允许了入站流量，出站回包自动放行。说白了，它像你家的门禁卡，只认人（IP/端口），不认方向。
- 网络 ACL：子网级别的防火墙，无状态。你需要分别配置入站和出站规则。它像小区门口的保安，进出都要检查。
安全组设计原则：
- 最小权限原则：只开放必要的端口和 IP。比如 Web 服务器只开放 80/443，数据库只允许应用层的 IP 访问。
- 分层设计：我习惯给每个角色（Web、App、DB）创建独立的安全组，然后通过「引用安全组 ID」的方式互相授权。这样比写死 IP 更灵活。
- 审计与变更：安全组的变更要记录。我见过有人为了省事，直接放行 0.0.0.0/0，结果被挖矿程序盯上了。
# 安全组规则示例（AWS 风格）
安全组：web-sg
入站规则：
- 协议：TCP，端口：80，来源：0.0.0.0/0
- 协议：TCP，端口：443，来源：0.0.0.0/0
- 协议：TCP，端口：22，来源：管理跳板机安全组 ID
安全组：db-sg
入站规则：
- 协议：TCP，端口：3306，来源：web-sg 安全组 ID
网络 ACL 的使用场景：
网络 ACL 通常用于「粗粒度」的访问控制。比如，你想禁止某个子网访问另一个子网的所有流量，用安全组要配很多条规则，但网络 ACL 一条规则就能搞定。不过要注意，网络 ACL 是无状态的，你允许了入站，出站回包也要显式允许。
我的建议：日常使用中，优先用安全组。网络 ACL 作为「兜底」策略，用来防止安全组配置遗漏。比如，你可以在网络 ACL 里显式拒绝所有来自非信任区域的流量，然后在安全组里精细放行。这样即使安全组配错了，还有一层保护。
3.4 实战避坑指南
讲了这么多理论，最后分享几个我在项目中遇到的真实案例：
- 案例一：子网 IP 耗尽。有个团队在 /24 的子网里部署了 200 多台实例，结果 IP 不够用了，不得不重建子网。我建议每个子网预留 30% 的 IP 空间，给弹性伸缩和容器预留。
- 案例二：安全组规则爆炸。一个业务系统用了 50 多条安全组规则，排查问题像大海捞针。后来我推动用「安全组标签」和「自动化工具」来管理，规则数量降到了 10 条以内。
- 案例三：跨 VPC 互联的坑。两个 VPC 的 CIDR 重叠了，导致对等连接后路由冲突。嗯，这个教训告诉我们，VPC 设计阶段一定要统一规划 IP 地址段，尤其是多云场景下。
最后一个小建议：网络隔离不是「配完就完事」的。我每周都会做一次「网络配置审计」，用脚本扫描安全组和 ACL 的变更，看看有没有意外的放行规则。自动化是云上安全的好朋友，别偷懒。
好了，网络隔离的基础就聊到这里。下一章我们会深入「多云互联与流量调度」，到时候再聊聊怎么把不同云厂商的网络安全地连起来。