連線測試與網路智慧中心

連線測試與 Network Intelligence Center 簡介

Connectivity Tests 是 Google Cloud Network Intelligence Center（NIC） 內建的診斷引擎，用來回答一個看似簡單的問題：「從來源 A 出發的封包能否抵達目的地 B？如果不行，到底是哪一條設定把它丟掉的？」它結合了「靜態分析器」（讀取 Andromeda 控制平面所使用的同一份路由、防火牆、NAT、負載平衡器中繼資料）與選用的「即時資料平面探測」（注入少量測試封包並觀察結果）。在 Professional Cloud Network Engineer（PCNE）考試中，你必須知道何時要用 Connectivity Tests 取代 tcpdump、如何解讀封包追蹤，以及 NIC 四大支柱（Connectivity Tests、Performance Dashboard、Firewall Insights、Network Topology）如何與 VPC Flow Logs 及 Network Analyzer 互相搭配。

本筆記會走過端點建模、考試常考的每一個封包追蹤丟棄原因、NIC 的 Reachability Analyzer 介面、Network Analyzer 發現項目、在 BigQuery 中分析 VPC Flow Logs、Performance Dashboard 的跨區延遲檢視，以及資深工程師在 SSH 進 VM 之前就會跑過的疑難排解流程。

白話文解釋（Plain English Explanation）

在深入 GCP 上的 Connectivity Tests 之前，先用三個具體畫面把取捨講清楚。

把 Connectivity Tests 想成機場的飛行前檢查員

飛行員不會啟動引擎就指望跑道是淨空的。飛行前檢查員會繞著飛機走一圈、核對艙單、核對航路天氣、核對加油紀錄，並在起飛前預先放行航班會經過的每一個閘門。Connectivity Tests 對 GCP 上的 TCP／UDP／ICMP 封包扮演的正是這個角色。在你部署工作負載之前，你描述飛行計畫（「us-central1 的 VM 飛到 us-east1 的私有 Cloud SQL，目的埠 5432」），檢查員會讀機場藍圖（VPC 路由、防火牆規則、Peering 政策、Private Service Connect 端點、NAT 對應）來認證這條航路。如果某個閘門關著，檢查員會在飛機離開停機坪之前，用名字告訴你是哪個閘門。

把封包追蹤丟棄原因想成護照上的海關戳章

當包裹跨境時，海關會在每一次退件上蓋上原因戳章：「MISSING_DECLARATION」、「PROHIBITED_GOODS」、「INSPECTOR_ABSENT」。每個戳章都精確告訴你是哪個機構退件、要修哪一處。Connectivity Tests 蓋的就是同一種戳章。DROPPED_DUE_TO_NO_ROUTE 表示路由表裡沒有目的子網路的對應條目；FIREWALL_BLOCK 表示隱含拒絕或明確拒絕規則觸發；INSTANCE_NOT_RUNNING 表示 VM 已停機；LOAD_BALANCER_HAS_NO_BACKEND 表示後端服務沒有健康後端。一看到戳章，你就知道要找哪個團隊。

把 Network Intelligence Center 四大支柱想成醫院的科別

醫院不會只有一間巨大的「醫療室」，而是分成心臟科、放射科、藥劑科和急診室，各自專精。NIC 的結構也是如此。Connectivity Tests 是急診室：你滿身是血進來，它告訴你哪一條動脈被切斷。Network Topology 是放射科：它畫出即時的流量解剖圖，讓你看清網路的構造。Firewall Insights 是藥劑科：它稽核哪些處方（規則）沒在用、過於寬鬆、或可能很快會用到。Performance Dashboard 是心臟科：它量測跨區之間的延遲與封包遺失，讓你能在全球範圍內發現心律不整。每個支柱共享同一份病歷（你的網路設定與遙測），卻回答不同的臨床問題。

Connectivity Tests 的核心概念

NIC 文件與 PCNE 考題裡會反覆出現幾個術語，必須精確掌握。

靜態設定分析（Static Configuration Analysis）

