Azure認證帳號開戶 Azure雲伺服器防火牆規則失效排查

前言：規則失效並不等於「防火牆壞了」

在 Azure 上談防火牆，最常見的誤解是：我在 NSG（Network Security Group）或 Azure 防火牆裡加了允許規則，流量就應該通過。可實務上，所謂「規則失效」常常只是問題被誤判。原因可能在規則之外：例如封包根本沒有走到你以為的網路介面；路由把流量導向了別處；規則被更高優先順序的項目覆蓋；目標服務並非你以為的那個端點；或是用錯了方向、來源/目的地欄位與服務標籤。

真正有效的排查方式，不是盲目重填規則，而是把每一步變成可驗證的假設：流量是否到達資源？是否進入正確的防火牆層？是否符合規則條件？是被拒絕還是根本沒有被評估？只要證據足夠，你就能迅速找到「哪一層」在阻擋，以及「為什麼」阻擋。

第一章：先釐清現象，避免在錯的問題上耗時

排查失效規則時，第一件事不是打開設定頁，而是把現象描述清楚。你需要回答幾個問題，越具體越好。

1.1 具體哪種流量失敗？

常見情境包括：網站無法被連線（HTTP/HTTPS）、SSH/遠端桌面連不上、從內網呼叫外部 API 失敗、或是特定來源 IP 被拒絕。請記下：

• 協定：TCP/UDP/ICMP？
• 目的埠：例如 80、443、3389、22 或某個自訂埠。
• 來源：是特定公網 IP、VNet 內 CIDR、還是某個子網？
• 方向：Inbound 還是 Outbound？

很多人把「網站連不上」當作一個問題，但其實可能是「443 有回應但 80 沒開」「DNS 沒解析成功」或「負載平衡器健康狀態不通」。因此，把失敗拆到最小可驗證的單元。

1.2 失敗發生在哪個階段？

若你使用的是瀏覽器或 API 客戶端，可觀察：

• 是否連線階段就失敗（例如逾時或立即拒絕）？
• 是否能解析 DNS，但後續連線失敗？
• 是否偶發（可能跟 NSG 套用範圍、路由或服務狀態有關）？
• 是否僅某一來源網段失敗？

用這些現象，你能猜測是「路徑問題」「方向/規則條件不符」「優先順序覆蓋」或「被另一層防火牆攔截」。

第二章：先確認流量走向，再談規則

Azure 的網路像一層層拼起來的管道。你在 NSG 上寫的規則，只在流量走到相應的位置時才會被套用。沒有「走到」，就談不上「失效」。

2.1 確認目標資源是誰：NIC、子網、還是後面的服務？

NSG 可以套在子網，也可以套在網路介面（NIC）。若你以為規則在 NIC 上生效，但實際流量先被子網層的 NSG 擋掉，你就會以為「NIC 規則失效」。

排查時先找：

• Azure認證帳號開戶 目標虛擬機是否有多張 NIC？
• 該 NIC 或其所在子網是否都套了 NSG？
• 是否還有 Azure Load Balancer、Application Gateway、Private Endpoint 等在前？

2.2 方向錯誤常見：Inbound/Outbound 看似相同其實完全不同

例如你要限制對外通訊（Outbound），卻在 Inbound 寫了允許規則；或你只開了 Inbound 到 Web 服務埠，但實際上應用需要先進行 DNS 查詢或呼叫第三方，Outbound 被擋住就仍然失敗。

建議你把「連線成功所需的整條鏈路」列出來：客戶端 →（可能先到負載平衡器）→ VM NIC 端口 → 反向回應；同時也要看 VM 內部是否還需要對外連線。

2.3 路由問題是隱形殺手：UDR、系統路由、虛擬設備

若你用 UDR（User Defined Route）把流量導向防火牆設備或其他網關，即使 NSG 開放，封包也可能不走你設定的那條路徑。這在以下情境更常見：

