Azure Network Watcher如何排查雲端連線問題？

先了解問題：雲端服務如何維持可用性

Azure Network Watcher 是協助管理員觀察及排查 Azure 網絡的工具集合。它不是單一的「修復按鈕」，而是把拓撲、連通性測試、封包路徑、有效安全規則及連線監控等證據集中起來，讓工程師由網絡層逐步收窄到端口及應用層問題。 對企業而言，設計的價值在於把技術設定轉化為可量度、可監控及可恢復的服務能力。下文從架構、操作流程、安全控制及本地部署情境逐步說明，方便管理員建立自己的檢查清單。

任何雲端配置都應先在測試環境驗證，再以最小範圍推進生產。記錄變更前後的設定、測試時間、責任人及回復方法，出現異常時才可以快速還原，而不是在事故中猜測哪一項設定曾經被修改。

排查前先界定故障範圍

「連不到」可能代表多種不同現象：VM 沒有路由、NSG 拒絕、Azure Firewall 阻擋、服務沒有監聽端口、DNS 回應錯誤，或應用程式完成 TCP 連線後仍然拒絕請求。開始前應記錄來源、目的地、協定、端口、發生時間及是否所有用戶都受影響，避免只憑一台電腦的主觀測試下結論。

Network Watcher監控工具提供不同層次的觀測方式。管理員應把測試結果與監控記錄對照，亦可參考 NIST持續監控原則，將一次性手動排錯轉化為可持續的監控及告警。

常用功能與用途

分層排查流程

1. 確認名稱及地址——由來源端解析目的地，核對是否得到預期私人或公開 IP，避免把 DNS 問題誤判為防火牆問題。
2. 檢查拓撲與路由——確認 VM 網卡、子網、VNet peering、VPN/ExpressRoute 及 user-defined route 的方向。
3. 驗證有效安全規則——以 IP flow verify 檢查 NSG；再查 Azure Firewall、第三方 NVA 及本地防火牆的記錄。
4. 測試實際端口——以 Connection Monitor 或受控的 TCP 測試確認目的服務是否監聽，並檢查作業系統防火牆。
5. 回到應用層——若 TCP 成功，繼續查看 TLS、身份驗證、HTTP 狀態碼及服務日誌，最後建立可重複的監控。

每一步都應保存時間、測試來源、規則名稱及回應，讓不同班次的工程師可以重現結果。切勿在生產環境為了「試一試」而大幅放寬 NSG；應先新增具限時及最小範圍的測試規則，完成後立即移除。

Connection Monitor的長期監控

手動連線測試只代表某一個時間點，適合故障定位；Connection Monitor 則可按固定頻率從指定來源監測多個目的地。測試設計要覆蓋辦公室到 Azure、Azure 到本地機房，以及不同可用性區域或網段之間的關鍵路徑。指標不應只看「通」或「不通」，亦要設定延遲、封包遺失、失敗連續次數及維護時段。

若監測端點包含攝影機、門禁或 IoT 閘道，應使用專用測試節點，不要以大量真實設備產生不必要流量。將告警交給行動群組或工單流程，並把變更、事件及根因結果連結，才可以逐步改善容量與網絡設計。

香港企業網絡的實務重點

香港企業常見跨辦公室、數據中心及 Azure 的混合網絡，故障可能由本地寬頻、VPN、路由器、雲端 NSG 或服務端口任何一層引起。建議先建立基線：正常時延、可接受封包遺失、每個業務系統的必要端口及維護窗口。網絡文件可參考 網絡故障排查步驟、網絡分段及VLAN規劃。

常見問題

延伸閱讀

權威資料來源

Microsoft Learn：Network Watcher監控概覽；NIST SP 800-137：Information Security Continuous Monitoring。