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

Network Watcher Packet Capture

Network Watcher Packet CaptureをVM/VMSSのdata-plane証拠として安全に取得し、5-tuple filter、SYN/ACK、reset、DNS、retransmissionを診断へ結び付ける。

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

Network Watcher Packet Captureを理解するための前提

Network Watcher Packet CaptureはVM/VMSSの送受信trafficをremote captureする機能で、reactive/proactive network diagnosisに使う。 current CLI referenceではNetwork WatcherがregionでenabledであることとAzureNetworkWatcherExtensionがVMにenabledであることがpacket-capture commandの前提。

captureはlocal diskまたはAzure Storageへ保存でき、filterでprotocol/local/remote IP/portを絞れる。 2026年更新のoverviewにはContinuous packet captureがpreviewとして記載される。previewを常設production packet recorderと同一視しない。

PCAPは「capture pointでpacketが見えた/見えない」を証明する。途中hopのdrop箇所を1 captureだけで特定するには不十分。 無制限captureはdisk/storage/個人情報/credential等のpayload露出リスクを増やすため、duration/size/filter/access/retentionを事前に決める。

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

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

Preflight

target VM/VMSS、region、extension、permission、保存先、空き容量。

Filter

problem flowのprotocol/IP/portへ絞る。広域captureは最後の手段。

Packet semantics

SYN/SYN-ACK/ACK、RST、ICMP、DNS、retransmit、TLS handshake開始を読む。

Pairing

sourceとdestinationまたはNVAの両側captureを時刻同期して比較する。

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

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

  1. 先に5-tupleとincident timestampを固定し、IP Flow Verify/Next Hop等でfailure domainを狭める。
  2. target VM/VMSS instance、Network Watcher region、AzureNetworkWatcherExtension、保存先をpreflightする。
  3. 最小duration/byte limit/filterでcaptureを開始し、同じfailureを1〜数回だけ再現する。
  4. captureを停止し、pcapをWireshark等でtime/tuple filterしてSYN→SYN-ACK→ACKまたはDNS/ICMPを追う。
  5. 片側だけではdrop位置が不明な場合、対向host/NVAの対応captureまたはflow log/Firewall logを同時刻で揃える。
  6. 修正後に同条件で短いcaptureを再取得し、正常handshake/responseとの差を保存する。

仕組みと読み方

packet captureは最もdata-planeに近い証拠ですが、Azure fabric全体を透視するものではありません。source VMでSYNが出ていてSYN-ACKが戻らない場合、「source OSから出た」は証明できますが、どのhopで落ちたかはまだ未確定です。destination側にSYNが到着していればreturn path/response側へ絞れます。

またTLS暗号化trafficではpayloadを読めなくても、TCP handshake、TLS ClientHelloの到達、connection reset、retransmission timingなど多くの事実を得られます。PCAPはsecurity/privacy上の取扱いが必要なので、必要なflowだけを短時間取得するrunbookが重要です。

運用設計

判断軸運用設計
Capture budgetduration/bytes/packet sizeを定義し、incident時に無制限取得しない。
Storagelocal vs Storageを選び、access control/retention/delete手順を決める。
Privacypayloadにtoken/PII/credentialが含まれる可能性を前提に閲覧者と保管場所を制限。
Clock複数capture/logを相関するためVM/NVA/log timestampのUTC基準を合わせる。
Previewcontinuous capture previewはfeature lifecycle/limitをcurrent docsで再確認して利用。

確認手順 / 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 packet-capture list --location <region> -o table
az network watcher packet-capture show --location <region> --name <capture-name> -o jsonc
az network watcher packet-capture show-status --location <region> --name <capture-name> -o jsonc
PowerShell — read-only first
Get-AzNetworkWatcherPacketCapture -NetworkWatcher <watcher>
# Start/Stopはproduction capture条件を明示してから実行

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

観測結果証明できることそれだけでは証明できないこと
Outbound SYN observedcapture pointからSYNが送信された。Azure fabric/NVA/destinationまで到達したこと。
Inbound SYN + outbound SYN-ACKdestination NIC/guestまでrequestが届き応答を出した。sourceまでreturn packetが届いたこと。
RST from destination対向がconnectionを明示reset。なぜresetしたか。process/firewall/app logが必要。
Repeated SYN no reply応答がcapture pointへ戻っていない。drop location。対向capture/route/security evidenceが必要。
DNS query no responseresolver requestは送信、response未確認。resolver故障か途中dropか。DNS server側/routeへ。

よくある切り分けの失敗

症状 / 状態疑う層次の証拠
capture開始失敗extension/region/permissionNetwork WatcherとAzureNetworkWatcherExtensionを確認。
ファイルが巨大filter/limit不足5-tuple + short durationで再取得。
packetが0件wrong NIC/instance/filteractual source IP/VMSS instance/方向を確認。
sourceにはあるがdestにないtransit dropNSG/UDR/NVA/Firewall/peeringを同時刻で追う。
PCAPだけで原因断定証拠範囲の誤解control plane/flow log/app logと相関する。

変更時の確認と rollback

  • packet capture自体のstart/stop/deleteをchange recordへ残す。
  • 診断終了後はcapture sessionを停止し、不要なlocal/Storage artifactをretention policyに従って処理する。
  • continuous capture等のpreview設定を恒久化する場合はproduction security reviewを別途行う。
Change safety: 診断中にsecurity、route、DNS、proxy/backendを同時変更すると、どの差分が効いたか分からなくなります。1 hypothesisずつ変更し、同じtest vectorでbefore/afterを取ります。

Current notes — 2026-09-11

Current behavior / guidance

Packet Capture overviewは2026-02更新でContinuous packet captureをpreviewとして掲示しています。一方、CLI referenceはVMでAzureNetworkWatcherExtensionが必要と明記しているため、runbookではpreviewとGA command prerequisiteを分離しています。

Network Watcher
同じtest vectorを別の観測面から確認する。Connection Troubleshoot
同じtest vectorを別の観測面から確認する。Packet Walk Method
同じtest vectorを別の観測面から確認する。VNet Flow Logs
同じtest vectorを別の観測面から確認する。

Official sources

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