Google PCNE: 混合连接、Cloud Router 和 BGP — 学习指南

By Laurynas Brazys · 23 August 2026 · #google #PCNE #certification #exam-prep #study-guide

属于 Google Professional Cloud Network Engineer — 学习指南. 使用经过验证的答案练习： Google 考试中心, 或参加限时模拟考试： ExamRoll.io.

概览

Google Cloud 上的混合连接可在 VPC 网络与外部网络（例如本地数据中心或其他云）之间实现私有的、受控的通信。其核心构建块是 HA VPN 和 Cloud VPN 网关、用于动态路由的 Cloud Router with BGP，以及带有 VLAN 连接的 Interconnect。设计时必须在带宽、延迟、可靠性、运营复杂性和成本之间取得平衡，同时遵循确定性的路由行为和故障域隔离原则。本节涵盖设计和运营的考量、常见的故障模式以及系统性的故障排查方法。

混合连接：HA VPN、Cloud Router 和 Interconnect

HA VPN 和 Cloud VPN
- HA VPN 是一种区域性、高可用的 IPsec VPN，支持 IKEv2，并需要 Cloud Router 进行动态路由（eBGP）。一个 HA VPN 网关有两个接口；为了满足 SLA 并实现 ECMP，请为每个接口构建两条连接到不同对等端点的隧道。
- Classic Cloud VPN 支持 IKEv1 或 IKEv2 以及静态或基于路由的隧道；它不支持 HA VPN SLA。仅在对等方缺少 BGP 或您必须使用基于策略的选择器时才使用它。
- 对等网关是远程的 VPN 设备/IP。对于 HA VPN，请定义一个具有一个或多个公共 IP 的对等 VPN 网关，以模拟不同的接口或设备来实现冗余。
- SLA 设计：要获得 HA VPN 99.99% SLA 的资格，请跨独立的本地设备或接口部署冗余隧道，并使用动态路由。Classic VPN 没有 SLA 支持。
- 吞吐量扩展：单个 IPsec 隧道的吞吐量有限。使用 ECMP 跨多个隧道来增加总吞吐量。通过将额外的隧道终止在唯一的对等公共 IP 上来实现这一点。
Cloud Router 和 BGP
- Cloud Router 是一种区域性控制平面服务，可与 VPN 隧道或 Interconnect VLAN 连接建立 BGP 会话，并动态交换路由。
- 动态路由模式（VPC 级别）决定了学习到的动态路由在何处可用，以及哪些 VPC 子网路由会被通告出去：
  - 区域级：仅在同一区域学习和使用/导入动态路由。
  - 全局级：在所有区域学习和使用/导入动态路由；向对等方通告所有 VPC 子网路由（全局）。
Dedicated Interconnect 和 Partner Interconnect
- Dedicated Interconnect 在托管设施中提供直接连接到 Google 的物理 10 Gbps 或 100 Gbps 线路。您需要获取一份授权书 - 连接设施分配 (LOA‑CFA) 以启用交叉连接。创建 VLAN 连接（互连连接），将 802.1Q 标记映射到与 Cloud Router 关联的区域性 L3 连接。
- Partner Interconnect 通过服务提供商提供逻辑连接。您向合作伙伴请求 VLAN 连接；带宽在合作伙伴的边缘交付。仍需将连接与 Cloud Router 关联以进行 BGP。
- 冗余和 SLA：在同一区域使用两个放置在不同边缘可用性域（以及适用的不同物理互连）上的连接，以达到更高的 SLA（例如 99.99%）。单个连接或链路会降低 SLA。对于 Partner Interconnect，整体 SLA 也取决于合作伙伴。
交叉连接和 VLAN 连接
- 交叉连接是在对接机房中，连接您的机柜/设备与 Google 机柜的物理光纤。向您的提供商出示 LOA-CFA 以完成连接。
- VLAN 连接是到 VPC 区域的逻辑 L2 分界点。每个连接：
  - 通过一个 Cloud Router 关联到唯一的一个 VPC 和区域。
  - 成对配置以实现冗余和 ECMP。
  - 仅承载 L3 流量；无 L2 扩展。

