Microsoft Azure での仮想ネットワーク接続のトラブルシューティング

  • 7 分

Peer 間でトラフィックが許可されるかどうかを判断する

ピアリングを使用すると、Azure で 2 つ以上の仮想ネットワークを接続できます。 仮想ネットワーク間のトラフィックは、ゲートウェイやパブリック インターネット経由ではなく、Microsoft のバックボーン インフラストラクチャを通じてルーティングされます。 Azure でのピアリングは 2 種類あります。

  • 仮想ネットワーク ピアリング: 同じ Azure リージョン内の仮想ネットワークが接続されます。

  • グローバル仮想ネットワーク ピアリング: 異なる Azure リージョン内の仮想ネットワークが接続されます。

グローバル仮想ネットワーク ピアリングには、次の制約があります。

  • 仮想ネットワーク内のリソースは、グローバルにピアリングされた仮想ネットワークの Basic 内部ロード バランサー (ILB) のフロントエンド IP アドレスと通信することはできません。

  • Basic ロード バランサーを使用する一部のサービスは、グローバルな仮想ネットワーク ピアリングでは動作しません。

  • クラウド間ではピアリングできません。

  • ピアリングする仮想ネットワークの IP アドレス空間が重複していてはいけません。

  • 2 つの仮想ネットワークがピアリングされている場合、仮想ネットワークのアドレス空間からアドレスの範囲を追加または削除することはできません。 アドレスの範囲を追加または削除するには、ピアリングを削除し、アドレスの範囲を追加または削除してからピアリングを再作成します。

  • クラシック デプロイ モデルを使用して作成された 2 つの仮想ネットワークをピアリングすることはできません。

  • Azure の組み込みの名前解決では、ピアリングされた仮想ネットワーク内の名前は解決されません。 他の仮想ネットワークで名前を解決するには、Azure プライベート ゾーンまたはカスタム DNS サーバーを使う必要があります。

  • Azure 仮想ネットワーク ゲートウェイを使用すると、仮想ネットワークを別の仮想ネットワークとピアリングすることも接続することもできます。 ピアリングとゲートウェイの両方を使用して仮想ネットワークが接続されている場合、仮想ネットワーク間のトラフィックは、ゲートウェイではなく、ピアリング構成を介して流れます。

  • 新しいルートを確実にクライアントにダウンロードするには、仮想ネットワーク ピアリングが正常に構成された後で、もう一度ポイント対サイト VPN クライアントをダウンロードする必要があります。

Peer 間の接続のトラブルシューティングを行うには、次の手順を実行します。

  1. ピアリング接続の状態を確認します。

    • [開始済み] は、双方向のリンクがないことを示します。 たとえば、VNetA と VNetB をピアリングするには、2 つのリンクを作成する必要があります。1 つは VNetA から VNetB へ、もう 1 つは VNetB から VNetA へのリンクです。 両方のリンクを作成すると、状態が "接続済み" に変更されます。

    • [切断] は、いずれかのリンクが削除されたことを示します。 ピアリング接続を再確立するには、どちらのリンクも削除して再作成する必要があります。

  2. 2 つの VNet に一致または重複するアドレス範囲がないことを確認します。

VPN ゲートウェイの転送に関する問題のトラブルシューティング

ゲートウェイ転送は、VNet 間接続の際に、1 つの仮想ネットワークで、ピアリングされた仮想ネットワーク内の VPN ゲートウェイを使用できるようにするピアリング プロパティです。 次の図で、仮想ネットワーク ピアリングでのゲートウェイ転送のしくみを確認できます。

Diagram of gateway transit with virtual network peering.

仮想ネットワークがグローバルにピアリングされている場合、次の制約が適用されます。

  • 1 つの仮想ネットワーク内のリソースは、グローバルにピアリングされた仮想ネットワーク内の Basic ILB のフロントエンド IP アドレスと通信することはできません。

  • Basic ロード バランサーを使用する一部のサービスは、グローバルな仮想ネットワーク ピアリングでは動作しません。 詳細については、「グローバル VNet ピアリングと Load Balancer に関連する制約とは」を参照してください。

