Azure 仮想マシン間の接続に関する問題のトラブルシューティング

概要

Azure仮想マシン (VM) 間で接続の問題が発生する可能性があります。この記事では、この問題の解決に役立つトラブルシューティング手順について説明します。

症状

1 つのAzure VM が別のAzure VM に接続できません。

トラブルシューティングガイダンスの概要

NIC が正しく構成されていないかどうかを確認する
ネットワークトラフィックが NSG または UDR によってブロックされているかどうかを確認する
VM ファイアウォールによってネットワークトラフィックがブロックされているかどうかを確認する
VM アプリまたはサービスがポートでリッスンしているかどうかを確認する
問題が送信元ネットワークアドレス変換 (SNAT) によって発生しているかどうかを確認する
クラシック VM の ACL によってトラフィックがブロックされているかどうかを確認する
クラシック VM 用にエンドポイントが作成されているかどうかを確認する
VM ネットワーク共有への接続を試みる
Inter-VNet 接続を確認する

注

PowerShell の Test-NetConnection モジュールを使用して、接続の情報を診断することもできます。

トラブルシューティングの手順

問題のトラブルシューティングを行うには、次の手順に従います。各手順を完了したら、問題が解決されたかどうかを確認します。

手順 1: NIC が正しく構成されていないかどうかを確認する

AZURE WINDOWS VM のネットワークインターフェイスをリセットする方法の手順に従います。

ネットワークインターフェイス (NIC) を変更した後に問題が発生した場合は、次の手順に従います。

マルチNIC VM

NIC を追加します。
無効な NIC の問題を修正するか、無効な NIC を削除します。次に、NIC をもう一度追加します。

詳細については、「仮想マシンへのネットワークインターフェイスの追加または仮想マシンからの削除」を参照してください。

Single-NIC VM

手順 2: ネットワークトラフィックが NSG または UDR によってブロックされているかどうかを確認する

ネットワークセキュリティグループ (NSG) と User-Defined ルート (UDR) は、VM 間のトラフィックフローに干渉する可能性があります。サブネットレベルとネットワークインターフェイス (NIC) レベルの両方で NSG を適用します。トラフィックは両方を通過する必要があります。 NSG または UDR 関連のブロックを診断するには、次のサブステップを使用します。

Network Watcher IP フロー検証を使用する

IP フロー検証では、VM との間で送受信されるトラフィックを許可または拒否している NSG ルールをすばやく識別します。

Azure portal で、 Network Watcher>IP フロー検証に移動します。
ソース VM のサブスクリプションとリソースグループを選択します。
入力：
- 方向: インバウンドまたはアウトバウンド。
- プロトコル: TCP (伝送制御プロトコル) または UDP (ユーザーデータグラムプロトコル)。
- ローカルポート: VM 上の宛先ポート (リモートデスクトッププロトコル (RDP) の場合は 3389、Secure Shell (SSH) の場合は 22 など)。
- リモート IP アドレス: 接続している VM の IP。
- リモートポート: ソースポート (または任意のポートに * を使用します)。
[ チェック ] を選択して、トラフィックを許可または拒否している NSG ルールを確認します。

Azure CLI または Azure PowerShell を使用することもできます。

az network watcher test-ip-flow \
  --direction Inbound \
  --protocol TCP \
  --local 10.0.0.4:3389 \
  --remote 10.0.1.4:* \
  --vm <vm-resource-id> \
  --nic <nic-name>

Test-AzNetworkWatcherIPFlow `
  -NetworkWatcher $networkWatcher `
  -Direction Inbound `
  -Protocol TCP `
  -LocalIPAddress 10.0.0.4 `
  -LocalPort 3389 `
  -RemoteIPAddress 10.0.1.4 `
  -RemotePort * `
  -TargetVirtualMachineId <vm-resource-id>

詳細については、「 Network Watcher IP フロー検証の概要」を参照してください。

接続トラブルシューティング

接続のトラブルシューティングでは、ソース VM と宛先の間の接続をテストします。接続が成功したか失敗したか、および問題の原因となっている NSG ルールまたは構成が識別されます。

Azure portal で、 Network Watcher>Connection のトラブルシューティングに移動します。
ソース VM と宛先 (VM、Uniform Resource Identifier (URI)、完全修飾ドメイン名 (FQDN)、または IP アドレス) を選択します。
宛先ポートとプロトコルを指定します。
[ チェック ] を選択して、パスに沿って評価された特定の NSG ルールを含む結果を表示します。

有効なセキュリティ規則を表示する

有効なセキュリティ規則ビューには、サブネットレベルの NSG から継承された規則を含め、ネットワークインターフェイスに適用されるすべての NSG 規則が表示されます。

Azure portal で、VM の ネットワーク設定に 移動します。
ネットワークインターフェイスを選択します。
[ 有効なセキュリティ規則 ] を選択すると、NIC レベルとサブネットレベルの NSG の両方から結合された規則が表示されます。

Azure CLI を使用することもできます。

az network nic list-effective-nsg --resource-group <resource-group> --name <nic-name>

詳細については、「 VM ネットワークトラフィックフィルターの問題を診断する」を参照してください。

サブネットレベルと NIC レベルの両方で NSG ルールを確認する

VM 間のトラフィックは、サブネットレベルの NSG と NIC レベルの NSG の両方を通過する必要があります。サブネットレベルでトラフィックを許可するルールは、引き続き NIC レベルでブロックできます。その逆も同様です。両方のレベルでルールを確認するには:

Azure portal で、VM のネットワーク設定に移動して、NIC レベルの NSG 規則を確認します。
仮想ネットワークのサブネット構成に移動して、サブネットレベルの NSG 規則を確認します。
両方の NSG に、必要なプロトコルとポートの許可規則があることを確認します。

