# 基于 Google Cloud 的安全双层网络 ## 目标 在 Google Cloud 上设计并部署一个自定义私有网络，将公共访问与后端资源分离开来，并通过最小权限的防火墙规则执行流量控制。 完成后的环境包含： - 一个自定义 VPC（非默认 VPC），划分为**公共**子网和**私有**子网 - 位于公共子网中的 **Web 服务器**，仅允许通过 HTTP 从互联网访问 - 位于私有子网中的**后端服务器**，**无公共 IP**，无法从互联网访问 - **防火墙规则**仅允许每一层所需的流量 —— 拒绝其他任何流量 - **Cloud NAT**，使私有服务器能够出站拉取更新，而无需在入站方向暴露 ## 架构 ``` Internet | [ HTTP :80 / SSH :22 ] <-- firewall: allow, restricted source | +-----------v-----------+ | PUBLIC SUBNET | 10.0.1.0/24 | web-server (nginx) | external IP | tag: web-server | +-----------+-----------+ | [ internal only ] <-- firewall: allow from 10.0.1.0/24 | +-----------v-----------+ | PRIVATE SUBNET | 10.0.2.0/24 | db-server | NO external IP | tag: db-server | +-----------+-----------+ | [ outbound only ] <-- Cloud NAT (egress for updates) | Internet ``` **安全理念：** 私有层可以*向外发起连接*（获取补丁/更新），但互联网上的任何设备都无法*向内连接*。公共层是唯一暴露的攻击面，且即使如此，它也仅接受实际需要的两个端口。 ## 构建方式（`gcloud` CLI） 整个环境均通过 Cloud Shell 配置： ``` # Custom VPC gcloud compute networks create secure-vpc --subnet-mode=custom # Subnets gcloud compute networks subnets create public-subnet \ --network=secure-vpc --region=us-central1 --range=10.0.1.0/24 gcloud compute networks subnets create private-subnet \ --network=secure-vpc --region=us-central1 --range=10.0.2.0/24 # Firewall rules (VPC firewall rules — 这些使用 network tags) # 注意：allow-ssh 的范围限定为单个 admin IP，绝不能是 0.0.0.0/0 gcloud compute firewall-rules create allow-http \ --network=secure-vpc --direction=INGRESS --action=ALLOW \ --rules=tcp:80 --source-ranges=0.0.0.0/0 --target-tags=web-server gcloud compute firewall-rules create allow-ssh \ --network=secure-vpc --direction=INGRESS --action=ALLOW \ --rules=tcp:22 --source-ranges=YOUR_IP/32 --target-tags=web-server gcloud compute firewall-rules create allow-internal \ --network=secure-vpc --direction=INGRESS --action=ALLOW \ --rules=tcp:3306,icmp --source-ranges=10.0.1.0/24 --target-tags=db-server # 公共 Web 服务器（包含用于安装 nginx 的 startup script） gcloud compute instances create web-server \ --zone=us-central1-a --machine-type=e2-micro \ --subnet=public-subnet --tags=web-server \ --metadata=startup-script='#! /bin/bash apt update && apt install -y nginx echo "

Hello from my secure VPC web tier

" > /var/www/html/index.html' # 私有 backend server（无公共 IP） gcloud compute instances create db-server \ --zone=us-central1-a --machine-type=e2-micro \ --subnet=private-subnet --tags=db-server --no-address # 用于私有 egress 的 Cloud Router + NAT gcloud compute routers create nat-router \ --network=secure-vpc --region=us-central1 gcloud compute routers nats create nat-config \ --router=nat-router --region=us-central1 \ --nat-all-subnet-ip-ranges --auto-allocate-nat-external-ips ``` ## 验证 | 测试 | 预期结果 | |---|---| | 浏览器访问 `web-server` 的外部 IP | nginx 页面加载成功 ✅ | | 尝试从互联网访问 `db-server` | 无外部 IP —— 无法访问 ✅ | | 在 `db-server` 上运行 `curl -I https://www.google.com` | 返回响应 —— 通过 NAT 的出站连接正常 ✅ | | 直接从互联网 SSH 连接到 `db-server` | 被阻止（无公共 IP；仅能通过堡垒机/IAP 访问） ✅ | 各步骤的截图见 [`/images`](./images)。 ## 展示的技能 云计算网络（VPC、子网、CIDR） · 网络隔离 · 最小权限防火墙设计 · Cloud NAT / 出站流量控制 · Compute Engine · 安全管理访问（堡垒机/IAP 概念） · 通过 CLI（`gcloud`）管理基础设施 ## 经验总结 在构建防火墙层的过程中，我遇到了一个很有启发性的区别。我的第一次尝试使用了 **network firewall policy**（一种全局 VPC 策略），但我无法将其范围限定仅应用于我的 Web 服务器——它一直应用于所有实例。原因是：**network firewall policy 不读取网络标签**——它们使用由 IAM 管理的 *secure tags*。更简单的 **VPC firewall rule** 才是遵循我设置在 VM 上的 `web-server` / `db-server` 网络标签的规则类型。理解何时使用哪种机制——VPC firewall rule（基于标签，简单易用）对比 network firewall policy（基于 secure tag、受 IAM 控制、支持层级结构，并且能够叠加威胁情报规则）——是本次实验最有价值的收获。我养成的另一个习惯是将 SSH 访问权限限制在单个管理员 IP，而不是对 `0.0.0.0/0` 开放，并且在配置任何资源之前先设置预算提醒。 *（请将其修改为您自己的语气——招聘人员能看出区别，而且您的真实经验比任何通用描述都更有说服力。）* ## 清理 实验结束后，所有资源均已被销毁以避免不必要的成本： ``` gcloud compute instances delete web-server db-server --zone=us-central1-a -q gcloud compute routers delete nat-router --region=us-central1 -q gcloud compute firewall-rules delete allow-http allow-ssh allow-internal -q gcloud compute networks subnets delete public-subnet private-subnet --region=us-central1 -q gcloud compute networks delete secure-vpc -q ``` ## 本系列的后续内容 - **阶段 2** — 负载均衡、高可用的 Web 层（托管实例组 + HTTP 负载均衡器） - **阶段 3** — 安全加固（IAM 最小权限、Cloud Armor WAF、Secret Manager） - **阶段 4** — 使用 Terraform 将所有内容重建为基础设施即代码 - **阶段 5** — 监控、日志记录与告警 - **阶段 6** — 毕业项目：完整的安全、高可用云应用 *实验完成时间：2026-07-25 · 云服务提供商：Google Cloud Platform*

标签：GCP, VPC, 网络架构, 防火墙策略