AzureのNetwork WatcherでVNet通信を診断する方法|IPフロー確認・パケットキャプチャ・接続チェックの実践手順

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)Azure > AzureのNetwork WatcherでVNet通信を診断する方法|IPフロー確認・パケットキャプチャ・接続チェックの実践手順
「VNet内のLinux VMが別のVMに通信できない。NSGのルールを確認しても問題なさそうなのに、なぜ繋がらないのか原因がわからない。」
「パケットがどこで遮断されているのか判断できない。curlはタイムアウトするだけで、OS側に問題がないのかAzure側の設定なのか切り分けができない。」

AzureのVNet環境でネットワーク障害が発生したとき、NSGのルール・ルートテーブル・Azure Firewallポリシーが複雑に絡み合うため、従来のLinuxサーバー運用と同じ感覚でtcpdumpやssコマンドだけを使っても原因を特定しにくい。

この記事では、Azure Network Watcher を使ってVNet通信トラブルを系統的に診断する方法を解説する。IP Flow Verify(NSGの遮断確認)、NSGフローログ(通信の時系列記録)、パケットキャプチャ(VMの実通信取得)、接続チェック(エンドツーエンドの到達確認)の4つのツールをazコマンドで実際に動かしながら一ステップずつ説明する。

動作確認環境:Azure CLI 2.63.0 / Rocky Linux 9.4 / Ubuntu 24.04 LTSで動作確認済み

この記事のポイント

・IP Flow VerifyはNSGが通信を遮断しているかを即座に判定できる
・NSGフローログはAllow/Denyを時系列で記録し事後調査に使える
・パケットキャプチャはVM Agent経由で実トラフィックを.capファイルに保存できる
・Connection Monitorでエンドツーエンドの到達性を継続的に監視できる


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

なぜAzure Network Watcherが必要なのか

AzureのVNet環境では、通信が遮断された場合に複数の要因が重なることが多い。

・NSGのインバウンド・アウトバウンドルール(サブネット単位・NIC単位の二重適用)
・カスタムルートテーブル(User Defined Route)によるルーティングの変更
・Azure Firewallのポリシールール
・ネットワーク仮想アプライアンス(NVA)を経由する場合の設定ミス

「NSGを確認したが問題なかった」にもかかわらず実際には通信できないというケースが現場では頻繁に起きる。NIC単位に付いたNSGとサブネット単位に付いたNSGの両方が評価されることを知らないと、片方しか確認せずに原因を見落とす。

Network Watcherはこうした複合的な原因を系統的に切り分けるための、Azureネイティブのネットワーク診断ツール群だ。

Network Watcherの有効化と前提確認

1. リージョン単位の有効化を確認する

Network WatcherはAzureサブスクリプション内でリージョンごとに有効化が必要だ。VNetを作成したタイミングで自動的に有効化される場合が多いが、明示的に確認・有効化するコマンドを押さえておく。

# Network Watcherの一覧確認 az network watcher list --output table # 特定リージョンに有効化する(例:japaneast) az network watcher configure --resource-group NetworkWatcherRG --locations japaneast --enabled true

実サーバーでの出力例:

Location Name ProvisioningState ResourceGroup ----------- ------------------------- ------------------- ---------------------- japaneast NetworkWatcher_japaneast Succeeded NetworkWatcherRG

ProvisioningStateSucceeded であればNetwork Watcherは有効だ。

2. NetworkWatcherAgentVMExtensionの確認

パケットキャプチャ機能を使うには、Linux VMにNetwork Watcher Agent拡張機能がインストールされている必要がある。インストール済みかどうかを確認し、なければ追加する。

# VM拡張機能の一覧確認 az vm extension list --resource-group myRG --vm-name myLinuxVM --output table # Agent未インストールの場合はインストールする az vm extension set --resource-group myRG --vm-name myLinuxVM --name NetworkWatcherAgentLinux --publisher Microsoft.Azure.NetworkWatcher --version 1.4

IP Flow VerifyでNSGの遮断を診断する

1. IP Flow Verifyとは何か

IP Flow Verify は、指定したVM・IPアドレス・ポート・プロトコルの組み合わせについて、NSGが通信を許可するかどうかを即座に判定するツールだ。実際にパケットを送るのではなく、NSGルールの評価結果を返す「仮想診断」であるため、秒単位で結果が返ってくる。

判定に使うパラメータは以下の4つだ。

・方向(Inbound / Outbound)
・プロトコル(TCP / UDP)
・送信元IPとポート
・送信先IPとポート