• 部署了 Hub-Spoke 且邊界透過虛擬設備轉發
• 使用 Azure Firewall 或第三方防火牆做 egress
• 設定了 0.0.0.0/0 或特定前綴的路由

因此排查時要檢查路由表是否讓封包在到達 NSG 評估前就被改道。

Azure認證帳號開戶 第三章：NSG 規則常見「看似寫了但不生效」的原因

NSG 是排查防火牆失效最常見的起點。下面整理一些經驗上最常遇到、也最容易忽略的問題。

3.1 優先順序：你以為允許會勝出，實際上被更高優先順序的 Deny 擋住

NSG 規則使用「優先順序（priority）」來決定匹配哪一條。只要有規則比你允許項目更高優先順序且條件匹配，結果就可能直接是 Deny。

常見情境：

• 你新增了允許，但原本有一條針對更寬的 CIDR、或針對某埠範圍的 Deny 優先級更低數值（更高優先）
• 來源/目的地欄位寫得過寬，導致你的「允許」其實被先匹配到別的 Deny

排查建議：不要只看你新增的規則，請檢查整張 NSG 的規則順序。並注意「預設規則」：若有預設的 Deny（或服務層需要特定流量），你可能誤以為沒有。

3.2 Service Tag / IP 範圍選錯導致匹配失敗

Azure 提供服務標籤（Service Tag）用來描述特定 Azure 服務的網路來源/目的地，例如 Storage、AzureLoadBalancer、AzureActiveDirectory 等。若你把服務標籤當作一般字串套用，或選錯方向（來源用錯），就會導致規則永遠不匹配。

另外，若你用 CIDR 但網路前綴不完全吻合，也會匹配不到。例如你開了 10.1.0.0/16，但實際來源是 10.2.4.5/32 或 10.1.10.0/24 以外。

建議：用你實際觀測到的來源/目的地（最好是日誌裡的 src/dst），對照規則中的範圍是否真的涵蓋。

3.3 方向與埠：Any 埠看似省事，卻常引入副作用

很多人為了快速驗證，把規則設成 Any（所有埠）或很寬的範圍。這在早期除錯有用，但若你之後開始收斂安全性，很容易因為漏掉某個必要埠而復發。

Azure認證帳號開戶 排查策略是：先用寬鬆規則驗證「通不通」，再縮回精準條件。

3.4 NSG 套用位置不符合預期：子網 vs NIC

如果目標 VM 的 NIC 有 NSG，但你以為是子網上的規則；或你以為子網沒套 NSG，實際上已套用，這都會造成「你改了規則卻沒效果」。

建議你在變更之前記錄：

• 該 VM 的 NIC ID
• NIC 是否綁定 NSG
• 子網是否綁定 NSG

並確認你修改的是哪一張 NSG。

3.5 規則已生效但你測試方式不正確

例如你從一台跳板機測試，但跳板機本身的出站也受 NSG 限制。你以為是目標側的規則失效，其實是來源側出站被擋。

這時測試要成對進行：

• 測試「來源側」Outbound 是否能出去
• 測試「目標側」Inbound 是否能進來

否則很容易誤判。

第四章：Azure 防火牆與其他安全層的干擾

許多企業網路並非只靠 NSG。當你看到「規則寫了卻沒用」，就要想到：封包可能在走完 NSG 之後，又被另一層防火牆處理，最後才導致連線失敗。

Azure認證帳號開戶 4.1 Azure Firewall：你以為開了，但其實策略裡沒允許

若你使用 Azure Firewall 做 egress（常見：Hub vNet 出口集中），那麼到外部的流量可能必須先經過 Firewall。此時 NSG 允許不代表最終會成功，因為 Firewall Policy（應用/網路規則集合）才是最後的閘門。

排查重點：

• 防火牆是否為該路徑的必經路徑（看路由表）
• Firewall Policy 是否允許目標網域/目的地 IP/埠
• 是否有 FQDN 規則（若用到）
• 是否有 TLS/HTTP 特性導致規則不匹配