VPN ゲートウェイの転送に関する問題のトラブルシューティングを行うには、以下を試してみてください。

  • スポーク仮想ネットワークに既に VPN ゲートウェイがある場合、ピアリング制限により、[リモート ゲートウェイを使用する] オプションはスポーク仮想ネットワークではサポートされません。

  • 同じリージョン内のスポーク仮想ネットワーク間のハブスポーク ネットワーク接続に関する問題については、ハブ ネットワークに NVA を含める必要があります。 NVA がネクスト ホップとして設定されているスポークで UDR を構成し、ハブ仮想ネットワークで [転送されたトラフィックを許可する] を有効にします。

Peer 間の推移性のトラブルシューティング

推移的なピアリングは、次の場合に発生します。

  • VNetA を VNetB にピアリングする場合。

  • VNetB を VNetC にピアリングする場合。

  • 既定では、VNetA は VNetC とピアリングされていません。

VNetA と VNetC の間でピアリングを実現するには、それらを一緒にピアリングする必要があります。 または、ハブとスポークの構成を使用し、ハブ内の NVA を経由します。

Screenshot showing all v nets peered to each other.

ハブとスポークの VNet 構成のトラブルシューティング

ハブとスポークの構成では、ハブ仮想ネットワークは、多くのスポーク仮想ネットワークに接続するための中心的なポイントとして機能します。 ハブは、オンプレミス ネットワークへの接続ポイントとしても使用できます。 スポーク仮想ネットワークはハブとピアリングし、ワークロードを分離するために使用できます。

Screenshot showing Hub-and-spoke configuration.

ハブスポーク仮想ネットワークとオンプレミス リソース間の接続をトラブルシューティングする方法を次に示します。

ネットワークでサードパーティの NVA が使用されている場合は、次のことを確認します。

  • ソフトウェアの更新プログラム。

  • サービス アカウントのセットアップと機能。

  • NVA に直接通信する仮想ネットワークのサブネット上のユーザー定義のルート (UDR)。

  • NVA から直接通信する仮想ネットワークのサブネット上の UDR。

  • NVA 内のテーブルとルールのルーティング (例: NIC1 から NIC2)。

  • ネットワーク トラフィックの送受信を確認するための NVA NIC のトレース。

  • Standard SKU と Public IP を使用するときは、NSG が作成されていて、NVA へのトラフィックのルーティングを許可する明示的なルールが存在する必要があります。

  • Azure 上の NVA に対する最小構成。

ネットワークで VPN ゲートウェイが使用されている場合は、次のことを確認します。

  • ゲートウェイは、Resource Manager モデルの仮想ネットワーク内にある必要があります。

ネットワークでサードパーティの NVA または VPN ゲートウェイが使用されていない場合、ハブ仮想ネットワークとスポーク仮想ネットワークに VPN ゲートウェイがありますか? スポーク仮想ネットワークに既に VPN ゲートウェイがある場合、スポーク仮想ネットワークでは [リモート ゲートウェイを使用する] オプションはサポートされません。 これは、仮想ネットワーク ピアリングの制限によるものです。

サイト間または Azure ExpressRoute 接続の場合は、オンプレミスからリモート仮想ネットワークへの接続に関する問題の、以下に示す原因を確認します。

  • 仮想ネットワークにゲートウェイがある場合、[トラフィック転送を許可する] チェック ボックスがオンになっていることを確認します。

  • 仮想ネットワークにゲートウェイがない場合、[リモート ゲートウェイを使用する] チェック ボックスがオンになっていることを確認します。

  • オンプレミス デバイスを調べ、それらすべてにリモート仮想ネットワーク アドレス空間が追加されていることを確認するようにネットワーク管理者に依頼します。

ポイント対サイト接続の場合:

  • ゲートウェイがある仮想ネットワークで [転送されたトラフィックを許可する] チェック ボックスがオンになっていることを確認します。

  • ゲートウェイがない仮想ネットワークで [リモート ゲートウェイを使用する] チェック ボックスがオンになっていることを確認します。

  • ポイント対サイト クライアント パッケージをダウンロードして再インストールします。 新しくピアリングされた仮想ネットワーク ルートでは、ポイント対サイト クライアントにルートが自動的に追加されません。

グローバル ピアリング接続のトラブルシューティング

