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

Packet Walk Method

Azure network incidentをDNSからreturn pathまで1 hopずつ再現するPacket Walk Method。control plane、active probe、flow log、packet evidenceを同じ5-tupleで積み上げる。

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

Packet Walk Methodを理解するための前提

Packet Walkは「Azureのどこかで止まる」を、source process→DNS→source NIC/security→route→transit/NVA/LB→destination→return pathへ分解する方法。 forward pathだけでなくreturn pathを別flowとして必ず確認する。NVA/forced tunneling/hybridではasymmetric routingが典型failureになる。

各hopで「期待構成」「Azure-selected/effective state」「active test」「historical telemetry」のうちどの証拠を持つかを明示する。 FQDNは最初にIPへ解決して固定するが、DNS自体がroot cause候補なのでquery path/TTL/private zone linkageを別stepで記録する。

L4 reachabilityとL7 application successを分離する。TCP 443 reachableでもTLS SNI/Host/WAF/backend healthで失敗できる。 変更はpacket walkでfailure boundaryが狭まってから行い、同じwalkをpost-changeへ再利用する。

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

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

Name

clientが何をどのresolverでどのIPへ解決したか。

Forward

source security + route + transit + destination entry。

Terminate / proxy

LB/AppGW/Front Door/Firewall/NVAでconnectionが終端・NAT・再生成される境界。

Return

destinationからsourceへのroute/security/NAT/session state。

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

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

  1. User journeyを1つ選ぶ: source host/process、URL/FQDN、resolved IP、protocol/port、expected response、timestamp。
  2. DNS query pathを確認し、A/AAAA/CNAME、private/public zone、TTL、sourceが使うresolverを保存する。
  3. source NICのeffective security/IP Flow Verifyとeffective route/Next Hopを同じdestination IPで確認する。
  4. peering/VPN/ER/Firewall/NVA/LB/AppGW等の境界を図に並べ、各境界でNAT/proxy/Host/SNI/source IPがどう変わるか記録する。
  5. destination側のsecurity、listener/backend health、guest listen/application logを確認する。
  6. return pathをdestination→sourceとしてroute/security/NAT/session stateまで逆向きに確認する。
  7. 不明境界だけConnection Troubleshoot/flow log/packet captureでdata-plane evidenceを追加する。
  8. 修正後、同じsource/URL/new connectionで全walkを短縮再実行し、隣接正常flowとnegative testも確認する。

仕組みと読み方

Packet Walkは特定Azure製品ではなく、複数serviceを跨ぐ障害を証拠の連鎖として扱う運用モデルです。重要なのは「route tableにこのrouteがある」ではなく「このNICからこのdestinationへAzureが選んだnext hopは何か」、「NSGにallowがある」ではなく「このtupleはどのruleでAllowか」と実効状態へ落とすことです。

proxy/LBを跨ぐと5-tupleが変わる場合があります。Application Gatewayならclient→frontendとGateway→backendは別connectionです。DNAT/SNAT/NVAではsource/destinationが変換されます。そのため1本の線で考えず、connection boundaryごとに新しいtupleを記録します。

運用設計

判断軸運用設計
Canonical diagramproduction topologyをresource ID/subnet/prefix/next-hop付きで維持。
Tuple ledger境界ごとにbefore/after NAT、source/dest、protocol/portを表にする。
Evidence link各hopの証拠URL/command/queryをrunbookへ紐付ける。
Bidirectionalreturn path確認を省略しない。stateful device/sessionも考慮。
Stop rule証拠がない状態で複数設定を同時変更しない。

確認手順 / 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
# 例: source VMでsecurity -> route -> reachability の順
az network watcher test-ip-flow ...
az network watcher show-next-hop ...
az network watcher test-connectivity ...
PowerShell — read-only first
# 同一source/destinationを維持してTest-AzNetworkWatcherIPFlow / NextHop / Connectivityを実行

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

観測結果証明できることそれだけでは証明できないこと
DNS answer fixedそのclient/resolver/timeの名前解決結果。別client/TTL後も同じIP。
Security Allowそのboundaryのpolicy permit。次hop到達。
Expected Next HopAzure-selected routeが設計通り。middlebox forward成功。
Packet at destinationforward pathがdestination capture pointまで到達。return/application success。
Application 200 + logsjourneyがL7まで成功。negative security requirementまで満たすこと。

よくある切り分けの失敗

症状 / 状態疑う層次の証拠
途中まで全部正常次boundaryを未観測connection termination/NAT後の新tupleを探す。
片方向だけpacketありreturn path/asymmetryreverse effective route + stateful device。
IP直打ちは成功/FQDN失敗DNS/Host/SNIresolver/CNAME/Host header/TLS SNIへ。
同じserviceで一部backendのみ失敗LB/backend healthbackend別health/log/captureで比較。
変更後に別通信が壊れたblast radius/negative test不足adjacent + deny testをchange validationへ追加。

変更時の確認と rollback

  • packet walkのfailure boundaryと変更対象を1対1にする。
  • rollback条件を「何分以内にどのtestが回復しないか」のobservable条件で決める。
  • rollback後もroute convergence/DNS cache/session reuseを考慮してnew connectionで再確認する。
Change safety: 診断中にsecurity、route、DNS、proxy/backendを同時変更すると、どの差分が効いたか分からなくなります。1 hypothesisずつ変更し、同じtest vectorでbefore/afterを取ります。

Current notes — 2026-09-11

Current behavior / guidance

current Azure observability guidanceはNetwork Watcherのreal-time diagnostics、VNet Flow Logs、Traffic Analytics等を役割別に示しています。Packet Walkではこれらを単一toolの代替ではなく、同一test vectorに対する異なるevidence layerとして組み合わせます。

Network Watcher
同じtest vectorを別の観測面から確認する。Connection Troubleshoot
同じtest vectorを別の観測面から確認する。Networking KQL Patterns
同じ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を再確認してください。