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

課程概述

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

Gemini Cloud Assist 可以協助查詢網路設定、解釋結果和草擬最小變更，Network Intelligence Center 也提供自然語言 Flow analyzer。不過 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 和既有網路工具逐步查證。

實作重點

• 保存 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
• 修復後使用原本五元組重測，再加一組不該被允許的負向測試，確認沒有過度放寬

Skill Badge 指引

Lab 連結：Gemini for Network Engineers — Google Cloud Skills Boost

Lab 裡每遇到一個連線問題，先寫五元組和預期路徑，再看 Gemini。跑完 Connectivity Tests 後，另外找一個目的服務健康或 DNS 的反例，練習分辨「設定可達」和「應用真的可用」。

延伸學習

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