4. 网络基础架构设计

在 Google Cloud 上，网络不是“先开机器再补网络”，而是整个生产环境的地基。VPC 是全局资源，子网是区域资源，防火墙规则作用于实例网卡，路由决定流量去向。理解这四层关系，才能把“能通”变成“可控地通”。本节围绕一个典型生产场景展开：某企业在 asia-east1（台湾）与 asia-southeast1（新加坡）双区域部署应用，前端在台湾，数据库在新加坡，需要跨区域私网互通、按环境隔离、按角色放行，并让无公网 IP 的实例既能访问 Google API 又能访问互联网。

VPC 全局架构与子网区域规划

VPC 网络是全局的，一个 VPC 可以横跨所有区域；子网是区域级的，必须指定 region 和 CIDR。同一 VPC 内不同区域的子网默认通过 Google 骨干网私网互通，无需额外对等连接。因此规划的核心不是“怎么连”，而是“怎么分地址、怎么隔离”。

推荐按“环境 + 区域 + 用途”三段式划分。示例规划如下：

CIDR 规划要预留扩展空间：/20 提供约 4096 个地址，适合应用层；/24 提供 256 个地址，适合数据库或代理层。注意每个子网会保留 4 个地址（网络地址、网关、次网关、广播），实际可用数减 4。跨区域通信时，源地址是子网内 IP，目标地址是另一区域子网 IP，路由由 VPC 自动生成，无需手工配置。

防火墙规则与层级策略

防火墙规则是“有状态”的，允许入站后返回流量自动放行。规则按优先级从 0 到 65535 评估，数字越小优先级越高，命中即停止。规则可作用于整个 VPC 或通过目标标签、服务账号限定到具体实例。

生产环境建议采用“默认拒绝入站、按需放行”的策略。示例规则：

gcloud compute firewall-rules create allow-web-tpe \
  --network=prod-vpc \
  --direction=INGRESS \
  --priority=1000 \
  --action=ALLOW \
  --rules=tcp:80,tcp:443 \
  --source-ranges=0.0.0.0/0 \
  --target-tags=web

gcloud compute firewall-rules create allow-db-from-app \
  --network=prod-vpc \
  --direction=INGRESS \
  --priority=1000 \
  --action=ALLOW \
  --rules=tcp:5432 \
  --source-ranges=10.10.0.0/20 \
  --target-tags=db

第一条允许公网访问带 web 标签的实例的 80/443；第二条只允许台湾应用子网访问带 db 标签的数据库 5432 端口。这样即使数据库有公网 IP，也无法从互联网直接连接。层级策略方面，若使用共享 VPC，宿主项目可定义“组织级防火墙策略”，对宿主项目内所有 VPC 生效，优先级高于 VPC 级规则，适合统一安全基线。

共享 VPC

共享 VPC 解决多项目网络统一管理问题：宿主项目拥有 VPC 和子网，服务项目把实例部署到宿主项目的子网中。服务项目的实例使用宿主项目的子网 IP，但计费和配额仍归属服务项目。典型场景是“网络团队管宿主项目，业务团队管服务项目”。启用时需在宿主项目授予服务项目 roles/compute.networkUser，并指定可用的子网。共享 VPC 下，防火墙规则由宿主项目统一管理，服务项目不能自行修改宿主 VPC 的规则，这既是约束也是安全优势。

Private Google Access 与 Cloud NAT

没有外部 IP 的实例默认无法访问互联网，也无法访问 Google API。Private Google Access（PGA）解决后者：在子网级别开启后，实例可用内部 IP 访问 *.googleapis.com、storage.googleapis.com 等，流量走 Google 内部网络，不经过公网。开启命令：

gcloud compute networks subnets update prod-app-tpe \
  --region=asia-east1 \
  --enable-private-ip-google-access

Cloud NAT 解决前者：为没有外部 IP 的实例提供出站互联网访问。它绑定在区域级，需要指定路由器、子网和 IP 分配方式。示例：

gcloud compute routers create prod-router-tpe \
  --network=prod-vpc \
  --region=asia-east1

gcloud compute routers nats create prod-nat-tpe \
  --router=prod-router-tpe \
  --region=asia-east1 \
  --nat-all-subnet-ip-ranges \
  --auto-allocate-nat-external-ips

PGA 与 Cloud NAT 的分工是：访问 Google API 走 PGA，访问外部网站走 NAT。两者可同时开启，互不冲突。判断是否生效：在无外部 IP 的实例上执行 curl -s -o /dev/null -w "%{http_code}" https://www.googleapis.com 应返回 200；执行 curl ifconfig.me 应返回 NAT 分配的外部 IP，而不是实例自身 IP。

把上述要素串起来看：VPC 提供全局私网骨架，子网按区域和用途切分地址，防火墙规则按标签和源范围控制东西向与南北向流量，共享 VPC 让网络管理集中化，PGA 和 Cloud NAT 分别解决无公网 IP 实例访问 Google API 与互联网的问题。实际落地时，先用 gcloud compute networks subnets describe 确认子网 CIDR 与 PGA 状态，再用 gcloud compute firewall-rules list --filter="network=prod-vpc" 核对规则优先级，最后在无外部 IP 的实例上分别验证 PGA 与 NAT 的出口 IP，确保流量路径与设计一致。