ピアリングされた仮想ネットワーク間の接続に関する問題のトラブルシューティングは次のとおりです。

  1. 必要なロールとアクセス許可があるアカウントで、Azure portal にサインインします。

  2. 仮想ネットワークを選択して、[ピアリング] を選択してから [状態] フィールドを選択します。

  3. 状態が [切断] の場合は、両方の仮想ネットワークからピアリングを削除し、再作成します。

  4. 状態が [接続済み] の場合は、ネットワーク トラフィック フローを確認します。

接続のトラブルシューティングと、ソース VM から宛先 VM への IP フロー検証を使用して、トラフィック フローの干渉の原因となっている NSG または UDR があるかどうかを判断します。

ファイアウォールまたは NVA を使用している場合:

  1. この手順の完了後に復元できるように、UDR パラメーターをドキュメント化します。

  2. 次ホップとして NVA を指すソース VM サブネットまたは NIC から UDR を削除します。 ソース VM から、NVA をバイパスしている宛先への直接の接続を確認します。

  3. ネットワーク トレースを取得する:

  • 宛先 VM でネットワーク トレースを開始します。 Windows の場合は、Netsh を使用できます。 Linux の場合は、TCPDump を使用します。 - ソースから宛先 IP への TcpPing または PsPing を実行します。 これは TcpPing コマンドの例です:
tcping64.exe -t <destination VM address> 3389

TcpPing が完了した後、宛先のネットワーク トレースを停止します。 ソースからパケットが到着した場合、ネットワークの問題はありません。 VM ファイアウォールと、そのポートでリッスンしているアプリケーションの両方を調べ、構成の問題を特定します。

Note

グローバル仮想ネットワーク ピアリング (異なるリージョン内の仮想ネットワーク) 経由では、次の種類のリソースに接続することはできません。

  • Basic ILB SKU の背後にある VM

  • Redis Cache (Basic ILB SKU を使用)

  • Application Gateway (Basic ILB SKU を使用)

  • スケール セット (Basic ILB SKU を使用)

  • Service Fabric クラスター (Basic ILB SKU を使用)

  • SQL Server Always On (Basic ILB SKU を使用)

  • App Service Environment (Basic ILB SKU を使用)

  • API Management (Basic ILB SKU を使用)

  • Microsoft Entra Domain Services (Basic ILB SKU を使用)

詳細については、グローバル ピアリングの「要件と制約」を参照してください。

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

次の手順で行います。

  • ゲートウェイが静的ルーティングではなく動的ルーティングを使用して構成されていることを確認します。 静的ルーティングはサポートされていません。

  • VPN 接続の数を確認します。 基本および標準の動的ルーティング ゲートウェイの場合、特定の VNet が接続できる VPN 接続と VNet の最大数は現在 10 です。 ハイ パフォーマンス ゲートウェイの場合は 30 です。

  • 両方の VNet のアドレス プレフィックスを調べて、2 つの VNet 間にアドレス空間が重複しないようにします。

サービス チェイニングのトラブルシューティング

サービス チェイニングは、ユーザー定義ルートを介して、ピアリングされたネットワーク内の 1 つの仮想ネットワークから NVA にトラフィックを送信する機能です。 ピアリングされた仮想ネットワーク内で、仮想マシンを指すユーザー定義ルートをネクスト ホップの IP アドレスとして構成します。 ルート テーブルを設定し、サブネットに関連付ける必要があります。 ネットワーク トラフィックのルーティング手順については、「チュートリアル: Azure Portal を使用してルート テーブルでネットワーク トラフィックをルーティングする」を参照してください。

PowerShell を使用すると、tracert を使用してネットワーク トラフィックのルーティングをテストできます。

tracert myvmprivate

これによりトレース ルートが表示され、トラフィックが予想したルートを使用しているかどうかを確認できます。 tracert には、次のような応答があります。

Tracing route to myvmprivate.q04q2hv50taerlrtdyjz5nza1f.bx.internal.cloudapp.net [10.0.1.4] over a maximum of 30 hops:

1     1 ms     *        2 ms  myvmnva.internal.cloudapp.net [10.0.2.4]

2     2 ms     1 ms     1 ms  myvmprivate.internal.cloudapp.net [10.0.1.4]

Trace complete.