Gemini Cloud Assist 網路除錯：先畫封包路徑

課程概述

「A 連不到 B」不是一個夠完整的網路問題。你至少要知道來源、目的、Protocol、Port、時間、預期路徑和最近變更，才能沿著 DNS、路由、防火牆、NAT、Load Balancer、VPN／Interconnect 和目的服務逐跳找證據。

Gemini Cloud Assist 可以協助查詢網路設定、解釋結果和草擬最小變更，Network Intelligence Center 的 Flow Analyzer 也能用自然語言產生查詢 VPC Flow Logs 的 SQL（這是 Gemini Cloud Assist 的功能，目前 Preview）。不過 AI 不會替你看到所有封包；它能用的證據取決於權限、已啟用的 API、Log 和監控資料。先把問題變成可重現的封包路徑，再請它幫忙，診斷才不會變成猜題。

你將學到

• 用五元組和時間窗口把模糊症狀變成可測問題
• 規劃不與未來 GKE、受管服務和混合雲重疊的 CIDR
• 分辨路由、防火牆、NAT、DNS 與應用層失敗
• 正確解讀 Connectivity Tests 的設定分析與限制
• 將 Gemini 產生的規則視為候選 Diff，經模擬、Review 和回滾設計後才套用

CIDR 要畫整個位址版圖，不只算現在 VM

規劃時要把下列範圍放在同一份 IPAM 或登錄表：

• 每個環境、Region 和 Subnet 的 Primary range
• GKE Pod 與 Service secondary ranges，以及成長預留
• Private Service Access、Private Service Connect 和受管服務範圍
• 地端、VPN、Interconnect、Peering、NCC 和合作夥伴網路
• 未來併購、災難復原、測試環境與 IPv6 規劃

Gemini 可以協助計算 Prefix 和列出重疊，但輸入若漏掉一個未來可互連網路，結果就可能從數學正確變成架構錯誤。

先寫出封包的五元組

一次 Connectivity Test 或 Log 查詢，至少固定：

• Source IP／Instance／Service account 或 Endpoint
• Destination IP／FQDN／Load Balancer／Managed service
• Protocol 與 Destination port
• 發生時間、頻率和是否只影響特定 Zone／使用者
• 預期經過的 VPC、Peering、VPN、Interconnect、NAT 或 Proxy

如果目的端是 FQDN，先保存當下 DNS 解析結果；如果來源會經 Cloud NAT 或 Proxy，也要分清楚應用看到的來源和網路政策實際比對的來源。

防火牆規則要看完整政策，不只新增一條 Allow

Google Cloud 防火牆判斷會受到 Direction、Priority、Scope、Target、Source／Destination、Protocol／Port，以及 Hierarchical、Global／Regional Network Firewall Policy 和 VPC firewall rules 共同影響。AI 產生規則後要檢查：

• 能不能用 Service account 或 Secure Tag 縮小 Target，而不是開整段 CIDR
• 是否有更高優先序的 Deny／Allow 改變結果
• Ingress 和 Egress 是否都已考慮，Return traffic 是否依 Connection tracking 放行
• Logging 是否開在需要追蹤的規則上，保存量和成本是否合理
• 變更會不會誤開管理 Port、跨環境或 Internet 路徑

不要把「允許某 Subnet 連 Cloud SQL 5432」直接翻成一條萬用 Firewall rule。Cloud SQL 連線方式可能是 Public IP、Private IP、PSC 或 Connector，實際路徑和授權方式不同，先畫路徑再決定控制。

Flow Logs、Firewall Logs 和 Connectivity Tests 各看不同事情

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

Connectivity Tests 的設定分析不代表真實 Data plane 狀態；Live analysis 也只支援部分路徑。看到 Packet could be delivered 後，還要測 DNS、TLS、Service listening、Host firewall、Health check 和應用依賴。

Gemini Cloud Assist 要吃證據，不要吃結論

與其問「為什麼網路壞了」，可以提供：

2026-08-21 10:05–10:15，Project A 的 VM 10.10.1.5 連 Project B 內部 LB 10.20.0.8:443 逾時；DNS 已解析正確，Connectivity Test 結果為 UNREACHABLE，附 Trace、有效 Route 和最近 Firewall Policy Diff。請把事實和推論分開，列出最可能的三個阻斷點，以及每個要再查的證據；先不要產生修改指令。