简短示例：

为一个连接或 HA VPN 对等方创建 Cloud Router 和 BGP： gcloud compute routers create cr-us-east1 –region=us-east1 –network=my-vpc –asn=65010 gcloud compute routers add-bgp-peer cr-us-east1 –region=us-east1 –peer-name=onprem-peer1 –peer-asn=65020 –interface=if-1 –peer-ip-address=169.254.0.2 –advertise-mode=DEFAULT –enable-bfd

路由和 BGP 行为

动态路由与静态路由
- 使用 Cloud Router 的动态路由提供自动路由学习、收敛和 ECMP。随着网络的增长，它能够扩展并减少运维开销。
- 当对等体缺少 BGP 支持，或用于范围狭窄、确定性的路径时，静态路由是合适的选择。在 VPC 中，静态路由具有数字优先级；对于相同前缀长度的静态路由，优先级值越低越优先。
- VPC 中的路由选择：
  - 最长前缀匹配优先。
  - 子网路由不能被自定义路由覆盖。
  - 对于相同前缀长度，静态路由按最低优先级选择。在动态路由中，Cloud Router 在安装路由前已经解析出最佳路径。系统默认路由的优先级最低。
BGP 会话、通告和导入/导出
- Cloud Router 默认导出 VPC 子网或一组自定义前缀。您可以在需要时通告 0.0.0.0/0 或聚合前缀，但如果策略允许，这样做会将本地流量拉向云端；请谨慎设计。
- Cloud Router 会导入任何允许的本地前缀，并根据 VPC 动态路由模式将其安装为动态路由。
- 每个对等体通告的路由优先级可让您影响本地路由器如何优先选择一条 Google 路径而非另一条；较低的优先级值会转化为向对等体通告的更优先的 MED 值。
ASN、MED 和主备模式
- 每个管理域使用唯一的私有 ASN，除非有必要使用公有 ASN。对于多个本地路由器为相同前缀与同一 VPC 对等的情况：
  - 要启用 ECMP 或一致的最佳路径，请在所有通告相同前缀的路由器上使用相同的本地远程 ASN。不同的远程 ASN 可能会阻止在 Cloud Router 上安装等价路由。
  - 对于主/备模式，可以从本地侧操作 MED（值越低越优先），或调整 Cloud Router 的每个对等体通告的路由优先级，使本地优先选择主路径。AS 路径前置 (AS-path prepending) 是一种替代方案，但其控制粒度较粗。
多路径设计
- Cloud Router 支持在 HA VPN 和 Interconnect 连接的多个等价 BGP 路径上实现 ECMP。请确保属性（AS 路径长度、MED、local-pref）相同且下一跳不同。对于 HA VPN，将隧道终止在不同的对等 IP 上。对于 Interconnect，使用冗余连接。

弹性、检测和出站服务

BFD 和故障检测
- BFD 加速了 HA VPN 和 Interconnect 上 BGP 会话的故障检测。在两侧启用 BFD 并设置兼容的时间间隔，以根据您的稳定性需求实现亚秒级或秒级检测。在 IPsec 隧道上与 IKE DPD 结合使用。确保您的对等设备能够处理更频繁的控制流量。
- 注意非对称检测：激进的 BFD 设置加上拥塞的链路可能导致会话抖动；从保守的计时器开始并进行监控。
冗余拓扑模式
- HA VPN：每个区域使用一个 HA VPN 网关，并将隧道终止到两个不同的本地设备或接口上。每个区域构建至少四个隧道（每个接口两个）和一个 Cloud Router。在提供 ECMP 时保持远程 ASN 一致。
- Interconnect：在每个区域中，跨越不同的边缘可用性域使用至少两个连接。对于 Dedicated Interconnect，尽可能将链路部署在不同的边缘设备和设施中。
Cloud NAT、外部地址和私有工作负载出站
- Cloud NAT 是为没有外部 IP 的资源提供的区域性、托管式出站服务。它不会对拥有外部 IP 的实例进行 SNAT；这些实例会直接出站。选择一个区域中的部分或所有子网以覆盖私有工作负载。
- 为并发连接和临时端口规划 NAT IP 池的大小；选择手动或自动 IP 分配。启用日志记录以进行诊断。
- 如需私密访问 Google API：
  - VPC 内部：在子网上启用 Private Google Access，以便没有外部 IP 的虚拟机可以通过 Google 的虚拟 IP 访问 Google API。
  - 从本地环境：为 Google API 使用 Private Service Connect 端点，并结合混合 DNS，以便本地客户端通过私有混合链路解析和访问 API，从而避免使用互联网。
