Google PCNE: 路由、Network Connectivity Center 與分割 — 學習指南
屬於 Google Professional Cloud Network Engineer — 學習指南. 使用經過驗證的解答練習： Google 考試中心, 或參加限時模擬考試： ExamRoll.io.
總覽
本節說明 Google Cloud 中的路由、Network Connectivity Center (NCC) 以及區隔模式。內容著重於路由如何建立與選取、如何在保持隔離的同時互連 VPC 與組織、如何建構可擴展的傳輸 (transit) 與服務插入 (service-insertion) 設計，以及如何驗證並控制故障範圍。
路由基礎與控制
路由類型
- 系統產生的子網路路由：每個主要和次要子網路範圍各一條；因其精確的前綴，永遠具有最高優先權。
- 前往網際網路閘道的預設路由：在新 VPC 中自動建立；可以移除或覆寫。
- 靜態路由：自訂前綴，其下一躍點 (next hop) 可為預設網際網路閘道、特定執行個體、作為下一躍點的內部 TCP/UDP 負載平衡器 (ILB)，或 Cloud VPN 通道。政策式路由則新增了比對條件 (標籤、服務帳戶、通訊協定/通訊埠)，並將流量導向執行個體或 ILB 下一躍點，以實現進階的服務插入。
- 動態路由：透過 Cloud Router，經由 BGP 從 Cloud VPN 或 Cloud Interconnect 學習而來。其範圍由 VPC 的動態路由模式 (區域性或全域性) 控制。
路由選取
- 優先採用最長前綴相符 (Longest prefix match)。
- 若多個路由具有相同的前綴長度，則以數值最低的路由優先順序為準 (自訂路由預設為 1000)。應避免在靜態/動態路徑之間出現相同前綴的重疊；設計時應明確偏好其中一條路徑。
- 優先順序相同時，會由平台內部的決勝機制解決；請勿依賴此機制。
下一躍點的選擇與服務插入
- 若要集中化輸出流量 (egress) 或插入 L3/L7 服務，可將一條 0.0.0.0/0 靜態路由或政策式路由指向一個 ILB 下一躍點，其後端為網路虛擬設備 (NVA)。
- 當沒有外部 IP 的執行個體需要繞過設備存取 Google API 時，請在子網路上啟用 Private Google Access，並為已發布的 Google API VIP 範圍新增自訂靜態路由，指向預設網際網路閘道。這樣可以在其他輸出流量遵循 NGFW 路徑的同時，保留對 Google 服務的私人存取。
動態路由模式與多地區行為
- 區域性 (Regional)：Cloud Router 學習到的路由僅會安裝到相同地區的子網路。
- 全域性 (Global)：在任何地方學習到的路由都會安裝到 VPC 中的所有地區，從而實現簡單的多地區連線，並降低 hub-and-spoke 設計的維運負擔。對於靠近 us-east1 和 europe-west1 的使用者和工作負載，單一 VPC 搭配區域性子網路和全域動態路由，能讓他們透過 RFC1918 進行私密通訊，並達到最佳效率。
路由通告控制
- Cloud Router 可以向地端 (on-premises) 通告所有子網路或一組自訂前綴 (包含預設路由)。可使用標準 BGP 工具 (MED、AS-path prepending、地端的 local preference) 來控制傳入地端的路徑選擇。對於指向地端的主動/備援 (active/standby) 設定，請在主要路徑上設定較低的 MED，並在備援路徑上設定較高的 MED。
- 避免從具有不同 ASN 的不同地端對等體 (peer) 向同一個 Cloud Router 通告相同的前綴；為了實現雙主機 ECMP 或乾淨的容錯移轉，請在備援的地端路由器上使用相同的對等體 ASN。
VPC 互連與區隔
VPC 網路對等互連 (VPC Network Peering)
- 可在 VPC 之間實現低延遲的私有 RFC1918 連線，且無需資料平面設備。它預設會交換子網路路由，並可選擇性地匯入/匯出客製化路由 (靜態和動態)，以將連線能力擴展到 Cloud VPN/Interconnect 後方的資源。沒有傳輸路由 (transitive routing)：從一個對等體學習到的路由不會再匯出到另一個對等體。
- 故障模式與限制：CIDR 不可重疊；每個 VPC 的防火牆規則各自獨立；頻寬雖高但不能替代負載平衡器；不支援跨網狀對等互連的非對稱路由。若要以三角形方式連接三個 VPC，需設定一個完整的網狀對等互連配對；Sales↔Finance 和 Marketing↔Finance 的連線並不會啟用 Sales↔Marketing 之間的連線，除非這兩者之間也建立了對等互連。
- 位址規劃：當與一個自動模式 VPC (會保留 10.128.0.0/9) 進行對等互連時，請將對等 VPC 建立為自訂模式，並使用不重疊的 CIDR，例如 10.0.0.0/9。
共用 VPC (Shared VPC) 與多專案連線
- 由一個主機專案 (host project) 擁有 VPC；服務專案 (service projects) 則附加到選定的子網路。這種方式集中了網路和混合雲連線 (Cloud Routers、Cloud NAT、Interconnect)，同時允許將應用程式的所有權委派給各個專案。將 Dedicated Interconnect 的 VLAN 附件和 Cloud Router 放置在主機專案中，以便為所有服務專案提供具成本效益且集中式的地端連線。
- 最小權限：網路管理員 (Network Admins) 管理路由和子網路；安全管理員 (Security Admins) 管理防火牆規則和政策。如果您以網路管理員身分無法更新防火牆，請在共用 VPC 範圍內請求安全管理員權限。
- 區隔：僅分享服務專案所需的特定子網路。這符合 Google 的最佳實踐，即嚴格控制生產 (Production) 和預備 (Staging) 環境之間的路由暴露。
網路隔離控制
- VPC 邊界：若無明確的對等互連、VPN 或 Private Service Connect，VPC 之間無法路由。對於必須完全隔離的部門或租戶，請使用獨立的 VPC；僅對需要連線的 VPC 進行對等互連，以最小化維運負擔。
- 防火牆政策：在組織/資料夾層級使用階層式防火牆政策以建立一致的防護機制，並使用個別 VPC 的規則處理本機例外情況。預設的傳入拒絕/傳出允許 (ingress deny/egress allow) 規則可以收緊。
- 邊界 (Perimeters)：使用 VPC Service Controls 來限制對 Google API 的存取，並降低跨專案和網路的資料外洩風險。
- IPv6 暴露：若要進行公開的 IPv6 存取，請將 IPv6 指派給位於您服務前端的全域外部 HTTP(S) 負載平衡器。後端則保持私有。
營運：驗證、分析與中斷圍堵
連線能力驗證與路由分析
- 使用 Network Intelligence Center 的 Connectivity Tests 來追蹤跨 VM、負載平衡器、VPC peering、Cloud VPN 和 Interconnect 的資料路徑，以驗證防火牆規則和路由。
- 分析每個 VM/子網路的有效路由，以確認 next hop 和動態前綴；驗證動態路由模式的範圍是否符合預期。
- 對於效能或使用者體驗問題，應優先選用全球 HTTP(S) 負載平衡，透過 anycast ingress 和邊緣終止來降低全球使用者的延遲；網路負載平衡器是區域性的，無法改善全球延遲。
中斷圍堵與爆炸半徑縮減
- 透過 VPC、NCC 路由表和每個專案的 Shared VPC 子網路進行分割，以防止故障或設定錯誤的意外擴散。
- 避免透過 peering 產生傳遞性依賴；當需要傳輸時，使用 NCC 和受控的匯入/匯出以限制可達性。
- 使用集中式的組織層級防火牆政策來設定基準的拒絕/允許規則，並使用本地政策來處理應用程式的例外情況；使用 Connectivity Tests 測試變更。
- 當需要 inline 安全性時，部署具有健康狀態檢查和 policy-based routing 的 next-hop ILB，以實現優雅的容錯轉移。確保關鍵的 Google API 可透過 Private Google Access 或 Cloud NAT 存取，而不依賴外部 IP。
- 監控 BGP session 和路由變更；標準化指標 (MED, local preference) 和位址規劃，以避免路由震盪和非對稱流量。
簡短設定範例
建立一條靜態路由，將流量導向一個 inline ILB：
undefined
使用 MED (在地端路由器上) 讓傳入地端的流量優先選擇兩條 BGP 路徑之一：
undefined
實務問題情境
Acme Retail 在一個多專案的 Google Cloud 組織中營運，其使用者群分佈在 us-east1 和 europe-west1 附近。他們需要在跨區域的工作負載之間進行私有、低成本的通訊，集中式的地端連線，以及用於網際網路出口的 inline URL 過濾，同時保持財務部門與工程部門的隔離。
- 在一個 host project 中建立單一的 Shared VPC，並在 us-east1 和 europe-west1 中設定區域性子網路，然後將動態路由模式設為 global。
- 理由：單一 VPC 能夠在區域之間實現直接的 RFC1918 通訊，無須 peering 的額外負擔。Global 動態路由會將學習到的混合雲路由安裝到所有區域，從而簡化營運並確保高效的 VPC 內部流量。
- 僅將必要的子網路分享給每個 service project；將財務和工程部門放在不同的 service project 中。
- 理由：子網路層級的分享提供了組織上的分割，並將意外的路由暴露降至最低。只要不分享工程部門的子網路，並透過獨立的防火牆政策範圍，就能讓財務部門保持隔離。
- 在 host project 中終止 Dedicated Interconnect 並附加 Cloud Routers；使用自訂宣告僅宣告必要的前綴。
- 理由：集中式的混合雲連線降低了成本和複雜性，同時保有對哪些流量能到達地端的控制權。自訂宣告可防止過度暴露並圍堵爆炸半徑。
- 在一個區域性的 internal TCP/UDP 負載平衡器後面插入一個 inline L7 URL 過濾設備；在每個區域中使用一條 0.0.0.0/0 靜態路由，將出口流量導向 ILB next hop。
- 理由：ILB next hop 加上健康狀態檢查，提供了具有對稱流量的高可用性服務插入。比預設路由更高優先級的靜態路由，確保所有出口流量都經過過濾。
- 確保沒有外部 IP 的執行個體可以直接存取 Google API：在所有子網路上啟用 Private Google Access，並為 Google API 的 VIP 範圍新增指向預設網際網路閘道的靜態路由，以繞過過濾設備。
- 理由：Private Google Access 保留了對 BigQuery 和 Pub/Sub 的私有存取；自訂路由可防止不必要的流量髮夾彎 (hairpinning) 穿過過濾器，從而降低成本和延遲。
- 保持財務部門的隔離：在階層式防火牆政策中拒絕跨專案的流量，並且不要在財務和工程部門之間設定 peering。當需要工程↔分析部門協作時，建立一對專用的 peered VPC，並使用不重疊的 CIDR。
- 理由：VPC 邊界、不設定 peering，以及組織層級的防火牆政策強制執行隔離。針對特定部門間的連線，目標性的 peering 提供了低營運負擔的解決方案，且不具傳遞性。
- 驗證與監控：使用 Connectivity Tests 來驗證跨區域的可達性和設備插入；監控 Cloud Router 的 BGP 健康狀態和路由表；如果存在多個通道，則在地端路由器上實作 MED 以進行 active/standby 容錯轉移。
- 理由：主動驗證能及早發現設定錯誤。BGP 控制能在維護或故障期間保持地端路徑的確定性，而 NCC/Cloud Router 的遙測資料則能加速故障排除。
此設計以最低的成本和高效率滿足了 Acme Retail 的需求：在單一 VPC 中實現私有多區域路由、集中式混合雲連線、受控的服務插入，以及強大的組織分割。
← 對 Google 與代管服務的私密連線 · 所有領域 · GKE、容器與應用程式網路 →
練習這些題目 → · 在 ExamRoll.io 上限時練習 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通過考試 →