這裡常見問題是：你開了 NSG 的 443，但 Firewall 的 NAT 規則或網路規則沒有允許對應目的地。

4.2 安全性中心建議或審計設定影響「你以為的狀態」

安全性中心（Microsoft Defender for Cloud）會提供建議、告警與可疑行為。它不一定會直接「攔截流量」，但有時搭配自動化修正或其他策略，就可能造成你以為設定沒差，實際上環境被調整。

排查時要檢查是否有：

• 自動修正（Just-in-time、policy-based enforcement）
• 資源鎖（造成你以為改了但實際沒套用）
• 政策（Azure Policy）在部署後覆寫或限制設定

第五章：用日誌把「猜」變成「查」

當你能確認流量應該怎麼走、規則應該怎麼匹配時，下一步是看證據。Azure 的日誌與連線驗證工具是把排查從體感改成工程化的關鍵。

5.1 NSG Flow Log / 診斷設定：看是否有「Deny」或「Skip」

Azure認證帳號開戶 NSG 流量日誌（Flow Log）能讓你看到來源/目的地/協定/埠以及決策結果。你要找的通常是：

• 是否存在 matching 的規則？
• 是否顯示 Deny？
• 是否顯示沒有匹配（可能是規則條件不正確）？
• Azure認證帳號開戶 是否顯示流量根本沒有到 NSG 所在層（例如沒有任何 Flow Log 記錄）？

若日誌完全沒有，你就要懷疑路由或測試路徑，或是診斷未啟用。

5.2 Azure 防火牆日誌：看是否被拒、或僅路由沒走到

Azure Firewall 日誌能告訴你是否被策略阻擋。若日誌也沒有出現相應流量，那多半表示封包沒經過防火牆。

5.3 IP 辨識與 NAT：別忽略目的地地址的變形

若你使用 NAT Gateway、Azure Firewall NAT 或其他轉譯機制，來源/目的地在不同層看到的 IP 可能不同。規則條件如果以為一直是原始 IP，就可能不匹配。

因此你在日誌中看到的 src/dst，要跟你規則中的條件對齊；若規則針對的是「轉譯後」的 IP，就要按實際流程修正。

第六章：封包測試與「有效規則」驗證方法

有時你會卡在：規則看起來都對，但就是不通。這時比對日誌與測試工具的結果，可以快速判定是「匹配不到」還是「路徑不一致」。

6.1 使用連線測試（Connection troubleshoot）思維：把問題壓到單一步

連線測試的精神是：從來源到目標，選定協定與埠，觀察預期路徑是否成立。你不必把所有複雜性都一次測完，但要確保每次測試都有明確的參數。

若測試工具顯示目標網段可達但埠不通，優先看目標側 Inbound。若顯示埠可通但應答失敗，則可能是回程路由或狀態防火牆（stateful）行為相關設定。

Azure認證帳號開戶 6.2 TCP/UDP 的差異：UDP 特別容易被誤判為規則失效

UDP 沒有握手，很多工具只會顯示逾時。這時你必須用正確的測試方式，確認是否真的被丟棄，還是對方沒有回包、或應用層邏輯尚未就緒。

排查 UDP 時，除了 NSG/Firewall，還要看應用是否在監聽正確埠、以及是否存在影響的上游服務。

第七章：一次把常見失效案例拆解（可直接套用的排查清單）

以下用幾個典型案例的思路，讓你能在遇到類似狀況時照表操作。

7.1 案例：開了 443 允許，但網站仍然超時

可能原因通常不是你沒開 443，而是：

• 你允許的是目標 VM 的子網，但實際流量打到的是負載平衡器前端，再轉發到後端（LB 規則/健康檢查/NSG 在後端才重要）。
• NSG 套在不同位置：你改了子網，實際 NIC 上另有 NSG。
• Inbound 允許了，但 Outbound（回連）被擋住，造成 TLS 握手完成不了。
• 路由把流量導向了防火牆設備或另一個虛擬網路。

建議流程：