- 如果默认路由指向第三方防火墙，但您希望私有工作负载绕过它来访问 Google API，可以使用 Private Service Connect，或者为已发布的 Google API IP 范围安装指向默认互联网网关的更高优先级的静态路由，并结合在子网上启用 Private Google Access。
混合 DNS 集成
- 使用 Cloud DNS 私有区域进行 VPC 内的名称解析。通过以下方式扩展到本地环境：
  - 入站转发：本地解析器将 VPC 托管的私有区域的查询转发到 Cloud DNS。
  - 出站转发：VPC 解析器将选定域的查询转发到本地 DNS。
  - 在共享 VPC 或多项目环境中使用对等区域进行跨 VPC 解析。
- 为了实现私有 API 的可达性，创建一个私有区域，将 API 主机名映射到 Private Service Connect 端点，或者在使用 Private Google Access 时映射到相应的 Google 私有 VIP，并确保这些名称可以通过 DNS 转发从本地环境解析。

规划与故障排查

带宽、延迟和成本的权衡
- VPN：部署最快，固定成本最低，但单隧道的吞吐量有限，每比特的 CPU/加密开销更高，且延迟通常高于专线。
- Dedicated Interconnect：吞吐量最高，每比特成本最低，延迟可预测；但固定成本和交付周期（交叉连接、主机托管）较高。
- Partner Interconnect：介于两者之间；利用服务提供商的覆盖范围；SLA 和延迟取决于合作伙伴的路径。
- 将附件和网关部署在区域上靠近工作负载的位置，以最大限度地减少延迟。使用 Shared VPC 将连接集中在宿主项目中，同时为多个服务项目提供服务。
- 考虑流量对称性、检查要求和故障域。避免在本地最后一公里和服务提供商路径中出现单点故障。
系统化诊断隧道、BGP 和路由问题
1. 隧道建立
  - 验证 IKE 版本兼容性：HA VPN 需要 IKEv2；如果对等设备仅支持 IKEv1 或基于策略的 VPN，请使用 Classic VPN。
  - 检查共享密钥、提议（加密、DH 组）、NAT-T 以及 UDP 端口 500/4500 的可达性。
  - 确认对等 IP，并确保每个隧道指向一个独立的对等接口以实现冗余。
2. BGP 会话健康状况
  - 确认两端的 BGP 状态；检查 Cloud Router 状态。如果启用了 BFD 但会话发生抖动，请放宽计时器。
  - 验证 ASN 配置；不匹配的预期可能导致 ECMP 无法工作或出现非预期的最佳路径选择。
  - 确保用于 BGP 会话的 IP 地址使用的是在隧道或附件接口上配置的正确的链路本地或 RFC1918 地址。
3. 路由交换与传播
  - 检查 Cloud Router 的通告模式（DEFAULT vs CUSTOM）。确保预期的子网或聚合路由已导出。
  - 检查 Cloud Router 上收到的路由；评估 AS-path、MED。如果意图是主/备模式，请确保 MED 或通告的路由优先级反映了该意图。
  - 验证 VPC 动态路由模式（REGIONAL vs GLOBAL），以确保学习到的路由出现在需要的位置。请记住，子网路由不能被覆盖。
  - 对于冲突，如果静态路由和动态路由具有相同的前缀长度，则优先级值最低的静态路由胜出。当出现非预期的重叠时，调整或删除重叠的静态路由。
