多个 Google Cloud 项目，一个混合 VPN？先做决定

当多个 Google Cloud 项目都需要混合访问时，直觉是按项目各建一个 VPN，而这几乎总是错误的形态。项目归属与数据包路由相互关联，却是两回事；有用的架构会保留你需要的管理边界，同时让目标前缀以一条经过斟酌的路径通往办公室或数据中心。下面这些检查按避免返工的先后顺序，决定你真正需要哪种网络模型。每一项都可能提前结束讨论，这正是重点。

项目边界并不自动要求各自建一条隧道。

先确认共享的对象是不是网络

从归属问题入手，而不是从连通性入手：中心化的网络归属能否支撑这些工作负载？如果答案是肯定的，且组织具备符合条件的配置，那么宿主项目拥有 VPC、子网与连通性，服务项目拥有自己的应用资源。共享网络中的一条 Cloud VPN 连接即可服务目标工作负载前缀， 但须遵守路由与安全策略 。

要准确理解关联到底做了什么。关联服务项目并不会把它现有的独立 VPC 并入宿主网络，也不会自动迁移每一项资源。工作负载关联、权限、地址空间和 DNS 都属于架构的一部分，而不是该设置的必然结果。请把关联首先理解为权限变更，其次才是路由变更，因为团队通常在切换期间才会发现差别。

如果相关团队无法接受中心化归属，就到此为止，把其余部分当作对等互连或中心型设计。把 Shared VPC 强加给需要独立网络生命周期的团队，只会制造一个带有技术名词的政治问题。

确认独立 VPC 能否保持独立

对等互连保留各自独立的 VPC，这正是它吸引那些想要自己的地址规划和变更控制的团队的原因。问题在于对等互连不具传递性：A 到 B、B 到 C 的对等互连本身并不会建立经 B 的 A 到 C 路由。如果三个项目都要到达同一个混合目的地，你需要一份经过斟酌的交换方案，而不是一串对等互连。

共享混合可达性还取决于有文档记载的自定义路由交换和既定的 Cloud Router 通告。对等互连状态为“活动”只能证明对等互连存在，不能证明双方关心的前缀确实曾被导出。请在执行导出的配置中检查对等两端的已导出范围，并与工作负载实际使用的地址作对比。那里的不匹配，正是对等互连看起来健康、前缀却始终不可达的最常见原因。

先把地址规划写下来。互不重叠的范围、通往每个既定目的地的路由，以及回程通告，是这套模型赖以生存或失败的三件产物。

确认中心型模型是否契合拓扑

对于规模更大或分段方式不同的设计，Google 的 Network Connectivity Center 概览 介绍了中心与分支模型。请读它当前版本支持什么，而不是图示意了什么：哪些 VPC 与混合组合、哪些路由族，以及每种分支类型允许哪些策略。

请明确检查地址族。多数指南（包括本文）中的规划示例都针对 IPv4，而为一种分支类型存在的功能并不会自动原样适用于另一种。如果你的环境是双栈，这个问题属于模型选择，而不是后续迁移。

下表汇总了三种模型以及决定各自取舍的问题。

确认路由并不授予什么

路由交换并不是对你的一揽子信任授权。DNS 解析、防火墙许可和应用授权仍各自独立，而且在多数组织中分别由不同的负责人配置。假定“可达即已授权”的设计，会通过连通性测试，却在安全评审中失败。

也要为每种模型确认 DNS 的来龙去脉，因为共享网络与对等互连网络在区域和转发安排上并不相同。在一个项目中可解析的私有名称，不会沿着路由进入另一个项目。

记录这项决定及其负责人

在组织希望由共享网络负责人统一管理的地方集中管理；在生命周期或策略要求的地方保留独立 VPC。然后选择一种受支持的连通关系，并写清你选了哪一种、谁拥有共享网络，以及每个项目可以通告什么。

数项目数量、给每个项目买一条 VPN，并不能替代这项归属决定。那只是同一个决定被推迟，由接手账单和路由表的人来做。