靜態分析器讀取的是 Google Andromeda 控制平面用來編程資料平面的同一份中繼資料：VPC 路由（subnet、static、Cloud Router/BGP 學到的 dynamic、peering）、防火牆規則與防火牆政策（hierarchical、network、regional）、Cloud NAT 對應、Cloud Load Balancing 轉發規則與後端服務、Private Service Connect 端點、VPN 通道、Interconnect attachments、PSC 消費者／生產者設定。它從來源到目的地逐步走過路徑，回傳 REACHABLE、UNREACHABLE、AMBIGUOUS 或 UNDETERMINED。這個模式不會發送任何實際封包。

即時資料平面分析（Live Data Plane Analysis）

啟用 「測試即時資料平面」 選項（gcloud network-management connectivity-tests rerun 的 --include-data-plane-analysis 旗標）時，Connectivity Tests 會向實際的 Andromeda Fabric 注入少量探測封包，並觀察追蹤結果。這能抓出設定意圖與運行中資料平面之間的歧異（例如靜態分析器看不到的過期 BGP 廣播）。探測封包數量有限（通常每方向 3–5 封），對生產流量無可量測的影響。

來源與目的端點（Source / Destination Endpoints）

端點可以是 VM instance 參照、內部／外部 IP 位址、GKE Pod 或 Service、Cloud Run revision、Cloud SQL 實例、Cloud Load Balancing 轉發規則、Network Attachment，或地端閘道（以 IP + 網路名稱建模）。端點可包含 port、protocol 與 networkType（gcp-network、non-gcp-network）。指定錯誤的端點型別，是測試回傳 UNDETERMINED 最常見的原因。

Trace 與封包追蹤原因

Trace 是封包會走過的步驟序列：INSTANCE → FORWARDING_RULE → VPC_NETWORK → ROUTE → FIREWALL_RULE → DELIVER（或 DROP）。每一步都記錄一個判定；對於被丟棄的封包，最終判定就是 drop reason，取自一個固定列舉值，PCNE 考試特別愛直接考。

Reachability Analyzer

在 console 裡，Connectivity Tests 的 UI 有時稱為 Reachability Analyzer，引擎相同，名稱比較友善。API 資源是 connectivityTests；gcloud 介面是 gcloud network-management connectivity-tests。

Network Analyzer

與 Connectivity Tests 不同，Network Analyzer 是一個永遠開啟、可選擇退出的服務，會主動掃描 VPC 設定中的錯誤，並以 findings（發現項目）的形式呈現。它能抓到你沒想到去測試的偏移。

考試必認的封包追蹤丟棄原因

PCNE 考試經常給你一段 trace，問你要修什麼。Drop reason 列舉值不多，足以背下來。

DROPPED_DUE_TO_NO_ROUTE

該步驟檢查的路由表中沒有可匹配目的 IP 的前綴。可能原因：刪除預設 Internet 路由後沒有補上 custom static route、對等的 VPC 沒有匯出 subnet routes、Cloud Router 還沒透過 BGP 學到路由，或使用 Network Connectivity Center 的 hub-and-spoke 設計中 spoke 落在不同 routing region。

FIREWALL_BLOCK 與 FIREWALL_RULE

封包命中拒絕規則，或在隱含拒絕入站／隱含允許出站基準下沒有任何允許規則命中。Trace 會引用確切的防火牆規則名稱與優先序。若引用的是 default-deny-ingress，代表你這個 tuple 完全沒有放行規則；若是命名的明確拒絕，多半是順序或優先序問題。

INSTANCE_NOT_RUNNING

目的 VM 處於 STOPPED、TERMINATED 或 SUSPENDED。修起來很便宜，但在盯著防火牆一小時後才發現會很尷尬。

LOAD_BALANCER_HAS_NO_BACKEND

轉發規則設定完成，但後端服務沒有任何健康後端。可能是健康檢查失敗、空的 managed instance group、或後端 bucket 沒有權限。

PRIVATE_GOOGLE_ACCESS_DISALLOWED

來源子網路嘗試連線 *.googleapis.com 的私有 VIP（199.36.153.4-11），但子網路未啟用 Private Google Access，或 DNS 解析沒有指向私有路徑。

