Microsoft AZ-700: 網路監視與疑難排解 — 學習指南

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

屬於 Microsoft Azure Network Engineer AZ-700 — 學習指南. 使用經過驗證的解答練習： Microsoft 考試中心, 或參加限時模擬考試： ExamRoll.io.

可觀察性工具與資料來源

Azure 網路的可觀察性，核心在於 Network Watcher、Azure Monitor (Log Analytics) 以及診斷設定。這些設定會將資源的遙測資料串流到一個中央的工作區或儲存體帳戶。Network Watcher 提供封包擷取 (packet capture)、IP 流量驗證 (IP flow verify)、下一躍點 (next hop)、連線疑難排解 (connection troubleshoot) 以及連線監視器 (Connection Monitor)；Connection Monitor v2 支援多端點、多協定的測試，並將結果儲存在 Log Analytics 工作區中，以提供可查詢的遙測資料。NSG 流量日誌是透過 Network Watcher 啟用，並將 JSON 記錄寫入儲存體帳戶；啟用流量分析 (Traffic Analytics) — 這需要流量日誌和一個 Log Analytics 工作區 — 能以應用程式/地理位置的洞察和視覺化來豐富這些日誌。Azure Firewall、Application Gateway/WAF、Front Door 和負載平衡器的診斷設定，都應該路由到同一個 Log Analytics 工作區，以便關聯各種信號。常見的陷阱包括：儲存體帳戶的防火牆規則阻擋了流量日誌的寫入、在較舊的租用戶中忘記為每個區域啟用 Network Watcher，以及儲存體與 Log Analytics 之間的保留原則不一致。成本和功能的權衡很明確：將原始日誌寫入儲存體帳戶以進行低成本封存，或是將其擷取到 Log Analytics 中以進行查詢和警示（成本較高，但診斷價值遠大於前者）。必須設定好角色型存取控制 (Role-Based Access Control)（視情況需要 Monitor Reader 加上 Storage Blob Data Reader 角色），這樣診斷管線才能寫入日誌，而分析師才能讀取日誌。

封包擷取、Connection Monitor 與深度診斷

若要進行封包層級的疑難排解，可透過 Network Watcher 的封包擷取功能（可經由 portal/CLI/PowerShell 操作）將 PCAP 檔案建立到儲存體帳戶或本機 VM 檔案中。設定封包擷取的篩選條件（協定、來源/目的地 IP、連接埠）以及大小/時間限制，以避免過度的儲存空間耗用和效能衝擊。對於啟用加速網路的高輸送量 VM，主機端的封包可見度可能會受限；應使用 VNet TAP 將流量鏡像到一個收集器 VM 或 NVA，以避免遺漏被卸載的封包。Connection Monitor 應用於主動的綜合測試：定義來源和目的地端點（IP、FQDN、連接埠）、選擇測試頻率，並啟用每一躍點的延遲和路徑擷取，以進行多區段的診斷。使用 IP Flow Verify 來檢查特定的 5-tuple 流量是否被 NSGs/UDRs 允許或拒絕，並用 Next-hop 來確認有效的路由路徑。注意陷阱：在 Windows VM 上進行封包擷取可能需要提升的權限，且會受到作業系統卸載 (OS offloads) 的影響；封包擷取可能非常耗用 CPU/磁碟資源，因此應優先使用目標明確的篩選條件和時間範圍。若要大規模地進行持續性封包檢測，可將 VNet TAP 與能夠擷取 PCAP 串流的封包分析設備或雲端 SIEM 配對使用。

NSG 流量日誌、Traffic Analytics 與安全性診斷

NSG 流量日誌（版本 2）提供包含時間戳記、5-tuple、位元組/封包計數以及決策（允許/拒絕）的流量記錄。它們不包含酬載 (payload)、應用程式層的會話詳細資訊或解密的 TLS 內容。Traffic Analytics 能以流量最高者 (top talkers)、ASN 和地理位置對應來豐富流量日誌，這需要一個 Log Analytics 工作區。Azure Firewall、Application Gateway/WAF 和 Azure Front Door 會發出各自的診斷資料；這些資料必須導向 Log Analytics 以進行統一查詢。重要的設計陷阱：套用在 NIC 層級的 NSG 規則，其優先序高於子網路層級的規則；系統存在預設規則（例如 AzureLoadBalancer、網際網路規則），這些規則無法移除，只能被更高優先序的規則覆寫。流量日誌的實用性取決於其保留和擷取策略——在 Log Analytics 中長期保留的成本高昂，而短期保留則有遺失鑑識證據的風險。將 NSG 流量日誌與 Firewall 診斷日誌以及基於 Kusto 查詢的警示規則結合，以偵測橫向移動或資料外洩。在規劃補救措施時，可考慮為 Azure Firewall 新增專用的公用 IP 以緩解 SNAT 連接埠耗盡的問題，並在 Log Analytics 成本過高時，利用 DiagnosticSettings 將資料路由到 Event Hubs 以進行 SIEM 整合。

