Operations & Troubleshooting参照資料確認: 2026-09-11

NSG Diagnostics

Network Watcher NSG Diagnosticsで指定flowがAllow/Denyになる理由をrule単位で確認し、effective NSG・IP Flow Verifyとの使い分けを整理する。

Scope: Microsoft Learn / Azure Architecture Centerの一次資料を2026-09-11時点で確認し、旧来の短い記事を公開運用向けdeep diveへ更新。SKU、region、limits、Preview statusは変わるため、実装直前にOfficial sourcesを再確認してください。

NSG Diagnosticsを理解するための前提

NSG Diagnosticsはsource/destination条件をsimulated flowとして評価し、Allow/Denyと根拠ruleを返す。 targetとしてVM、NIC、VMSS NIC、Application Gateway v2(一部制約あり)をsupportする。

NSG ruleはpriority numberが小さい順に評価され、matching ruleがdecisionを決める。 subnet NSGとNIC NSGが併用される場合は両方のeffective effectを確認する。

NSG Diagnosticsはapplication listener/host firewall/NVA等を証明しない。 security admin rule等AVNM controlが関与する環境では対象toolがどこまで評価するかcurrent docsを確認する。

通信や判断の流れを追う
症状を再現設定を確認能動試験ログ / packetアプリ確認

Control plane と data plane

Control planeNSG/ASG/security admin ruleとresource associationがcontrol plane。
Data planesimulated 5-tupleに対しsecurity rulesを評価しallow/deny reasonを提示するが、actual packet送信ではない。

仕組みと設計上の意味

「portが開いているはず」をrule textで判断せず、actual source/destination IP/protocol/portで診断する。

stateful existing flowとnew connectionは挙動が違う可能性があるためchange validationはnew flowで実施。

effective NSG outputとNSG Diagnostics resultが違う時はresource selection/ASG/IPを再確認。

denyがNSGでなければroute、Firewall/NVA、host、applicationへ進む。

Packet / decision path

source→destinationを1本のflowとして固定し、名前解決・routing・security・NAT/service processing・return pathを必要な範囲で順に確認する。

  1. target resourceとNIC/subnetを特定。
  2. 5-tupleを固定。
  3. NSG Diagnostics/IP Flow Verifyを実行。
  4. effective NSGとmatching ruleを確認。
  5. allowなら次にroute/application layerを確認。

設計判断

判断点推奨理由
Quick rule reasonNSG Diagnosticsmatching ruleを可視化
NIC-wide reviewEffective NSG全effective rule inventory
Actual connectivityConnection troubleshoot/app testNSG外layerも含む
Historical patternVNet flow logsintermittent flowを分析

確認手順

Azure Portal

  • Network Watcher → NSG diagnosticsでtarget/direction/protocol/IP/portを指定。
  • 結果のsecurity rule名/priority/actionを確認。
  • NIC → Effective security rulesでsubnet/NIC ruleを照合。

Evidence contract

Identitysubscription / resource group / resource ID / regionを固定。
Before / After同じsource・destination・protocol・portで比較。
Effective state設定値だけでなくeffective route/security/health/logを取得。
Runtimecontrol-plane Succeededとapplication successを分けて判定。
Azure CLI — read-only first
az network watcher run-configuration-diagnostic --resource <resource-id> --resource-group <rg> --direction Outbound --protocol TCP --destination <dst-ip> --port <port>
az network nic list-effective-nsg -g <rg> -n <nic> -o jsonc
az network watcher test-ip-flow -g <rg> --vm <vm> --direction Outbound --protocol TCP --local <src:port> --remote <dst:port>

障害切り分け

症状疑う点証拠次の確認
Deny ruleが想定外priority/ASG/source IP誤認diagnostic resultrule scope修正
Allowなのに接続不可route/host/app/NVAnext hop/connection test次layerへ
VMSS一部だけ差NIC/subnet association driftinstance NIC effective NSGconfig統一
change直後だけ旧挙動existing flow statenew connection teststateful behavior考慮

変更・rollback

  • rule変更前にmatching diagnostic resultを保存。
  • Allow追加はsource/dest/serviceを最小化しexpiry/ownerを付ける。
  • rollbackはrule priorityとASG membershipも元に戻す。
  • 変更後はexpected allowとexpected denyの両方を再試験。

Official sources