4. 数据平面验证
  - 使用 VPC Flow Logs 和 Cloud NAT 日志来确认出站路径和地址转换。如果虚拟机仍使用其外部 IP 出站，请移除该外部 IP 以强制使用 NAT。
  - 对于 Interconnect，验证附件的操作状态，并确保两个附件都已在管理上启用并关联到正确的 Cloud Router。
  - 确认防火墙规则允许 BGP 和应用程序流量；请记住，必须允许 Google 健康检查源范围访问负载均衡器后端。
5. Interconnect 启用细节
  - 从控制台或 NOC 联系邮箱获取 LOA-CFA。在建立 BGP 之前，与提供商确认交叉连接的光功率水平和 VLAN 标记。

实际问题场景

Contoso 制造公司正在将其 ERP 工作负载迁移到 Google Cloud，同时保持本地工厂在线。要求：20 Gbps 的私有连接，具备亚秒级故障切换能力，集中式路由控制，从本地到云的主/备出口，无需公共互联网即可私有访问 Google API，以及最小化运维开销。

方法：

在同一都会区的不同边缘可用性域和设施中部署两条 Dedicated Interconnect 链路；每个区域创建两个 VLAN 附件（主用和备用），并将它们关联到一个区域性 Cloud Router。
- 理由：Dedicated Interconnect 提供了所需的聚合吞吐量和可预测的延迟。冗余的链路和附件可以隔离故障，并满足更高 SLA 的要求。多个附件支持 ECMP，并允许在不中断流量的情况下进行维护。
每个区域配置一个 Cloud Router，该路由器带有两个 BGP 对等体（每个附件一个），并启用 BFD。
- 理由：单个路由器简化了控制平面的管理，同时仍然支持通过多个下一跳实现 ECMP。BFD 将故障检测时间缩短至数秒内，从而改善了 ERP 应用的收敛 RTO。
在与 Google 对等的两个工厂边缘路由器上，标准化使用相同的本地远端 ASN，并从每个路由器通告相同的前缀。
- 理由：匹配的远端 ASN 允许 Cloud Router 在需要时安装等价路径并进行负载均衡。如果使用不同的 ASN，可能只有一组路由会被安装，从而导致多路径失效。
从本地到 Google 使用 MED 实现主/备偏好，从 Google 到本地则使用 Cloud Router 的通告路由优先级；在主路径上设置较低的值。
- 理由：双向策略确保了确定性的流量方向：工厂优先选择主都会区来到达云端，而 Contoso 的 VPC 则优先选择主工厂数据中心作为返回流量的路径。这避免了非预期的不对称性。
在 Shared VPC 中为 Google API 启用 Private Service Connect，并创建一个私有 DNS 区域，将 API 主机名映射到 PSC 端点；配置 Cloud DNS 入站转发，以便本地解析器可以私下解析这些名称。
- 理由：PSC 提供了对 Google API 的私有、VPC 内访问。混合 DNS 使这些端点可以通过 Interconnect 从工厂访问，从而消除了 ERP 支持服务对互联网的暴露和对防火墙的依赖。
作为 VPN 备用方案，在每个区域添加一个 HA VPN 网关，该网关带有两条隧道连接到不同的本地设备；在 BGP 会话上启用 BFD 并允许 ECMP。
- 理由：如果 Interconnect 受损，HA VPN 可维持私有可达性。每个设备的双隧道可保持 SLA 和吞吐量的连续性，而 BFD 可加速故障切换。
对于私有工作负载到互联网和非 Google 目的地的出站流量，在 ERP 子网上配置区域性 Cloud NAT；不要为虚拟机分配外部 IP。
- 理由：Cloud NAT 无需虚拟机管理开销即可扩展转换规模，并保留了私有地址。移除外部 IP 可确保使用 NAT，并简化了出口控制。
通过分阶段测试来验证路由和故障切换：拔掉一个附件，然后拔掉一个本地路由器，再模拟链路降级；监控 BGP、BFD 和应用 SLO。如果发生抖动，则调整 BFD 计时器。
- 理由：受控的故障注入可以验证设计是否满足恢复目标，并防止在生产环境中出现意外。调整计时器可以在稳定性和响应性之间取得平衡。