• 先確認連線目的端點是什麼（LB VIP？Direct VM IP？Private Endpoint？）
• 用日誌或連線測試確認是否匹配到 NSG 規則，以及決策是 Allow 還是 Deny
• 若有 Azure Firewall，檢查 Firewall Policy 是否允許對應目的地

7.2 案例：只有特定來源 IP 連不上

這類問題最常見是來源範圍、服務標籤、或 NAT 後的 IP 不一致。

• 來源規則寫的是公網 IP，但實際流量是透過 NAT Gateway 轉譯後的出口 IP。
• 你用了服務標籤（例如某 Azure 服務）但方向或端點型態不匹配。
• 優先順序中存在更高優先的 Deny 規則，剛好覆蓋了這個來源。

建議流程：

• 找出實際 src/dst（用日誌）
• 逐條比對你的規則條件範圍與優先順序
• Azure認證帳號開戶 必要時先用臨時允許（僅限單一來源、單一埠）驗證路徑，再收斂

7.3 案例：Inbound 規則正確，但站內呼叫仍失敗

站內呼叫代表通常是 VM-to-VM 或 VNet 內部服務。這時很多人只看目標側 Inbound，卻忽略來源側 Outbound。

• 來源 VM 的 Outbound 被 Deny，所以封包根本沒出去。
• 兩端 NSG 中都有規則：即使目標 Allow，來源端也可能先擋。
• 路由表導向不同子網或遠端網段的安全裝置。

建議：對調測試方向，從兩端各做一次確認，並看 Flow Log 決策。

第八章：修復與預防：讓規則不再「失效」

找到原因後，下一步是修復與避免未來重複發生。防火牆規則不是一次性的設定，而是會隨架構變動而演化。

8.1 變更要有可追蹤性：版本化與註記

建議你在每個規則做註記（description），寫清楚用途、來源/目的地依據、建立人與日期。當出現問題時，你才能快速知道是誰在什麼時候調整了策略。

8.2 優先順序策略：避免「靠運氣」

把 NSG 規則依功能分組，並建立一套優先順序規劃，例如：

• Den y（高風險或明確阻擋）放較高優先
• Allow（特定服務必要流量）放中間優先
• 廣域 fallback 置於較低優先

同時避免在同一張 NSG 中混入過多臨時規則。臨時規則要明確標記，並設期限或計畫移除。

8.3 用最小權限與最小範圍：先通再收

Azure認證帳號開戶 初期排錯可以用較寬條件確認路徑，但長期策略要收斂到必要的來源範圍、埠與協定。最小權限能降低規則衝突機率，也能讓日後除錯更快。

8.4 把日誌與告警納入日常：失效要能提早被看見

與其等到服務爆發再找原因，最好在關鍵路徑上啟用日誌與告警。特別是：

• Inbound/Outbound 的 Deny 計數突然升高
• 特定來源/目的地的流量被拒絕
• Firewall policy 的拒絕日誌出現頻繁異常

當你把監控建立起來，「失效」往往可以在影響擴大前被攔下。

結語：規則失效的本質，是「路徑與匹配」出了偏差

Azure 的防火牆規則失效排查，最核心的觀念只有一句：先確認封包走到哪裡、再確認它是否符合規則條件。NSG 優先順序、套用位置、方向與埠、服務標籤與 CIDR 匹配、UDR 與虛擬設備、Azure Firewall 策略、以及 NAT 轉譯後的 src/dst，都可能讓你以為規則沒作用。

把排查流程工程化：釐清現象 → 確認路徑與套用層 → 用日誌找到決策 → 修正規則與路由 → 收斂權限並建立監控。當你用這套方式做，真正的「原因」會越來越少，而「解決時間」會越來越短。

如果你願意，我也可以根據你目前的具體架構（是否有 NSG 套子網/ NIC、是否有 Azure Firewall、是否有 UDR、服務是 VM/LB/Private Endpoint）把排查清單改成更貼近你的版本，讓你照著做即可定位。