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 的 VM 和 GKE 節點，可以透過 VPC 的預設網際網路閘道（而非 Cloud NAT）來存取 Google API 與服務，使用的是 Google 的 anycast VIP。這項功能是依每個子網路來啟用。

• 端點：

  • 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 私有區域中，用 CNAMEs 覆寫特定的 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 VIPs 使用預設網際網路閘道：

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 Service Connect

私有服務存取 (Private Services Access, PSA) 為代管 Cloud SQL (私有 IP) 和 Memorystore 等服務的 Google 代管生產者網路提供私有 IP 連線。您需要在您的 VPC 中配置一個 RFC1918 範圍供 Google 使用，並與服務生產者網路建立對等互連。

• 設定模式：
  • 為 VPC peering 保留一個位址範圍：

undefined

• 建立私有連線：

undefined

• 使用私有 IP 佈建代管服務。

• 維運注意事項：

  • 此範圍必須夠大以容納所有執行個體，且不得與現有範圍重疊。
  • 此對等互連不具遞移性；流量必須源自對等互連的 VPC (如果路由允許，地端可以透過該 VPC 存取)。
  • 日後變更或縮小範圍會造成服務中斷；請妥善規劃容量。

Private Service Connect (PSC) 將私有連線能力擴展至：

• Google API (消費者在子網路中建立帶有私有 IP 的端點，並由 DNS 將 API 名稱對應到這些 IP)。
• 透過服務連結發布的合作夥伴和 SaaS 服務。
• 透過服務連結私下發布給其他專案或組織的您自己的服務。

生產者－消費者模型：

• 生產者在某個區域中發布一個由內部負載平衡器支援的服務連結。生產者可以要求消費者的專案/組織加入允許清單，並指定連線配額。
• 消費者在同一區域中建立一個 PSC 端點 (轉送規則)，指向生產者的服務連結。該端點會從所選的子網路中取得一個 IP。

設計限制與權衡：

• PSC 是區域性的；應在靠近消費者的每個區域進行部署。使用 DNS 政策或加權記錄來引導鄰近的用戶端並提供故障轉移。
• PSC 不具遞移性；消費者無法透過一個端點串連多個服務。
• 來源 IP 在 PSC 的端對端傳輸中不會被保留；在設計生產者端的控制措施時應考慮到這一點 (例如，依賴身分或應用程式層級的授權)。

常見的失敗模式：

• 生產者的 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 對應涵蓋了用戶端使用的所有名稱。
• 邊界設定錯誤時採阻斷式設計 (fails closed)；請監控 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 anycast VIP 的特定主機路由，以確保 PGA 繞過防火牆。對於非 Google 的目的地，根據政策傳送到 NGFW 或 Cloud NAT。

混合雲用戶端 (地端或其他雲端)：

• 若要私密地使用 Google API：
  • 選項 A：透過 Private Google Access for on-premises，從 Cloud Router 向地端公告 199.36.153.4/30 及/或 199.36.153.8/30，並將 VPC 中的下一躍點設為預設網際網路閘道；視需求將地端 DNS 對應至 restricted/private.googleapis.com。
  • 選項 B：在您的 VPC 中為 Google API 建立 PSC 端點；透過 Cloud VPN/Interconnect，將路由指向端點 IP 並相應地對應地端 DNS，以供外部存取。
• 若要連線到具有私有 IP 的 Google 代管服務 (透過 PSA)，需建立與 VPC 的連線 (Cloud VPN/Interconnect)，確保 RFC1918 範圍不重疊，傳播路由，並允許防火牆規則。

疑難排解與驗證：

• DNS：從用戶端 dig 或 nslookup API 主機名稱，並驗證它是否解析為預期的私有位址 (PSC 端點 IP) 或 restricted/private anycast VIP。檢查 VPC 上的 Cloud DNS 政策順序與私有區域。
• 路由：執行

undefined

並確認最明確的路由符合預期的下一躍點 (PGA VIP 為預設網際網路閘道，PSC 為內部躍點)。

• 防火牆：驗證輸出規則是否允許 TCP 443 連線至目標 IP。對於 PSC 後方的負載平衡生產者，請驗證是否已允許健康狀態檢查的來源範圍。
• PGA：確認子網路設定已啟用，且在有自訂預設路由的情況下，存在指向 199.36.153.4/30 及/或 199.36.153.8/30 的主機路由。
• PSA：執行

undefined

以確認 servicenetworking 對等互連為 ACTIVE 狀態，且分配的範圍正確且未在其他地方使用。

• PSC：在消費者端，描述端點以查看連線狀態；在生產者端，檢查待處理或已拒絕的連線以及 ILB 的健康狀態。驗證服務附件的消費者允許清單。
• Cloud NAT：使用 NAT 記錄與指標來確認轉譯情況，並檢查通訊埠的分配或耗盡情形。如果執行個體有外部 IP，其設計上會繞過 NAT。

實際問題情境

Contoso 研究中心在兩個地區 (us-east1, europe-west1) 執行分析作業。安全性強制規定任何 VM 都不能有公用 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 的主機路由，下一躍點為預設網際網路閘道。
• 理由：確保 VM 到 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. 保留 Cloud NAT 用於非 Google 的網際網路輸出

• 行動：部署依區域劃分的 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 →