CLOUD_NAT_NO_ADDRESSES 與 CLOUD_NAT_PORT_EXHAUSTION

Cloud NAT 閘道用盡了配發的外部 IP，或耗盡了來源埠 tuple。修正方式：提高 minPortsPerVm、改用 dynamic port allocation 或新增 NAT IP。

TRAFFIC_TYPE_BLOCKED_BY_FIREWALL_POLICY

階層式防火牆政策（資料夾或組織層級）在任何 VPC 層規則執行前就先拒絕了流量。Trace 會顯示政策名稱與規則優先序。

NO_KNOWN_ROUTE_FROM_PEERED_NETWORK_TO_DESTINATION

VPC Network Peering 已建立但目的子網路沒有被匯出。切換 peering 的 exportSubnetRoutesWithPublicIp 與 exportCustomRoutes，或檢查 Private Service Connect peering 設定。

Network Intelligence Center 四大支柱

NIC 在 console 的同一個標題下整合了四個互補工具，考試會要你針對情境挑選對的支柱。

Connectivity Tests（Reachability Analyzer）

反應式 + 主動式的路徑驗證工具。針對 你能命名的一組特定來源－目的 使用。輸出 trace 與可達性判定。

Performance Dashboard

永遠開啟，呈現每一組 Google Cloud 區域之間以及你的 VM 與 Google edge 之間的 延遲與封包遺失。可看過去 7 天的 p50／p95／p99。當症狀是延遲而非可達性時使用。

Firewall Insights

分析 防火牆規則使用情形（預設視窗 24 小時，最長 6 週）。回報未使用規則、被遮蔽的規則（高優先序規則完全覆蓋低優先序規則，使後者變死碼）、過於寬鬆的規則（針對敏感埠允許 0.0.0.0/0）、以及近期被拒絕流量會命中的規則。

Network Topology

過去 6 週 VPC 實體與流量邊的即時視覺化圖。顯示 VM、GKE clusters、Cloud SQL、負載平衡器、Cloud NAT 閘道、peering，以及彼此之間的位元數／封包量。在重構之前用它了解「誰跟誰在說話」。

端點建模與測試設定方式

一個連線測試由來源、目的、protocol 及（可選）port 定義。端點可用多種方式描述，建模正確就成功一半。

來源端點型別

• VM instance：以 projects/{p}/zones/{z}/instances/{name} 參照；測試會綁定指定 NIC 上的主要或別名 IP。
• GKE workload：Pod IP 或 Service ClusterIP；測試會走 GKE 網路外掛的路徑。
• Cloud Run / Cloud Functions：以 revision URL 指定；若已設定 serverless VPC connector，測試會走該路徑。
• 內部 IP：自由輸入 IP 加 VPC network 參照；適用於非受管工作負載。
• 外部 IP / FQDN：模擬來自公開網際網路的入站流量。
• 地端：IP 加 non-GCP network 標籤；分析器在 VPN／Interconnect 邊界停止，並把其餘部分標記為 AMBIGUOUS。

目的端點型別

清單與來源相同，外加 Cloud Load Balancing 轉發規則、Cloud SQL 實例（私有路徑）、Private Service Connect 端點，以及 Producer 端 PSC 的 Network Attachment。

gcloud 範例

gcloud network-management connectivity-tests create web-to-sql \
  --source-instance=projects/p1/zones/us-central1-a/instances/web-vm \
  --destination-cloud-sql-instance=projects/p1/instances/orders-db \
  --destination-port=5432 \
  --protocol=TCP \
  --include-data-plane-analysis

重新執行測試

設定每天都在變。測試不會自動重跑。透過 Cloud Scheduler 加 Cloud Functions 安排 gcloud network-management connectivity-tests rerun，或直接從部署流水線呼叫 API。常見作法是在 CI 中於 Terraform 升版前重跑測試。

Network Analyzer 發現項目與呈現方式

Network Analyzer 持續掃描 VPC，並把發現項目以類別 NETWORK_ANALYZER_INSIGHT 發布到 Recommender API。發現項目依嚴重度（CRITICAL、HIGH、MEDIUM、LOW）與生命週期狀態（ACTIVE、RESOLVED、MUTED）分組。

