云网络基础:VPC、子网与安全组

上云第一件事,大多数人凭直觉是"开一台虚拟机"。错。真正该先动手的是网络。

讲个真实的事故:某团队为了"方便调试",把 RDS 数据库的 3306 端口对 0.0.0.0/0 开放,心想反正密码很复杂。两周后,数据库被拖空,日志里是一条境外 IP 用弱口令字典跑了一晚上。密码复杂不复杂根本不重要——暴露在公网上的数据库,等于把保险柜搬到马路边,然后相信没人会撬。

这种事故的根因,不是密码策略,不是数据库版本,是网络没搞懂。云上的网络(VPC、子网、安全组、NAT)是整个安全模型的地基。地基错了,上面堆多少加固都是空中楼阁。这篇文章把云网络最核心的几件事讲透:为什么云网络和机房不同、VPC 是什么、公共子网和私有子网怎么分、安全组和 NACL 怎么配、NAT 干嘛用,最后给一套"两层子网 + 最小暴露"的经典架构。

一、云网络不是"把交换机搬上云"

很多人把云网络理解成"机房那套搬上云",这是个危险的误解。云网络是软件定义网络(SDN),它和传统网络有三个根本差异:

• 逻辑隔离,而非物理隔离。机房里两套业务要隔离,得拉两套网线、两个交换机,物理上隔开。云上隔离是逻辑的——你定义一段 CIDR(VPC),这段地址空间就只属于你。同一个物理机柜上可能跑着几十个租户的虚拟机,但你的流量到不了别人那里,靠的是云底层的网络虚拟化(VPC、VXLAN 之类),不是网线。
• 安全模型是"默认拒绝"。传统网络常常是"内网默认信任",云上正好相反——默认全部不通,你显式放行才会通。安全组默认就是全拒绝,这是云安全的底线。
• 一切可编程。子网、路由、防火墙规则全是 API 对象,能用代码(Terraform/Pulumi)创建、能进 Git、能走评审、能回滚。这一点是 IaC 的基础,也是云网络比机房网络强的地方。

理解这三点,后面的概念就顺了。云网络不是更复杂的机房网络,是另一种范式。

二、VPC:你在云里的私人领地

VPC(Virtual Private Cloud)就是你在云上分到的一段私有 IP 空间。AWS、阿里云、GCP 都有这个概念(阿里云叫 VPC、GCP 叫 VPC network),本质一样。

你可以把 VPC 想象成云里划给你的一个私人园区:

• 它有一段 CIDR 地址(比如 10.0.0.0/16,65536 个 IP)。
• 园区内部这些 IP 互相可达,园区外面(其他租户、公网)默认进不来。
• 园区里你想怎么切分子网、怎么布路由,自己定。
• VPC 是**区域级(region)**资源,要跨可用区(AZ)做高可用,就在一个 VPC 里跨 AZ 建子网。

关键认知:VPC 本身不连公网。一个刚建好的 VPC 是个"孤岛",里面的机器互相能通,但访问不了 internet,公网也访问不了它。要打通公网,得显式加两样东西——Internet Gateway(进公网)和 NAT Gateway(出公网)。这就是下一节子网分类的来源。

三、子网:公共 vs 私有,数据库放哪

VPC 切成子网(subnet),子网是AZ 级的——每个子网落在某个可用区里。按"能不能从公网直接访问",子网分两类:

公共子网(Public Subnet):路由表里有一条指向 Internet Gateway(IGW) 的默认路由(0.0.0.0/0 → IGW)。这里的实例只要配上公网 IP / 弹性 IP,就能被公网直接访问。放什么?面向公网的入口——负载均衡器(ALB/NLB)、堡垒机(Bastion)、NAT 网关本身、需要公网 IP 的 API 网关。

私有子网(Private Subnet):没有到 IGW 的路由。这里的机器没有公网 IP、公网也访问不了它。放什么?不该被公网直接访问的东西——数据库(RDS/Redis/Elasticsearch)、应用服务器、内部微服务、消息队列。

判断一个子网是公共还是私有,不要看名字(名字可以乱起),看路由表里有没有 0.0.0.0/0 → IGW 那条规则。这是唯一标准。

记住一条铁律:数据库永远放私有子网。没有例外。如果有人说"我先放公共子网方便测试",你可以直接拦下——方便测试的成本,可能是拖库。

四、安全组:实例级防火墙,默认拒绝

光把数据库放私有子网还不够——私有子网内的机器之间默认还是通的。要进一步控流,就得用安全组(Security Group)。

安全组是绑定在实例网卡(ENI)上的有状态防火墙。它的几个关键特性:

• 有状态(stateful):你放行了入站,出站回包自动放行,不用单独写反向规则。这点和 NACL 不同,后面会讲。
• 默认拒绝:新建的安全组,入站规则一条都没有——全拒绝。你必须显式写规则才会通。
• 白名单模型:你写"允许谁从哪个端口进来",而不是"禁止谁"。配置时永远问"还需要哪条放行",不是"还要封谁"。
• 引用而非写 IP:安全组规则可以引用另一个安全组,比如"允许 sg-app 这个安全组访问 3306",而不是写 10.0.10.0/24。IP 会变,安全组 ID 不会,这样维护起来稳得多。

一套合理的配置长这样:app 安全组入站只允许 ALB 安全组的 8080;DB 安全组入站只允许 app 安全组的 3306。层层引用,谁也跳不过去。

