Google PCNE: 私有连接至 Google 和托管服务 — 学习指南

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

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

概述

连接到 Google 和托管服务的私有连接涵盖了多种模式，这些模式允许工作负载在不使用公共 IP 的情况下与 Google API、Google 管理的生产者网络以及第三方服务进行通信。其目标是通过将流量保持在私有路径上，来降低数据泄露风险、简化合规性并提高可预测性。核心构建块包括 Private Google Access (及其受限端点)、Private Services Access (为 Google 管理的服务提供私有 IP)、Private Service Connect (用于生产者-消费者模式的私有服务发布和使用，包括 Google API)、VPC Service Controls (数据边界)、Cloud NAT (私有出站到公共互联网) 以及用于确定性端点选择的 DNS 映射。

设计成功与否取决于三个决策：

• 哪种私有访问机制与服务和安全模型相匹配 (针对 Google API，是使用 PGA 还是 PSC；针对托管或合作伙伴服务，是使用 PSA 还是 PSC)。
• DNS 应如何将服务名称解析到私有目标，同时不破坏不支持的服务。
• 路由和边界策略如何交互，以确保在发生故障或变更时，流量在端到端路径上始终保持私有。

故障模式通常源于路由选择、DNS 解析顺序、端点的区域范围或边界规则静默拒绝调用。验证每一层：名称解析、路由、防火墙、端点健康状况和服务策略。

Private Google Access、受限端点和端点选择

Private Google Access (PGA) 使没有外部 IP 的虚拟机和 GKE 节点能够通过 VPC 的默认互联网网关（而不是通过 Cloud NAT）使用 Google 任播 VIP 访问 Google API 和服务。此功能按子网启用。

• 端点：

  • private.googleapis.com (199.36.153.8/30): 完整的 Google API 接口。
  • restricted.googleapis.com (199.36.153.4/30): 与 VPC Service Controls 兼容的 API 子集。当您强制实施服务边界时使用此端点。

• DNS 映射方法：

  • 保留默认的公共名称，并允许客户端访问公共 DNS。如果您允许通过 Cloud NAT 的出站流量，这种方法可行，但会削弱数据泄露控制。
  • 在针对 googleapis.com 的 Cloud DNS 私有区域中，使用 CNAME 将特定 API 主机名覆盖为 restricted.googleapis.com (或 private.googleapis.com)，以强制每个服务进行私有解析。 示例：创建一个私有区域 googleapis.com，并添加 storage.googleapis.com CNAME restricted.googleapis.com。

• 路由注意事项：

  • PGA 需要一条到默认互联网网关的路由。如果您将 0.0.0.0/0 流量发送到第三方 NGFW，则需要添加显式主机路由，以便 Google API VIP 使用默认互联网网关：

undefined

• 故障模式：如果缺少这些主机路由，当 0.0.0.0/0 的下一跳是防火墙实例时，没有外部 IP 的实例将无法访问 API。

• 子网配置：

undefined

权衡取舍：

• restricted.googleapis.com 降低了数据泄露风险，但某些 API 不可用。
• PGA 流量会绕过 Cloud NAT，因此 NAT 日志中不会显示这些流量。请在子网上使用 VPC Flow Logs。

对于本地客户端，您可以通过两种方式为其提供对 Google API 的私有访问：一种是通过 Cloud VPN/Interconnect 向本地通告 199.36.153.4/30 和/或 199.36.153.8/30，并将 VPC 中的下一跳设置为默认互联网网关；另一种是暴露 PSC 端点 (见下文) 并将本地 DNS 映射到这些端点。

Private Services Access 和 Private Service Connect

Private Services Access (PSA) 为托管 Cloud SQL（私有 IP）和 Memorystore 等服务的 Google 托管生产者网络提供私有 IP 连接。您需要在您的 VPC 中分配一个 RFC1918 范围供 Google 使用，并与服务生产者网络建立对等互连连接。

• 设置模式：

  • 为 VPC 对等互连预留一个地址范围： gcloud compute addresses create google-managed-services-range
    –global –purpose=VPC_PEERING –prefix-length=24 –network=VPC
  • 建立私有连接： gcloud services vpc-peerings connect
    –service=servicenetworking.googleapis.com –network=VPC
    –ranges=google-managed-services-range
  • 使用私有 IP 预配托管服务。

• 运维说明：

  • 该范围必须足够大以容纳所有实例，且不得与现有范围重叠。
  • 对等互连不具有传递性；流量必须源自对等互连的 VPC（如果路由允许，本地环境可以通过该 VPC 访问）。
  • 之后更改或缩小范围会造成中断；请做好容量规划。

Private Service Connect (PSC) 将私有连接扩展到：

• Google API（消费者在子网中创建具有私有 IP 的端点，并通过 DNS 将 API 名称映射到这些 IP）。
• 通过服务附件发布的合作伙伴和 SaaS 服务。
• 通过服务附件私下发布到其他项目或组织的您自己的服务。