常見發現項目

• IP 使用率過高：subnet 已配發超過 80%，新 VM 將可能無法建立。
• MTU 設定不佳：VPC MTU 與 VPN／Interconnect 對端不符，導致分片。
• 非對稱路由：BGP 只在單向廣播前綴。
• VPN 通道斷線或抖動：包含最後一次 IKE 失敗原因。
• 未使用的外部 IP：預留的 static IP 未掛載到任何資源卻持續計費。
• 對等 VPC 子網路重疊：會悄悄打壞可達性。
• GKE node pool IP 即將耗盡：預估 secondary range 將在 N 天內填滿。

取得發現項目

發現項目顯示在 NIC console 的 「Network Analyzer」分頁，也可用 gcloud recommender insights list --recommender=google.networkanalyzer.vpcnetwork.connectivityInsight 取得。透過 Eventarc 把 critical 發現項目導入 Pub/Sub topic 以觸發自動呼叫。

VPC Flow Logs 與 BigQuery 分析

VPC Flow Logs 是每個 VM NIC 以可設定的取樣率（預設 0.5 = 50% 流量）與彙總間隔（預設 5 秒）發出的每 5-tuple 流量樣本。它是 Connectivity Tests 即時資料平面判定背後的原始證據，也是大多數正式環境疑難排解流程的輸入。

啟用 Flow Logs

Flow Logs 以子網路為單位啟用：gcloud compute networks subnets update SUBNET --enable-flow-logs --logging-aggregation-interval=INTERVAL_5_SEC --logging-flow-sampling=0.5 --logging-metadata=INCLUDE_ALL_METADATA。紀錄會落在 Cloud Logging 的 logName=projects/.../logs/compute.googleapis.com%2Fvpc_flows。

將 Flow Logs 導入 BigQuery

建立目的地為 bigquery.googleapis.com/projects/{p}/datasets/network_logs 的 Cloud Logging sink，過濾條件 resource.type="gce_subnetwork"。每日分區資料表讓 30 天保留期的查詢成本可控。

實用 BigQuery 查詢

最近一小時 top talkers：

SELECT
  jsonPayload.connection.src_ip AS src,
  jsonPayload.connection.dest_ip AS dst,
  SUM(CAST(jsonPayload.bytes_sent AS INT64)) AS bytes
FROM `proj.network_logs.compute_googleapis_com_vpc_flows_*`
WHERE _TABLE_SUFFIX = FORMAT_DATE('%Y%m%d', CURRENT_DATE())
  AND TIMESTAMP_DIFF(CURRENT_TIMESTAMP(), timestamp, MINUTE) < 60
GROUP BY src, dst
ORDER BY bytes DESC LIMIT 50;

針對敏感子網路的拒絕連線嘗試：

SELECT timestamp, jsonPayload.connection.src_ip, jsonPayload.connection.dest_port
FROM `proj.network_logs.compute_googleapis_com_vpc_flows_*`
WHERE jsonPayload.reporter = "DEST"
  AND jsonPayload.dest_vpc.subnetwork_name = "payments-subnet"
  AND jsonPayload.disposition = "DENIED"
ORDER BY timestamp DESC LIMIT 200;

把 Flow Logs 與 Connectivity Tests 一起用

Connectivity Tests 回答「這應該能通嗎？」；Flow Logs 回答「實際上發生了什麼？」。資深工作流是先跑一次 Connectivity Test 驗證設定意圖，再用 Flow Logs 查可疑時間窗內確切的 5-tuple，確認生產資料平面是否真的如預期行事。

Performance Dashboard 的跨區延遲檢視

Performance Dashboard 提供兩種檢視：Google Cloud Performance（由 Google 內部探測器量測的每一組 Google Cloud 區域之間的往返延遲與封包遺失）與 Project Performance（同樣指標，但範圍限縮於你專案的 VM）。

區域對區域檢視