最常见的灾难配置是 0.0.0.0/0 全端口放行——尤其是 22(SSH)、3306、6379 这几个。一旦写了,等于把服务挂公网裸奔。每次 review 安全组,先 grep 这条规则。

五、NACL:子网级的第二道关

NACL(Network ACL)是绑定在子网上的无状态防火墙。它和安全组是两个层次:

NACL 用得少,但有两个场景值得用:一是当一个子网里跑了多个租户的实例,想在子网边界做一层硬隔离;二是阻断已知恶意 IP 段——NACL 可以显式 DENY,安全组只能 ALLOW。

绝大多数中小项目,安全组配好就够,NACL 保持默认。但要知道它的存在,因为 NACL 是无状态的——如果你只在 NACL 放了入站 80,没放出站临时端口,连接就是不通,这种坑排查起来极费时间。

六、NAT 网关:让私有子网"出得去、进不来"

私有子网里的机器没有公网 IP,但它们常常需要主动访问公网——下载系统更新、拉 Docker 镜像、调外部 API、上报监控。怎么让它们出去又不暴露自己?NAT 网关。

NAT(Network Address Translation)网关放在公共子网,它的作用就一句话:把私有子网机器的出站流量,换成自己的公网 IP 转发出去;回来的包再转回给那台机器。效果是——私有机器能主动连外网,但外网无法主动连进来(因为 NAT 表里没有对应条目)。

配法是固定的:私有子网的路由表里加一条 0.0.0.0/0 → NAT Gateway。从此 app 机器能 apt update,能 curl api.github.com,但公网扫不到它。

一个坑:NAT 网关按量计费,而且不便宜。它有按小时的小时费 + 每 GB 处理费。一个跑着大流量镜像拉取、或每天 TB 级出口的服务,账单上 NAT 可能占一大块。优化方向:把常用镜像放到内网的镜像仓库(VPC Endpoint / 私有链路),绕开 NAT;大批量数据传输走 VPC peering 或直连。

七、经典架构:两层子网 + 最小暴露

把上面拼起来,就是云上最经典的安全架构——公共子网 + 私有子网,层层隔离,最小暴露:

                      Internet
                         │
                  ┌──────┴──────┐
                  │   IGW 网关   │
                  └──────┬──────┘
                         │
   ┌─────────────────────┴──────────────────────┐
   │            VPC 10.0.0.0/16                  │
   │                                             │
   │  公共子网 10.0.1.0/24 (有 IGW 路由)          │
   │   └─ ALB / 堡垒机 / NAT 网关                 │
   │           │                                 │
   │  私有子网 10.0.10.0/24 (app)                 │
   │   └─ 应用容器 / API 服务                     │
   │      │  ↑ SG: 仅允许 ALB 的 8080             │
   │      │  ↓ SG: 仅允许访问 DB 的 3306          │
   │  私有子网 10.0.20.0/24 (db)                  │
   │   └─ RDS / Redis  ← 无公网,无 IGW 路由      │
   │           SG: 仅允许 app 安全组的 3306/6379 │
   └─────────────────────────────────────────────┘

流量的走向:用户 → ALB(公共子网)→ app(私有子网)→ DB(私有子网)。每一跳都被安全组收紧,数据库只信任 app,app 只信任 ALB,ALB 只对公网开 443。任何一层被攻破,攻击者也无法直接跳到下一层,因为他没有对应的放行规则——这就是"最小暴露"。

跨 AZ 高可用,就把每个子网在 2-3 个 AZ 里各建一份,ALB 和 RDS 都是天然多 AZ 的。架构骨架不变。

八、四个一踩一个准的坑

• 数据库对公网开放。前面讲的事故,根因就是这条。一旦你看到 RDS 安全组里有 0.0.0.0/0 → 3306,立刻删掉。数据库永远在私有子网,永远只对 app 安全组开端口。
• 安全组全开 0.0.0.0/0。22、3306、6379、5432 这些端口尤其不能对公网开。需要 SSH 用堡垒机或 SSM Session Manager,不要直接挂公网。
• NAT 网关账单刺客。它是按量 + 按 GB,大流量出口很贵。把镜像源、对象存储、第三方 API 这些高频访问,尽量走 VPC Endpoint 或私有连接,绕开 NAT。
• 忘了开安全组端口,然后怀疑代码有 bug。机器之间连不上,90% 不是代码问题,是安全组没放行。排查时先 telnet / nc 试端口,再看两边安全组的入站/出站规则,最后才去看应用日志。顺序错了能调试一晚上。

小结

• 云网络是软件定义 + 默认拒绝 + 一切可编程,不是机房那套物理网络的翻版。地基思维先变过来。
• VPC 是你的私有 IP 空间,默认是孤岛。要连公网必须显式加 IGW(进)或 NAT(出),这是子网分类的根源。
• 公共子网放入口(ALB/堡垒),私有子网放数据(DB/app)。判断看路由表里有没有 0.0.0.0/0 → IGW,不看名字。
• 安全组是实例级有状态白名单,默认拒绝,规则尽量引用别的安全组而不是写死 IP;NACL 是子网级无状态,多数项目保持默认即可。
• NAT 让私有子网"出得去、进不来",但按量计费别滥用;经典的"公共子网 → app → DB"两层架构,层层收紧、最小暴露,是云上安全的标配。

一句话收尾:云上的安全,90% 在网络层,不在应用层。一个 VPC 切得清楚、子网分得干净、安全组只开必要端口的架构,已经替你挡掉了绝大多数攻击——剩下的密码、补丁、加密,都是在网络地基之上的加固。先把网络搞懂,再谈别的。