生产者-消费者模型：

• 生产者在某个区域发布一个由内部负载均衡器支持的服务附件。生产者可以要求消费者项目/组织加入许可名单，并指定连接配额。
• 消费者在同一区域创建一个 PSC 端点（转发规则），指向生产者的服务附件。该端点会从所选子网中获取一个 IP。

设计限制与权衡：

• PSC 是区域性的；应在靠近消费者的每个区域进行部署。使用 DNS 策略或加权记录来引导邻近的客户端并提供故障切换。
• PSC 不具有传递性；消费者无法通过一个端点将服务链接起来。
• 在 PSC 连接中，源 IP 不会被端到端保留；在设计生产者端的控制措施时要考虑到这一点（例如，依赖身份或应用级授权）。

常见故障模式：

• 生产者 ILB 健康检查失败会导致 PSC 连接被拒绝。
• 消费者的端点与服务附件创建在不同的区域。
• 生产者的拒绝策略或项目未在许可名单中，导致连接被阻止。
• DNS 未指向端点 IP，或重叠的私有区域解析到了错误的目的地。

VPC Service Controls、边界、入站/出站和 DNS 映射

VPC Service Controls (VPC-SC) 围绕 Google 托管的资源定义服务边界，以缓解数据渗漏风险。在边界内部，对受保护服务的请求必须源自范围内的项目，并满足所有已配置的访问级别。

• 边界：

  • 标准边界保护托管数据的项目（例如，BigQuery、Cloud Storage）。
  • 边界网桥允许原本隔离的边界之间进行有限的交互。
  • 入站规则授予来自边界外部的特定访问权限（例如，来自 CI/CD 或监控项目）。
  • 出站规则限制可以调用哪些外部服务或 Google Cloud 内部的项目。

• 端点选择：

  • 使用 restricted.googleapis.com 将 API 调用限制在与 VPC-SC 兼容的服务，并避免意外调用非边界感知的公共端点。
  • 用于 Google API 的 PSC 通过将流量保持在私有 IP 上并启用区域亲和性来提供更强的控制，但仍需要配置边界进行授权。

• DNS 和命名：

  • 使用 Cloud DNS 私有区域实施分离 DNS (split-horizon DNS)，以便内部客户端将 API 名称解析为私有目标。
  • 优先为 restricted.googleapis.com 使用每个服务独有的记录或 CNAME，而不是对整个 googleapis.com 使用通配符，因为这可能会破坏那些必须保持公共访问的服务。
  • 对于 PSC，发布指向每个端点 IP 的 A 记录。为每个环境使用独立的区域，以防止意外的跨环境调用。

陷阱：

• 使用 Cloud NAT 访问公共的 googleapis.com 可能会绕过 VPC-SC 的意图，除非边界规则明确限制了出站流量；应将 NAT 与受限 DNS 或 PSC 结合使用。
• 某些 API 有多个主机名（例如，JSON vs XML 端点）；请确保您的 DNS 映射涵盖了客户端使用的所有名称。
• 边界配置错误会导致默认关闭（拒绝访问）；监控 Access Transparency 和 VPC-SC 日志以检测拒绝事件。

出站模式、混合访问与问题排查

私有工作负载的出站模式：

• 仅访问 Google API：启用 PGA 并将 DNS 映射到 restricted.googleapis.com，或为 Google API 部署 PSC 并将 DNS 映射到端点 IP。
• 互联网和 SaaS：为没有外部 IP 的实例使用 Cloud NAT。根据峰值并发连接数和端口数规划 NAT 的规模；监控端口耗尽情况。
• 与第三方 NGFW 混合使用：将 NGFW 作为默认路由，但为 Google API 的任播 VIP 添加特定的主机路由，以确保 PGA 绕过防火墙。对于非 Google 的目标地址，根据策略发送到 NGFW 或 Cloud NAT。

混合客户端（本地或其他云）：

• 私密地使用 Google API：
  • 方案 A：通过 Cloud Router 向本地通告 199.36.153.4/30 和/或 199.36.153.8/30，并将 VPC 中的下一跳设置为默认互联网网关，从而为本地环境启用 Private Google Access；根据需要将本地 DNS 映射到 restricted/private.googleapis.com。
  • 方案 B：在您的 VPC 中为 Google API 创建 PSC 端点；通过路由到端点 IP 并相应地映射本地 DNS，经由 Cloud VPN/Interconnect 将其暴露给本地环境。
• 要访问具有私有 IP 的 Google 托管服务（通过 PSA），需建立到 VPC 的连接（Cloud VPN/Interconnect），确保 RFC1918 地址范围不重叠，传播路由，并允许相应的防火墙规则。

问题排查与验证：

• DNS：从客户端使用 dig 或 nslookup 查询 API 主机名，并验证其是否解析为预期的私有地址（PSC 端点 IP）或 restricted/private 任播 VIP。检查 VPC 上的 Cloud DNS 策略顺序和私有区域。
• 路由：运行