選兩個區域，看到過去 6 小時、24 小時或 7 天的 p50、p5、p95 RTT（毫秒）以及封包遺失百分比。用它決定是否要部署區域複本，或接受跨區延遲代價。

專案檢視

顯示你的 VM 跨區或跨可用區之間的相同指標。可在不對應用程式埋點的情況下偵測異常 hop。

解讀數字

us-central1 ↔ us-east1 典型 RTT 約為 p50 30 ms；us-central1 ↔ asia-southeast1 約 p50 175 ms。同區路徑突然多出 50 ms 幾乎一定是路由或壅塞事故，而不是程式碼回歸。怪罪應用程式之前，Performance Dashboard 是第一個該看的地方。

與 Network Topology 交叉比對

當 Performance Dashboard 顯示某條路徑延遲惡化，Network Topology 讓你看見目前坐在那條路徑上的工作負載與其流量量級，方便排定處置優先順序。

疑難排解流程

可重複的分流流程能在事故中省下數小時。以下是 Google 客戶工程師在真正升級事件中跑的社群驗證流程。

步驟 1：取得確切配對

請使用者提供確切的來源與目的，包含 port、protocol 與時間戳。「API 掛了」這種模糊回報會把你拖死。一定要拿到具體的 5-tuple。

步驟 2：執行 Connectivity Test

用 gcloud 一行指令，加上 --include-data-plane-analysis。讀判定與 trace。七成事故會在這一步解決，因為 trace 已直接點名違規防火牆規則、缺少的路由或停止中的實例。

步驟 3：檢查 Network Analyzer

開 Network Analyzer 並過濾到相關 VPC 的發現項目。即使使用者沒提到，像 IP_UTILIZATION_HIGH 或 VPN_TUNNEL_DOWN 這類 HIGH 嚴重度發現項目常常就是事故的肇因。

步驟 4：拉可疑時間窗的 Flow Logs

對來源 IP 與目的 port 在可疑的 10 分鐘窗中查 BigQuery，確認生產資料平面是否真的看到封包，以及回報的 disposition 是什麼。

步驟 5：觀察 Firewall Insights

若 trace 顯示 FIREWALL_BLOCK，到 Firewall Insights 查被點名的政策／規則。介面會顯示近期命中數，並讓你預覽變更影響。

步驟 6：檢查 Network Topology 與 Performance Dashboard

若判定是 REACHABLE 但使用者仍回報問題，問題就不是可達性而是效能。打開 Performance Dashboard 的對應區域組合與 Network Topology 的工作負載圖，找延遲尖峰、封包遺失，或經由 Cloud NAT 的非預期髮夾流。

步驟 7：用證據升級

若 1–6 步無法解決，開支援票時附上 Connectivity Test ID、Flow Logs 查詢結果、Network Analyzer finding ID 及 Performance Dashboard 截圖。Google 支援人員拿到這包證據後處理速度會快上好幾倍。

IAM、配額與營運限制

Connectivity Tests 有自己的權限介面與一些考試會考的配額。

IAM 角色

• roles/networkmanagement.admin：對 connectivityTests 資源完整控制。
• roles/networkmanagement.viewer：唯讀檢視測試與 trace。
• 細粒度權限：networkmanagement.connectivityTests.create、.get、.list、.update、.delete、.rerun。

執行測試的主體還必須擁有路徑上所有網路資源（subnets、防火牆規則、peering）的讀取權限。常見錯誤是只授予 network-management 角色卻沒有 compute.networks.get 與 compute.firewalls.list，會造成不透明的 UNDETERMINED 判定。

配額

每個專案最多 1,000 個連線測試（軟性限制，可調升）。重新執行不佔測試數量配額，而是計入 API 請求配額。即時資料平面探測會以 VM 為單位限速（每分鐘數封），避免被濫用。

計費

靜態分析器免費。即時資料平面探測以每封包小費率計費。VPC Flow Logs 儲存與 Cloud Logging 出口分開計費；Flow Logs 進 BigQuery 採標準 sink 與儲存費率。Performance Dashboard、Firewall Insights、Network Topology 已含在平台費用中。

常見陷阱與取捨