2. azコマンドで実行する

# 変数を定義する RG=myRG VM=myLinuxVM # VMのリソースIDを取得する VM_ID= # IP Flow Verifyの実行 # 例:外部IP(203.0.113.10)からVMの80番ポートへのインバウンド通信を確認 az network watcher test-ip-flow --watcher-resource-group NetworkWatcherRG --watcher-name NetworkWatcher_japaneast --vm $VM_ID --direction Inbound --protocol TCP --local 10.0.1.4:80 --remote 203.0.113.10:12345

3. 実サーバーの出力例

通信が許可されている場合:

{ "access": "Allow", "ruleName": "AllowHttpInbound" }

通信が遮断されている場合:

{ "access": "Deny", "ruleName": "DefaultDenyAllInBound" }

ruleName に遮断しているルール名が出力される。DefaultDenyAllInBound が返った場合は明示的な許可ルールが存在しないことを意味する。

4. 「Deny」が返った時の原因特定手順

Denyが返ったときは以下の順番で確認する。

ruleName のルール名を特定し、az network nsg rule show でルールの詳細を確認する
・NICに直接アタッチされたNSGとサブネットに設定されたNSGの両方を確認する(二重適用に注意)
・カスタムルートテーブルがある場合は az network watcher show-next-hop でネクストホップを確認し、トラフィックが意図しない経路を通っていないかを調べる

NSGフローログで通信の実記録を収集する

1. ストレージアカウントへのフローログ設定

NSGフローログ は、NSGを通過した通信を時系列でストレージアカウントに記録する機能だ。IP Flow Verifyが「これから起きる通信のシミュレーション」なのに対し、フローログは「実際に起きた通信の記録」だ。障害が発生した時間帯の通信ログを事後に確認できる点が最大の利点だ。

# ストレージアカウントを作成する(フローログの保存先) az storage account create --name mystorageflowlog01 --resource-group myRG --location japaneast --sku Standard_LRS STORAGE_ID= NSG_ID= # NSGフローログを有効化する(バージョン2・保持90日) az network watcher flow-log create --name myFlowLog --nsg $NSG_ID --storage-account $STORAGE_ID --enabled true --retention 90 --version 2 --location japaneast --resource-group NetworkWatcherRG

2. フローログの読み方

フローログはJSON形式でBlob Storageに書き込まれる。各レコードはカンマ区切りで通信情報を表す。

フィールド 値の例 意味
通信方向 I / O Inbound / Outbound
判定 A / D Allow / Deny
フロー状態 B / C / E Begin(開始)/ Continue(継続)/ End(終了)

バージョン2ではバイト数とパケット数も記録されるため、通信量の分析にも使える。判定フィールドが「D(Deny)」の記録が大量にある場合、その送信元IPと送信先ポートを手がかりにNSGルールの見直しを行う。

AzureのNetwork WatcherによるVNet通信診断の実践手法は、https://azure.linuxmaster.jp/ でもハンズオン形式で体系的に学べます。

パケットキャプチャでVM上の実通信を取得する

1. パケットキャプチャの開始と停止

パケットキャプチャ はLinux VM上のネットワークパケットを直接採取し、.capファイルとして保存する機能だ。VMに直接ログインして手動でtcpdumpを実行するのと同等の情報が、Azure側から操作で取得できる。VMへのSSHアクセスが取れない状況でも使えるのが利点だ。

# パケットキャプチャの開始(TCP 80番を対象に60秒間) az network watcher packet-capture create --resource-group myRG --vm myLinuxVM --name myCapture01 --storage-account mystorageflowlog01 --time-limit 60 --filters '[{"protocol":"TCP","localIPAddress":"10.0.1.4","localPort":"80"}]' # キャプチャの状態を確認する az network watcher packet-capture show-status --resource-group myRG --vm myLinuxVM --name myCapture01 # 手動で停止する場合 az network watcher packet-capture stop --resource-group myRG --vm myLinuxVM --name myCapture01

2. .capファイルをダウンロードしてtcpdumpで確認する

Blob Storageに保存された.capファイルをダウンロードし、手元のLinuxでtcpdumpを使って通信内容を確認する。

# .capファイルをダウンロードする az storage blob download --account-name mystorageflowlog01 --container-name network-watcher --name "captures/myCapture01.cap" --file /tmp/myCapture01.cap # tcpdumpで読み込む tcpdump -r /tmp/myCapture01.cap -n # 80番ポートだけに絞る tcpdump -r /tmp/myCapture01.cap -n port 80

実際の出力例(IPマスク処理済み):

