AZ VNet SpaceAzure Networking Wiki
Home / Operations & Troubleshooting
Operations & Troubleshooting参照資料確認: 2026-09-11

IP Flow Verify

IP Flow VerifyをVM NICのsecurity-policy判定専用toolとして使い、NSGとVirtual Network Manager security admin ruleのAllow/Denyを5-tupleで検証する。

この記事の目次
要点証拠診断順序仕組み設計確認証明範囲切り分け変更安全CurrentSources

IP Flow Verifyを理解するための前提

IP Flow VerifyはAzure VMに対する指定trafficがsecurity/admin rules上AllowedかDeniedかを判定し、該当ruleを返す。 評価入力はdirection、protocol、local IP/port、remote IP/port。曖昧な「443が通るか」ではなくpacket条件を固定する。

VM NICへ効くsubnet/NIC NSGに加え、current documentationではAzure Virtual Network Manager security admin rulesも評価対象。 Allowはroute、NVA/Azure Firewall、destination listen、TLS、applicationを証明しない。Deniedはsecurity policy層の強い証拠になる。

local/remoteの意味はdirectionで変わるため、Inbound/Outboundを取り違えると別packetを検査することになる。 NSGはstatefulだがIP Flow Verifyは指定packet条件に対するpolicy evaluation。既存sessionの状態そのものをpacket traceする機能ではない。

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

診断結果をどう読み分けるか

Direction

Inbound / Outbound。どちら側NICで何方向のpacketを評価するか。

Tuple

protocol + local IP:port + remote IP:port。再現性の核。

Policy result

Access Allow/Denyとrule名。security policyの判定証拠。

Next layer

AllowedならNext Hop/Connection Troubleshoot、Deniedならeffective rule/desired policyへ。

判定原則あるtoolがPASSしたら、そのtoolの責任範囲だけを通過条件にします。「Allow」「Reachable」「Healthy」をnetwork/application全体の正常証明へ拡大しません。

障害が起きたときの調べ方

  1. 失敗flowのsource/destination IP、protocol、destination port、実source portまたはwildcard相当の条件を整理する。
  2. 対象VMのNIC/IP configurationをresource IDまで確認し、検査対象local IPがそのNICに存在することを確認する。
  3. Inbound/Outboundを決め、local/remote endpointを方向に合わせて設定してIP Flow Verifyを実行する。
  4. Deniedなら返されたruleをNSG/security admin configurationで確認し、priorityと意図されたpolicyを照合する。
  5. Allowedならsecurity rule仮説を一旦外し、Next Hop/effective route/Connection Troubleshootへ進む。
  6. 変更後は同一tupleのpositive testと、本来denyすべきnegative testを再実行する。

仕組みと読み方

IP Flow Verifyの強みは、subnet NSGとNIC NSGを人間が目視で重ね合わせる代わりに、指定packetに対して実効的なsecurity判定とruleを返すことです。Virtual Network Manager security admin rulesも関与する環境では、単一NSG画面だけを見て「allowされている」と判断する誤りを減らせます。

一方でroutingとsecurityを同時に判定するtoolではありません。Allowを得たあと通信できない場合、route/next hop、NVA/Azure Firewall、guest firewall、server listen、application proxy/WAFなどへ診断を進めます。

運用設計

判断軸運用設計
Test catalog重要flowを5-tuple/方向/expected Allow-Denyでcatalog化しchange validationへ再利用。
Negative controls拒否すべきinternet/management flowもtestし、過剰allowを検出。
Rule ownership返されたrule名からowner/change ticketへ追跡できる命名とtag運用。
Scope boundaryVM NIC security policyのtoolであり、PaaS/Firewall/WAFの全policy検証へ拡大解釈しない。

確認手順 / read-only first

実行前に固定する情報

  • subscription / resource group / resource ID / region
  • source IP/NIC/subnet と destination FQDN/IP
  • protocol / source port / destination port
  • UTC time window + JST表示
  • expected result と known-good comparison

Evidence to keep

  • command/query textとraw JSON/CSV
  • Portal screenshotだけでなくresource IDを含む機械可読結果
  • 変更前/変更後の同一test vector
  • negative test と adjacent critical path
  • rollback実施時の復帰確認
Azure CLI — read-only first
az network watcher test-ip-flow \
  --resource-group <rg> \
  --vm <vm-name> \
  --direction Outbound \
  --protocol TCP \
  --local <vm-ip>:50000 \
  --remote <dest-ip>:443 -o jsonc
PowerShell — read-only first
Test-AzNetworkWatcherIPFlow -NetworkWatcher <watcher> -TargetVirtualMachineId <vm-id> -Direction Outbound -Protocol TCP -LocalIPAddress <vm-ip> -LocalPort 50000 -RemoteIPAddress <dest-ip> -RemotePort 443

この結果で何を証明できるか

観測結果証明できることそれだけでは証明できないこと
Allow + rule X対象VM security/admin rulesでtupleが許可。route/Firewall/NVA/server/app success。
Deny + rule Xrule Xが指定tupleを拒否。それ以外の別tuple/別NICも拒否されること。
Allow after changepolicy評価上はchangeが反映。実flow回復。Connection Troubleshoot/実clientで確認。
Unexpected rule matchpriority/address/service tag条件が設計と不一致。root causeがそのrule変更だけか。route等も確認。

よくある切り分けの失敗

症状 / 状態疑う層次の証拠
Allowなのにtimeoutrouting/middlebox/listenNext Hop→Connection Troubleshoot→packet capture。
Deny ruleが想定外priority/ASG/admin ruleeffective rulesとAVNM security admin rulesを確認。
local IPを選べないNIC/IP config取り違えVM NICとprivate IP/resource IDを再確認。
Inbound/Outboundで結果が違うdirection semantics実packetの送受方向に合わせて再試験。
変更後だけ一部flow失敗tuple差source IP/port/protocol/IPv4/IPv6差を分ける。

変更時の確認と rollback

  • security rule変更前にold result/rule/priorityを保存する。
  • temporary high-priority allowを使う場合は最小prefix/portに制限し即rollback条件を持つ。
  • rollback後はintended deny/allowの両方を同じcatalogで再検証する。
Change safety: 診断中にsecurity、route、DNS、proxy/backendを同時変更すると、どの差分が効いたか分からなくなります。1 hypothesisずつ変更し、同じtest vectorでbefore/afterを取ります。

Current notes — 2026-09-11

Current behavior / guidance

current IP Flow Verify documentationではNSGだけでなくAzure Virtual Network Manager admin rulesも評価対象として記載されています。したがって、AVNM利用環境でNSGだけを見てpolicyを判断しない手順に更新しています。

Effective Security Rules
同じtest vectorを別の観測面から確認する。Next Hop
同じtest vectorを別の観測面から確認する。Connection Troubleshoot
同じtest vectorを別の観測面から確認する。Network Change Validation
同じtest vectorを別の観測面から確認する。

Official sources

動作、support boundary、preview/GA、retirement、schemaはMicrosoft Learnのcurrent documentationを基準にしています。productionで使う際は対象subscription/region/resource provider/API/CLI versionの最新documentationを再確認してください。