Connectivity Tests 在 demo 看起來簡單，正式環境裡會冒出尖角。

陷阱：把可達性誤認為應用程式健康

REACHABLE 只證明 L3/L4 網路路徑暢通。應用程式仍可能每次請求都回 500。REACHABLE 之後的下一步是應用層診斷，而不是宣告勝利。

陷阱：相信過期的測試結果

測試結果是快照。昨天跑的測試已被今天的防火牆變更作廢。下結論前永遠重跑一次，並偏好在 CI 中排定定期重跑。

陷阱：作業系統層的防火牆檢查員看不到

Connectivity Tests 看得到 Google Cloud 的防火牆物件，但看不到 VM 內 guest OS 跑的 iptables、ufw、firewalld 或 Windows Defender 規則。REACHABLE 但連線被拒，通常是 guest OS 在當門神。

取捨：取樣率 vs 儲存成本

對嘈雜子網路用 100% 取樣的 Flow Logs，Cloud Logging 攝入費可能一天數百美元。依敏感度逐子網路調整取樣率：付款子網路 1.0、批次處理 0.1、開發環境 0.05。

取捨：Network Analyzer 雜訊

Network Analyzer 可能產出數十項低嚴重度發現項目。要主動呼叫的請積極過濾到 HIGH／CRITICAL；其餘每週審查即可。

常見問題（FAQs）

Q：執行 Connectivity Test 會影響生產流量嗎？

A：靜態分析不發任何封包，毫無影響。即時資料平面模式會發少量探測封包（通常每方向 3–5 封），有速率限制，與背景流量無法區分。對應用程式吞吐量或延遲沒有可量測影響。

Q：Connectivity Test 能驗證經過 Cloud NAT 的流量嗎？

A：可以。Trace 會明確把 Cloud NAT 建模為一個步驟，並在適用時回報 CLOUD_NAT_NO_ADDRESSES 或 CLOUD_NAT_PORT_EXHAUSTION。它同樣建模 Cloud Load Balancing、Cloud VPN、Interconnect attachments、Private Service Connect 與 VPC Network Peering。

Q：Reachability Analyzer 與 Network Analyzer 有何差別？

A：Reachability Analyzer（Connectivity Tests 的 console 名稱）驗證你定義的特定來源－目的路徑。Network Analyzer 則是永遠開啟的掃描器，不需指定路徑就會冒出 VPC 設定錯誤。有特定問題時用前者；持續偵測偏移時靠後者。

Q：為什麼我的測試回傳 UNDETERMINED 而不是 REACHABLE 或 UNREACHABLE？

A：最常見原因：(1) 執行測試的主體在路徑上某個資源缺少讀取權限；(2) 來源或目的跨入分析器看不見的 non-GCP 網路（地端防火牆、合作夥伴 SaaS）；(3) 端點參照模稜兩可（例如同一 IP 屬於不同專案的多個子網路）。修正權限或讓端點更精確後重跑。

Q：能即時把 VPC Flow Logs 匯出到 BigQuery 嗎？

A：可以，透過目的地為 BigQuery 的 Cloud Logging sink，日誌通常在產生後 1–2 分鐘內落入分區資料表。若要更低延遲，改用 Pub/Sub sink，再用 Dataflow 串流進 BigQuery 或直接寫入串流緩衝。

Q：Performance Dashboard 的延遲數字是從我的 VM 量的，還是從 Google 探測器量的？

A：兩者都有。「Google Cloud Performance」檢視來自 Google 內部探測器基礎建設（每組區域之間的連續探測）。「Project Performance」檢視則用與你專案 VM 綁定的遙測計算相同指標。比較兩者：若同一組區域 Project Performance 比 Google Cloud Performance 差，瓶頸就是你的工作負載或 VPC 設定，而不是底層 Fabric。

Q：Flow Logs 預設保留多久？

A：Cloud Logging 預設保留 30 天。導入 BigQuery（長期儲存便宜）或 Cloud Storage Coldline 來達到一年以上的法遵保留。Flow Logs 本身不會落在 NIC 中，NIC 是按需從 Cloud Logging 讀取。