10:15:23.412104 IP 10.0.1.4.52301 > 10.0.2.10.80: Flags [S], seq 3847291041, win 65535 10:15:23.412890 IP 10.0.2.10.80 > 10.0.1.4.52301: Flags [S.], seq 287341012, ack 1 10:15:23.413251 IP 10.0.1.4.52301 > 10.0.2.10.80: Flags [.], ack 1, win 65535

SYN→SYN-ACK→ACKの3ウェイハンドシェイクが確認できれば、VMレベルでは通信が確立している。SYNのみでSYN-ACKが返っていない場合は、対向VMのOS側(firewalldまたはiptables)で遮断されている可能性が高い。

Linuxサーバー上でのポート疎通確認は、Linux ポート確認の全コマンドも参考にしてほしい。

Connection Monitorでエンドツーエンドの到達性を継続監視する

1. Connection Monitorの作成

Connection Monitor は、送信元VMから送信先(VM・URL・IPアドレス)へのエンドツーエンドの到達性と遅延を定期的に測定・記録するツールだ。障害発生時の1回限りの診断ではなく、定常的な監視に使う点が他の3つのツールと異なる。

# VMのリソースIDを取得する VM_ID= # Connection Monitorを作成する(30秒ごとにTCP 80をテスト) az network watcher connection-monitor create --name myConnMonitor --resource-group myRG --location japaneast --source-resource-id $VM_ID --dest-address 10.0.2.10 --dest-port 80 --monitoring-interval 30

2. テスト結果の確認

# Connection Monitorの一覧を確認する az network watcher connection-monitor list --watcher-resource-group NetworkWatcherRG --watcher-name NetworkWatcher_japaneast --output table # 最新のテスト結果を取得する az network watcher connection-monitor query --name myConnMonitor --watcher-resource-group NetworkWatcherRG --watcher-name NetworkWatcher_japaneast

実サーバーの出力例(接続可能な場合):

{ "sourceStatus": "Active", "states": [ { "avgLatencyInMs": 1.23, "connectionState": "Reachable", "maxLatencyInMs": 3.10, "minLatencyInMs": 0.91, "probesFailed": 0, "probesSent": 10 } ] }

connectionState: "Unreachable" が返った場合は、IP Flow VerifyとNSGフローログを組み合わせて障害箇所を切り分ける。

トラブルシュート:よくある遮断パターンと対処

症状 まず使うツール よくある原因 対処
VNet内VM間で通信不可 IP Flow Verify NSGのOutbound/Inboundルール漏れ az network nsg rule createでルール追加
特定ポートだけ繋がらない パケットキャプチャ VM側のfirewalldが遮断している firewall-cmd --add-portで開放
通信は通るが遅い Connection Monitor NVA/Firewallを経由する不要なルート UDRのnext-hopをVirtualNetworkに変更
原因が複合的で不明 NSGフローログ 複数NSGのDenyルールが競合 フローログでDeny記録の送信元・宛先を特定

本記事のまとめ

Azure Network Watcherが提供する4つのツールを使い分けることで、VNet通信の問題を効率的に切り分けられる。
ツール 用途 主なazコマンド
IP Flow Verify NSGが通信を許可/遮断するかを即時判定 az network watcher test-ip-flow
NSGフローログ 実通信のAllow/Denyを時系列で記録 az network watcher flow-log create
パケットキャプチャ VMの実パケットを.capファイルに保存 az network watcher packet-capture create
Connection Monitor エンドツーエンドの到達性を継続監視 az network watcher connection-monitor create

実運用での使い順は「IP Flow Verifyで素早くNSG起因を切り分け→原因が複合的なときはNSGフローログで時系列を確認→VMレベルで通信を実測したいときはパケットキャプチャ→本番環境の定常監視にはConnection Monitor」という流れが標準だ。

次に読む記事:
Linux ポート確認の全コマンド(ss・lsof・netstatでポートと接続状態を調べる方法)
Linux DNS 設定の基本(resolv.confとnmcliで名前解決を設定する方法)

Azure Network Watcherを使ったVNet診断も、ハンズオンで体系的に習得できます

NSGフローログやIP Flow Verifyによるトラブルシューティングは、Azureインフラ運用の核となるスキルです。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、Azureハンズオン学習コースでは実機を使った演習で即戦力スキルを習得できます。

「Linuxの基礎から体系的に学びたい」という方には、『Linuxサーバー構築入門マニュアル(図解60P)』を無料でプレゼントしています。こちらから無料ダウンロード

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。