NSG の一般的な構成ミス

優先度の競合: 優先度の高い拒否規則 (低い番号) は、優先度の低い許可規則をオーバーライドします。許可ルールがシャドウされていないことを確認するには、ルールの優先順位を確認します。
両方の NSG に受信規則がない: サブネットレベルの NSG と NIC レベルの NSG の両方で受信許可規則が必要になる場合があります。
ソース IP の制限: ソース IP アドレスを制限する規則によって、異なるサブネットまたは仮想ネットワーク内の VM からのトラフィックが誤ってブロックされる可能性があります。ソース IP を確認するか、適切なサービスタグを使用します。
既定の拒否規則: 既定の DenyAllInbound 規則 (priority 65500) は、明示的に許可されていないすべての受信トラフィックをブロックします。優先順位の低い明示的な許可規則を追加します。
サービスタグの誤解: VirtualNetwork などのサービスタグには、仮想ネットワークアドレス空間、ピアリングされたネットワーク、ゲートウェイ経由で接続されたオンプレミスネットワークが含まれます。ルール内のサービスタグが予想されるトラフィックソースと一致することを確認します。

フローログを使用してトラフィックを分析する

問題が断続的または再現が困難な場合は、フローログを使用してトラフィックパターンを分析します。

仮想ネットワーク (VNet) フローログ (推奨): VNet フローログは、VNet レベルでフローごとの状態とスループットデータを提供し、すべてのワークロードのトラフィックをキャプチャします。詳細については、 VNet フローログの概要を参照してください。
NSG フローログ: NSG フローログは、NSG を通過する IP トラフィックに関する情報をキャプチャします。詳細については、「 NSG フローログの概要」を参照してください。

Important

NSG フローログは、2027 年 9 月 30 日に廃止されます。この提供終了の一環として、2025 年 6 月 30 日以降、新しい NSG フローログを作成することはできません。必ず仮想ネットワークフローログに移行してください。

Traffic Analytics を使用してフローログデータを視覚化し、ブロックされたトラフィックパターンを特定します。

UDR の確認

NSG ルールが正しく表示される場合は、UDR がトラフィックをドロップまたはフィルター処理している可能性がある予期しない次ホップ (ネットワーク仮想アプライアンスなど) にトラフィックをリダイレクトしているかどうかを確認します。

Azure portal で、VM の ネットワーク設定に 移動します。
ネットワークインターフェイスを選択し、[ 有効なルート] を選択します。
ネットワーク仮想アプライアンス (NVA) または予期しない次ホップにトラフィックを送信するルートを探します。

詳細については、「仮想ネットワークトラフィックのルーティング」を参照してください。

手順 3: VM ファイアウォールによってネットワークトラフィックがブロックされているかどうかを確認する

ファイアウォールを無効にし、結果をテストします。問題が解決した場合は、ファイアウォールの設定を確認してから、ファイアウォールを再度有効にします。

手順 4: VM アプリまたはサービスがポートでリッスンしているかどうかを確認する

次のいずれかの方法を使用して、VM アプリまたはサービスがポートをリッスンしているかどうかを確認します。

次のコマンドを実行して、サーバーがそのポートをリッスンしているかどうかを確認します。

Windows VM

netstat –ano

Linux VM

netstat -l

仮想マシン自体で telnet コマンドを実行して、ポートをテストします。テストが失敗した場合、アプリケーションまたはサービスはそのポートでリッスンするように構成されていません。

手順 5: ソースネットワークアドレス変換 (SNAT) によって問題が発生するかどうかを確認する

一部のシナリオでは、Azure の外部のリソースに依存するロードバランサーソリューションの背後に VM を配置します。これらのシナリオでは、断続的な接続の問題が発生した場合、 SNAT ポートの枯渇によって問題が発生する可能性があります。この問題を解決するには、次のいずれかの方法を使用します。

NAT ゲートウェイをサブネットに関連付けます (推奨)。
パブリック IP アドレスを VM に直接割り当てます。
Standard ロードバランサーで送信規則を構成します。

NSG ルールを使用して公開 VM をセキュリティで保護し、受信アクセスを制限します。

手順 6: クラシック VM の ACL によってトラフィックがブロックされているかどうかを確認する

アクセス制御リスト (ACL) は、仮想マシンエンドポイントのトラフィックを選択的に許可または拒否する機能を提供します。詳細については、「エンドポイントでの ACL の管理」を参照してください。

手順 7: クラシック VM 用にエンドポイントが作成されているかどうかを確認する

クラシックデプロイモデルを使用してAzureで作成したすべての VM は、プライベートネットワークチャネル経由で、同じクラウドサービスまたは仮想ネットワーク内の他の仮想マシンと自動的に通信できます。ただし、他の仮想ネットワーク上のコンピューターでは、受信ネットワークトラフィックを仮想マシンに転送するエンドポイントが必要です。詳細については、「エンドポイントを設定する方法」を参照してください。

VM ネットワーク共有に接続できない場合は、VM で使用できない NIC が原因で問題が発生している可能性があります。使用できない NIC を削除するには、「使用できない NIC を削除する方法」を参照してください。

手順 9: Inter-VNet 接続を確認する

Network Watcher IP フロー検証を使用して、NSG または UDR がトラフィックフローに干渉しているかどうかを判断します。 VNet フローログ (推奨) または NSG フローログを使用して、仮想ネットワーク間のトラフィックパターンを分析します。また、 VPN Gateway のトポロジと設計に関するドキュメントを確認して、VNet または VPN 接続を確認することもできます。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-03-19