如果使用 Investigations，要注意目前是 Preview，而且 2026 年 4 月 10 日後建立、執行與編輯調查只開放給 Premium Support 或透過 Account team 取得存取的使用者。沒有這項資格時，仍可用 Chat、Flow analyzer 和既有網路工具逐步查證。

%%{init: {"flowchart": {"curve": "linear", "nodeSpacing": 20, "rankSpacing": 28, "wrappingWidth": 600}}}%%
flowchart TB
  subgraph DEFINE_STAGE["1. 固定可重現路徑"]
      direction LR
      SYMPTOM["記錄錯誤、時間、頻率<br/>和最近變更"] --> TUPLE["固定來源、目的、Protocol<br/>Port 與預期路徑"]
      TUPLE --> DNS{"FQDN 在發生當下<br/>解析到正確位址嗎？"}
      DNS -->|"否"| DNS_FIX["查 DNS Zone、Policy<br/>Cache、Split horizon 與 TTL"]
  end
  DNS -->|"是"| ROUTE
  subgraph NETWORK_STAGE["2. 沿設定與封包路徑逐跳查"]
      direction LR
      ROUTE{"有效 Route、Peering、VPN<br/>或 Interconnect 路徑正確嗎？"} -->|"否"| ROUTE_FIX["修正 Route、Advertisement<br/>Overlap 或 Tunnel 狀態"]
      ROUTE -->|"是"| FIREWALL{"階層與 VPC Firewall<br/>對此五元組會放行嗎？"}
      FIREWALL -->|"否"| FW_FIX["找出實際命中政策<br/>草擬最小範圍變更"]
      FIREWALL -->|"是"| MIDDLE["檢查 NAT、LB、PSC<br/>Proxy 與 Return path"]
  end
  MIDDLE --> SERVICE
  subgraph SERVICE_STAGE["3. 驗證服務，再做最小修復"]
      direction LR
      SERVICE{"目的 Process、TLS、Health check<br/>和 Host firewall 都正常嗎？"} -->|"否"| APP_FIX["交給服務 Owner 修復<br/>不要誤改網路放寬權限"]
      SERVICE -->|"是"| PLAN["整理 Trace、Log 和候選根因<br/>Plan／Review 最小變更"]
      PLAN --> RETEST["套用後重跑同一測試<br/>監控副作用並保留回滾"]
  end

實作重點

• 保存 Connectivity Test Trace 和發生時間，不只截一張 Overall result
• Flow Logs 先確認 Sampling、Aggregation、Metadata 和 Log scope，再解讀「沒有記錄」
• Firewall 變更使用 Policy／Rule 的完整 Diff，檢查 Priority、Target、Direction 和 IPv4／IPv6
• VPN／Interconnect 同時看 Tunnel／Attachment、Cloud Router、BGP Session、Advertised／Learned routes 和地端狀態
• Gemini 產生的 gcloud 或 Terraform 先在 Test Project／Plan 驗證，不直接貼到 Production Shell
• 修復後使用原本五元組重測，再加一組不該被允許的負向測試，確認沒有過度放寬

Lab 指引

Lab 連結：Gemini for Network Engineers — Google Skills

依課程頁，這門課有兩段影片、一個測驗和一個 Lab「Creating a VPC Network with Gemini」，Lab 說明寫的是在兩個網路之間設定 VPC Network Peering，再驗證兩台 VM 的私有通訊。驗證連線前先寫五元組和預期路徑，再看 Gemini；做完後可以自己延伸，對同一條路徑跑一次 Connectivity Tests，另外找一個目的服務健康或 DNS 的反例，練習分辨「設定可達」和「應用真的可用」。

延伸學習

• GCP PCA：VPC 網路架構 — 系統理解 Shared VPC、Peering 與混合連線
• Gemini 輔助資安工程師 — 從安全事件與政策角度查網路證據
• Gemini Cloud Assist 給架構師 — 把網路修改放回架構取捨與 ADR
• Connectivity Tests 概觀 — 查閱支援路徑、分析方式與限制