VPC 通信与路由： subnet、跨 Region 与 Peering
验证：未记录
- 适用版本
- 未记录
- 验证范围
- 尚未登记验证记录。
前置：VPC 与 subnet 概念。网络创建与 NAT 实验见 网络实验，PSA、PSC 等服务访问方式见 私网连接。本文以普通 VPC、普通 IPv4 subnet 和 VM 为例；命令是配置示例，未执行云端实验。
先判断是否属于同一个 VPC#
| 场景 | 路由如何建立 | 还需要什么 |
|---|---|---|
| 同 VPC、同 subnet、不同 Zone | 自动生成的本地 subnet 路由 | 防火墙允许、目标服务监听 |
| 同 VPC、不同 subnet、同 Region | 自动生成的本地 subnet 路由 | 防火墙允许、目标服务监听 |
| 同 VPC、不同 subnet、不同 Region | 同样使用本地 subnet 路由，适用于整个 VPC | 防火墙允许、目标服务监听 |
| 不同 VPC、同 Region 或跨 Region | 显式建立 Peering 等连接 | 地址兼容、双方连接配置、路由和防火墙 |
同 VPC 跨 Region 有普通 subnet 路由，不代表 firewall 已允许通信。 独立 VPC 即使同 Region 也不会自动互通；先判断网络归属，再检查路由与访问规则。路由
subnet 路由属于 VPC，覆盖所有 Region#
创建 subnet 时，GCP 自动为其主、次要 IPv4 地址范围生成对应的本地 subnet 路由，适用于整个 VPC。扩展地址范围或删除 subnet 时，路由也由平台维护。
VPC：my-network（全局）
├─ 东京 subnet：10.10.0.0/24
│ └─ VM A：10.10.0.10
└─ 美国 subnet：10.20.0.0/24
└─ VM B：10.20.0.10
VPC 中的自动 subnet 路由：
10.10.0.0/24 → 东京 subnet 内的资源
10.20.0.0/24 → 美国 subnet 内的资源路由属于 VPC，不是向其他 subnet 添加地址池，也无须逐 subnet 关联 AWS 式路由表。
VM A → 10.20.0.10:8080 匹配美国 subnet 路由，回程匹配东京路由；无需 NAT、VPN、Cloud Router 或额外跨 Region 静态路由。
local subnet route 的 local 表示属于本 VPC，包含其他 Region。生命周期
路由连通与访问许可分开配置#
路由回答“如何到达”，防火墙回答“是否允许”，应用配置回答“端口是否提供服务”。在 Custom mode VPC 中，自动 subnet 路由不意味着默认允许 subnet 互访；默认隐含规则会拒绝未经允许的入站流量。
以上面的 VM A → VM B 为例，已有 VM B，给它添加 web-8080 网络标签，再为目标创建入站规则：
# 替换为实际项目；示例网络名是 my-network。
PROJECT_ID=REPLACE_PROJECT_ID
gcloud compute instances add-tags vm-b \
--project="$PROJECT_ID" --zone=us-central1-a --tags=web-8080
gcloud compute firewall-rules create allow-tokyo-web-8080 \
--project="$PROJECT_ID" --network=my-network \
--direction=INGRESS --allow=tcp:8080 \
--source-ranges=10.10.0.0/24 --target-tags=web-8080应用需监听 VM B 的内部地址或 0.0.0.0:8080，仅监听 127.0.0.1 无法被远端访问。在东京 VM A 内运行：
curl --connect-timeout 5 http://10.20.0.10:8080/若网络还有出站拒绝规则或更高优先级的 Deny policy，也需检查。允许入站后，已建立连接的响应流量由有状态防火墙处理；若 B 要主动向 A 发起新的连接，应另行检查 A 的入站许可。VPC 防火墙
两个 VPC 使用 Peering 通信#
VPC A：东京 subnet 10.10.0.0/24
⇅ VPC Network Peering
VPC B：美国 subnet 10.20.0.0/24Peering 连接的是两个全局 VPC，可供同 Region 或跨 Region 的资源使用，也支持跨 Project。两个网络需分别配置指向对方的 Peering；双方连接生效后，私有 IPv4 subnet 路由自动交换。
假设 vpc-a 属于 PROJECT_A，vpc-b 属于 PROJECT_B，且两边所有 subnet 地址范围符合 Peering 的非重叠限制：
PROJECT_A=REPLACE_PROJECT_A
PROJECT_B=REPLACE_PROJECT_B
gcloud compute networks peerings create a-to-b \
--project="$PROJECT_A" --network=vpc-a \
--peer-project="$PROJECT_B" --peer-network=vpc-b
gcloud compute networks peerings create b-to-a \
--project="$PROJECT_B" --network=vpc-b \
--peer-project="$PROJECT_A" --peer-network=vpc-a
gcloud compute networks peerings list --project="$PROJECT_A" --network=vpc-a
gcloud compute networks peerings list --project="$PROJECT_B" --network=vpc-b双方应显示 ACTIVE。还需在 VPC B 为目标配置来自 10.10.0.0/24 的必要入站规则，然后从 A 使用 B 的内部 IP 访问。上节防火墙示例可用于此场景，但目标项目和网络需改为 B 的项目、vpc-b。Peering 配置步骤
Peering 的关键限制：
- 地址不能重叠：两个独立 VPC 可以各用
10.10.0.0/24，但不能直接建立 Peering。 - 不支持传递路由：A ↔ B、B ↔ C，不会自动让 A ↔ C 互通。
- 防火墙独立管理：只交换路由，不共享防火墙规则；普通网络标签不能跨 VPC 作为来源身份使用，可按对端来源 CIDR 配置规则。
- DNS 不自动共享：Peering 不会自动共享 VM 内部 DNS 名称或仅对单个 VPC 可见的私有 DNS 区。需要配置私有区可见范围或 DNS peering。
- subnet 路由与自定义路由不同：私有 IPv4 subnet 路由自动交换；静态、动态等自定义路由需按需求设置导出和导入。交换自定义路由也不会让 Peering 具有传递性。
参考：Peering 行为与限制。
路由类型与配置入口#
| 类型 | 配置方式 | 典型用途 |
|---|---|---|
| 本地 subnet 路由 | 随 subnet 自动维护 | 同 VPC 的 subnet 通信，包括跨 Region |
| Peering subnet 路由 | Peering 生效后自动导入 | 到达另一个 VPC 的私有 subnet |
| 静态路由 | 手动指定目标范围、下一跳等 | 经网络设备或适用的 VPN 下一跳访问其他网段 |
| 动态路由 | Cloud Router 通过 BGP 学习 | HA VPN、Interconnect 等混合网络连接 |
| 默认路由 | 通常自动生成 0.0.0.0/0 → default-internet-gateway，可删除或替换 |
没有更具体匹配路径时的默认出口 |
默认互联网路由存在，也不意味着无公网 IP 的 VM 可以直接访问互联网；普通互联网出口还需要外部 IP、Cloud NAT 等适用配置。
VPC 的 Dynamic routing mode = Regional / Global 控制动态路由的作用范围。即使设置为 Regional，本地 subnet 路由仍覆盖整个 VPC，普通 VM 仍可跨 Region 访问同 VPC 的其他 subnet。
普通 subnet 路由由平台维护，不能当作隔离开关单独删除。普通 subnet 目的范围也不能用相同或更小前缀的静态路由随意覆盖；有插入网络设备的需求时，应另行设计策略路由等机制。路由类型及交互规则
查看配置可使用：
gcloud compute routes list --project="$PROJECT_ID" --filter='network:my-network'
gcloud compute firewall-rules list --project="$PROJECT_ID" --filter='network:my-network'
gcloud compute networks describe my-network --project="$PROJECT_ID"排障时还应在控制台查看具体 VM 网卡的适用路由，包括动态或 Peering 路由，不能仅凭一条静态路由列表判断整条路径。入口是 VM 详情中的网络接口，再查看 Firewall and routes / Routes。查看适用路由
与 AWS 的路由思路对照#
AWS 的 subnet 关联路由表，VPC 内有 local 路由。由于 VPC 属于一个 Region，跨 Region 私网连接需要连接两个 VPC，例如建立跨 Region Peering，并在双方相关 subnet 路由表中添加对端 CIDR → Peering 的路由。
GCP 同 VPC 的 subnet 路由由平台统一管理，自动覆盖所有 Region；不同 VPC 建立 Peering 后，私有 IPv4 subnet 路由自动交换。AWS 也支持跨 Region 私网连接，区别在于 VPC 范围与连接、路由的配置方式。AWS Peering 路由配置
只访问服务时选择 PSC#
如果 A 只需要访问 B 发布的某个服务，可以考虑 Private Service Connect：A 的客户端 → A 中的私有 endpoint → B 发布的服务。PSC 提供服务级连接，不等于两个网络整体互通。例如访问 published service 的 regional endpoint：默认要求客户端同 Region；跨 Region 客户端需在 endpoint 启用 global access，且生产者服务支持该配置。不要把它理解成把服务搬到客户端 Region；Google API bundle 等 endpoint 类型另有规则。Published service endpoint 与 global access。详细选择见 私网连接。PSC 官方说明
验收与排障顺序#
- 确认源、目标的 VPC、 subnet、Region 和内部 IP；跨 VPC 时检查地址冲突。
- 同 VPC 检查 subnet 路由；跨 VPC 检查双方 Peering 为
ACTIVE及目标路由已导入。 - 检查目标入站、来源出站及适用防火墙策略。
- 在目标检查应用监听地址、端口和主机防火墙，再从来源测试实际服务端口。
- IP 访问成功、域名访问失败时，再检查 DNS 可见范围。不要只用 ping 失败判断 TCP 服务不通。
示例规则使用完毕后可删除 allow-tokyo-web-8080，并移除对应目标标签。实验 Peering 可分别在两边用 gcloud compute networks peerings delete 清理；删除前确认没有业务依赖这些连接。