undefined

并确认最具体的路由匹配预期的下一跳（对于 PGA VIP 是默认互联网网关，对于 PSC 是内部地址）。

• 防火墙：验证出站规则是否允许到目标 IP 的 TCP 443 流量。对于 PSC 后面的负载均衡生产者，验证健康检查源范围是否被允许。
• PGA：确认子网设置已启用，并且在存在自定义默认路由的情况下，存在针对 199.36.153.4/30 和/或 199.36.153.8/30 的主机路由。
• PSA：运行

undefined

以确认 servicenetworking 对等连接为 ACTIVE 状态，并且分配的范围正确且未在别处使用。

• PSC：在消费者端，描述端点以查看连接状态；在生产者端，检查待处理或被拒绝的连接以及 ILB 的健康状况。验证服务附件的消费者允许列表。
• Cloud NAT：使用 NAT 日志和指标来确认地址转换，并检查端口分配或耗尽情况。如果实例具有外部 IP，则根据设计会绕过 NAT。

实际问题场景

Contoso Research 在两个区域（us-east1, europe-west1）运行分析工作负载。安全要求规定，任何虚拟机都不能有公共 IP，Google API 必须能够通过私有方式访问并受 VPC Service Controls 的保护，本地用户需要私密访问一个 Cloud SQL 实例（私有 IP），并且必须私密地使用一个合作伙伴的 SaaS。一个第三方 NGFW 是默认的出站下一跳。

1. 启用 Private Google Access 和受限端点

• 操作：在所有分析子网上启用 Private Google Access。为 googleapis.com 创建 Cloud DNS 私有区域，并为所需的 API（BigQuery、Pub/Sub、Cloud Storage）添加 CNAME 记录指向 restricted.googleapis.com。在两个区域中为 199.36.153.4/30 添加指向默认互联网网关的主机路由。
• 理由：确保虚拟机到 API 的流量保持私密，与 VPC-SC 兼容，并绕过 NGFW，而无需创建广泛的互联网出口。

2. 创建 VPC Service Controls 服务边界

• 操作：将分析项目和数据项目放入一个服务边界内。根据需要为 Contoso 公司网络添加入站级别，并通过入站规则明确允许所需的跨项目流量。除非有非常充分的理由，否则避免使用边界网桥。
• 理由：降低来自 Google 托管服务的数据泄露风险，并与受限端点的使用保持一致。

3. 使用 Private Services Access 预配 Cloud SQL

• 操作：为 PSA 分配一个 /24 的地址范围，连接 servicenetworking，并在 us-east1 中创建一个具有私有 IP 的 Cloud SQL 实例。通过 Interconnect 将 VPC 路由传播到本地，并允许相应的防火墙规则。
• 理由：为 VPC 工作负载和本地客户端提供私有的 RFC1918 可达性，而无需公共暴露。

4. 为本地环境提供对 Google API 的私密访问

• 操作：通过 Cloud Router 向本地通告 199.36.153.4/30，并将 VPC 中的下一跳设置为默认互联网网关。在本地 DNS 上，将相同的 API 主机名映射到 restricted.googleapis.com。
• 理由：让本地客户端能够使用相同的受限私有路径，确保策略执行的一致性并最大限度地减少操作差异。

5. 通过 Private Service Connect 使用合作伙伴的 SaaS

• 操作：合作伙伴共享一个区域性的服务附件。在 us-east1 和 europe-west1 的子网中创建指向该附件的 PSC 端点。发布指向每个区域端点的私有 A 记录 (saas.partner.contoso)；使用加权 DNS 来优先选择区域性访问。
• 理由：将 SaaS 流量保持在私有 IP 上，并由生产者强制执行项目允许列表，通过区域亲和性改善延迟，并避免公共出口。

6. 为非 Google 的互联网出口保留 Cloud NAT

• 操作：部署按区域划分的 Cloud NAT 网关，其规模应能满足峰值流量。确保默认路由仍然指向 NGFW，但特定的受限 VIP 主机路由除外。
• 理由：允许对非 Google 目标进行受控的出站访问，同时确保 Google API 流量保持私密，并且 NGFW 保留中央可见性。

7. 验证和监控

• 操作：对于每种客户端类型，验证 DNS 解析、路由选择和 TLS 连接。检查 VPC-SC 日志中的拒绝记录、NAT 日志中的非 Google 出口流量以及 PSC 连接状态。为合作伙伴服务附件后面的 ILB 和 Cloud SQL 添加健康状况和可用性警报。
• 理由：确认数据路径与设计意图相符，并及早发现回归问题，尤其是在 DNS、路由或服务边界发生变化时。

← Cloud DNS、服务发现和混合名称解析 · 所有领域 · 路由、Network Connectivity Center 和分段 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Google →