疑難排解模式、路由陷阱與設計權衡

在排解連線問題時，請遵循分層方法：先驗證資源層級的 NSG/UDR，檢查有效路由與下一個躍點 (next hop)，使用 IP 流量驗證 (IP Flow Verify) 與連線疑難排解 (Connection Troubleshoot)，若有需要再升級到封包擷取 (packet capture) 或 VNet TAP。路由陷阱通常在強制通道 (forced tunneling)、CIDR 重疊、或 UDR 設定錯誤（將流量送入 AzureFirewallSubnet 卻沒有適當的回傳路由）時浮現。針對負載平衡與擴展，請根據 L4 vs L7 的需求以及全域 vs 區域的流量管理，在 Azure Standard Load Balancer、Application Gateway WAF 和 Front Door 之間做選擇。請考量以下這些 SKU 的權衡取捨：

Azure Firewall Standard vs Premium： Premium 版本增加了 TLS 檢測、IDPS 和 URL 過濾功能，但成本較高；當需要深度流量檢測與法規控管時，請選擇 Premium。
Azure Front Door Standard vs Premium： Premium 版本支援進階 WAF 功能與 private link 整合；Standard 版本成本較低，適用於典型的全域 CDN + 路由。
VNet TAP vs packet capture： TAP 成本較高，但在需要大規模無損擷取，以及當加速網路 (accelerated networking) 卸載封包時，TAP 是必要的。權衡取捨的核心在於效能、成本與彈性：NVA 可能比 Firewall Premium 更便宜或功能更豐富，但會增加管理負擔與單點故障的風險，除非採用高可用性 (HA) 架構。規劃 SNAT 容量、預留備用公用 IP，並準備好診斷管線，以在可觀測性需求與資料擷取成本之間取得平衡。

實務問題：使用案例情境

情境：Contoso Electronics 公司在兩個 Azure 區域（EastUS、WestEurope）營運，採用 hub-and-spoke (中樞輪輻式) VNet 架構，中樞 VNet 中有一台 Azure Firewall Standard，多個輪輻 VNet 中有 Application Gateway WAF，並有一個中央的 Log Analytics workspace 用於監控。他們最近在一個輪輻 VNet 中部署了一批生產環境的 VM，這些 VM 回報在透過 ExpressRoute 線路連線到地端 SQL 叢集時，會發生間歇性故障。

挑戰：連線到地端資源時出現間歇性連線問題與高延遲，但缺乏明確的封包層級證據；現有的 NSG 流量日誌雖已啟用，但只顯示允許的流量，沒有延遲指標。

建議方法：

從具代表性的 VM 部署 Connection Monitor v2，以 TCP port 1433 連線到地端 SQL 的 FQDN 與 IP，設定每 30 秒進行一次測試，並將結果傳送到中央的 Log Analytics workspace，以擷取每個躍點的延遲與可達性。
在一台受影響的 VM 上啟用 Network Watcher 封包擷取，設定篩選器以過濾 SQL 叢集的來源/目的地 IP 與 port 1433，並將 PCAP 檔案儲存到設有生命週期原則的儲存體帳戶；如果環境中有使用加速網路，請同時在輪輻 VNet 的子網路上啟用 VNet TAP，將流量鏡像到一台專用的收集器 VM。
為 Azure Firewall (Standard) 設定診斷設定，將應用程式與網路日誌傳送到同一個 Log Analytics workspace，並執行關聯查詢，將 Connection Monitor 的結果、防火牆日誌及 NSG 流量日誌結合起來，以偵測防火牆 SNAT 耗盡或原則丟棄的問題。
在事件發生期間，針對有問題的 5-tuple 使用 IP 流量驗證 (IP Flow Verify) 與下一個躍點 (Next Hop) 進行分析；如果懷疑是 SNAT 或非對稱路由問題，可以為 Azure Firewall 新增一個額外的公用 IP，或在輪輻 VNet 中部署一個 NAT Gateway 以獲得可預測的出口流量，並更新 UDR 將流量路由到中樞 VNet。

理由：Connection Monitor 提供合成的、帶有時間戳的可達性與每個躍點的延遲資料；當作業系統的卸載功能隱藏了流量時，封包擷取與 VNet TAP 能提供無損的鑑識資料。在 Log Analytics 中關聯防火牆與 NSG 日誌，有助於找出原則、SNAT 或非對稱路由的問題；新增公用 IP 或 NAT Gateway 則能緩解連接埠耗盡問題並穩定出口流量的行為。

← 負載平衡與流量管理 · 所有領域 · Azure Virtual WAN 與 Hub-Spoke →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →