仮想ネットワークピアリングルートの伝達と同期に関する問題のトラブルシューティング

まとめ

この記事は、Azure 仮想ネットワークピアリングに関する一般的なルート伝達、ピアリング同期、ドメインネームシステム (DNS) の解決、および監視の問題を診断して解決するのに役立ちます。構成、接続、エラーメッセージなどの一般的なピアリングのトラブルシューティングについては、「仮想ネットワークピアリングの問題のトラブルシューティング」を参照してください。

前提条件

アクティブなサブスクリプションが含まれる Azure アカウント
Azure CLI または Azure PowerShell がインストールされている
仮想ネットワークがデプロイされているリージョンで有効になっている Azure Network Watcher
両方の仮想ネットワークに対するネットワーク共同作成者ロールまたは同等のアクセス許可

原因 1: ピアリングの作成または変更後のルート伝達の遅延

仮想ネットワークピアリングのセットアップを作成または変更すると、ピアリングされた仮想ネットワーク内のアドレス範囲ごとに、次ホップの種類である 仮想ネットワークピアリングを使用するシステムルートが Azure によって自動的に追加されます。これらのルートの更新はすぐには有効になりません。反映の処理には数分かかる場合があります。

Symptoms

新しくピアリングされた仮想ネットワーク内の仮想マシン (VM) は、ピアリングが作成された直後に相互に到達できません。
ピアリング設定を変更した後 ( [転送されたトラフィックを許可 する] や [ゲートウェイ転送を許可する] を有効にするなど)、トラフィックは期待どおりに動作しません。
VM のネットワークインターフェイス上の有効なルートには、ピアリングされた仮想ネットワークのアドレス空間は表示されません。

解決策: 有効なルートを確認し、伝達を待機する

ピアリング操作が完了してから 2 ~ 5 分待ちます。ほとんどのルート伝達は、このウィンドウ内で終了します。
VM のネットワークインターフェイス上の有効なルートを調べて、ピアリングルートが表示されることを確認します。

Azure portal を使用するには:

仮想マシンに移動し、[ ネットワーク] を選択します。
ネットワークインターフェイスを選択します。
[有効なルート] を選択し、仮想ネットワークピアリングの次ホップの種類と、ピアリングされた仮想ネットワークのアドレスプレフィックスを持つエントリを探します。

Azure CLI の場合は、次のコマンドを実行します。

az network nic show-effective-route-table \
  --resource-group <resource-group> \
  --name <nic-name> \
  --output table

Azure PowerShell の場合は、次のコマンドを実行します。

Get-AzEffectiveRouteTable -ResourceGroupName <resource-group> -NetworkInterfaceName <nic-name>

ピアリングルートが 5 分後に表示されない場合:
- ピアリングの状態が両方の仮想ネットワークで接続されていることを確認します。
- 両方の仮想ネットワーク上のアドレス空間が正しく、重複していないことを確認します。
- ルートの伝達をブロックしている Azure Policy がないことを確認します。

ルートが表示されても接続が失敗する場合は、ピアリングトラフィックをオーバーライドまたはブロックしている可能性のあるユーザー定義ルート (UDR) またはネットワークセキュリティグループ (NSG) を確認します。詳細については、「仮想ネットワークピアリングの問題のトラブルシューティング」を参照してください。

原因 2: アドレス空間の変更後にピアリング同期が必要

ピアリングされた仮想ネットワーク内のアドレス範囲を追加、変更、または削除する場合、ピアリングはリモートピアのルーティング情報を更新するために同期する必要があります。同期をスキップまたは遅延した場合、リモートピアリングされた仮想ネットワークは引き続き古いアドレス空間を使用します。この動作により、ルーティングエラーが発生する可能性があります。

Symptoms

ピアリングされた仮想ネットワーク内の新しく追加されたアドレス範囲へのトラフィックは失敗します。
VM のネットワークインターフェイス上の有効なルートには、ピアリングされた仮想ネットワークの古いアドレスプレフィックスが引き続き表示されます。
ピアリングの状態は [接続済み] と表示されますが、ピアリングの詳細に一覧表示されているリモートアドレス空間が、ピアの実際のアドレス空間と一致しません。

解決策: ピアリングを同期し、更新されたルートを確認する

ピアリング内のリモートアドレス空間が、ピアリングされた仮想ネットワークの実際のアドレス空間と一致するかどうかを確認します。 Azure CLI を使用して、次のコマンドを実行します。

# Check the peering's view of the remote address space
az network vnet peering show \
  --resource-group <resource-group> \
  --vnet-name <local-vnet-name> \
  --name <peering-name> \
  --query "remoteAddressSpace.addressPrefixes"

# Check the actual address space of the remote virtual network
az network vnet show \
  --resource-group <remote-resource-group> \
  --name <remote-vnet-name> \
  --query "addressSpace.addressPrefixes"

値が一致しない場合は、ピアリングを同期します。

Azure portal を使用するには:

アドレス空間を変更した仮想ネットワークに移動します。
[ ピアリング] を選択し、ピアリングの横にあるチェックボックスをオンにします。
[同期] を選択します。
リモートピアリングされた仮想ネットワークごとに繰り返します。

Azure CLI の場合は、次のコマンドを実行します。

az network vnet peering sync \
  --resource-group <resource-group> \
  --vnet-name <vnet-name> \
  --name <peering-name>

同期後、リモートアドレス空間が更新されていることを確認します。 Azure CLI を使用して、次のコマンドを実行します。

az network vnet peering show \
  --resource-group <resource-group> \
  --vnet-name <local-vnet-name> \
  --name <peering-name> \
  --query "{state:peeringState, remoteAddressSpace:remoteAddressSpace.addressPrefixes}"

ピアリングされた仮想ネットワーク内の VM 上の有効なルートを調べて、新しいアドレス範囲が存在することを確認します。

Important

アドレス空間が変更されるたびに同期操作を実行します。同期する前に、複数のアドレス空間の変更をバッチ処理しないでください。仮想ネットワークがクラシック仮想ネットワークとピアリングされている場合、アドレス空間の同期はサポートされません。

原因 3: ピアリングされた仮想ネットワーク間の DNS 解決エラー

仮想ネットワークピアリングは、ピアリングされた仮想ネットワーク間のネットワーク層接続を提供しますが、ピア間で DNS 名解決を自動的に有効にすることはありません。 1 つの仮想ネットワーク内の VM は、Azure が提供する既定の DNS のみを使用して、ピアリングされた仮想ネットワーク内の VM のプライベート DNS 名を解決できません。

Symptoms

1 つのピアリングされた仮想ネットワーク内の VM は、もう一方の仮想ネットワーク内の VM のプライベート IP アドレスに ping を実行できますが、ホスト名を使用した DNS 名前解決は失敗します。
nslookup <hostname> または Resolve-DnsName <hostname> は、プライベート IP の代わりに NXDOMAIN またはパブリック IP アドレスを返します。
ピアリング状態が [ 接続済み] であっても、ピアリングされた仮想ネットワーク内のリソースに接続するために DNS 名に依存するアプリケーションは失敗します。

解決策 1: Azure プライベート DNS ゾーンを使用する

Azure プライベート DNS は、カスタム DNS サーバーを使用せずに、ピアリングされた仮想ネットワーク間の VM の名前解決を提供します。

プライベート DNS ゾーン ( contoso.internal など) を作成します。

自動登録を有効にして、プライベート DNS ゾーンを両方のピアリングされた仮想ネットワークにリンクします。 Azure CLI を使用して、次のコマンドを実行します。

# Link to the first virtual network with auto-registration
az network private-dns link vnet create \
  --resource-group <resource-group> \
  --zone-name contoso.internal \
  --name link-vnet1 \
  --virtual-network <vnet1-resource-id> \
  --registration-enabled true

# Link to the second virtual network with auto-registration
az network private-dns link vnet create \
  --resource-group <resource-group> \
  --zone-name contoso.internal \
  --name link-vnet2 \
  --virtual-network <vnet2-resource-id> \
  --registration-enabled true

両方のリンクを作成した後、いずれかの仮想ネットワーク内の VM は、 <hostname>.contoso.internal 形式を使用して相互の名前を解決できます。

解決策 2: カスタム DNS 転送を構成する

カスタム DNS サーバーを既に使用している場合は、ピアリングされた仮想ネットワークの DNS ゾーンの条件付き転送を構成します。

DNS サーバーで、ピアリングされた仮想ネットワークの DNS ゾーンの条件付きフォワーダーを作成します。 Azure DNS 再帰リゾルバー ( 168.63.129.16) をポイントします。
カスタム DNS サーバーを指す各仮想ネットワークの DNS 設定を構成します。仮想ネットワークに移動し、 DNS サーバーを選択し、DNS サーバーのプライベート IP アドレスを入力します。
VM を再起動するか、動的ホスト構成プロトコル (DHCP) リースを更新して DNS の変更を取得します。

注

168.63.129.16 の Azure 提供の DNS は、同じ仮想ネットワーク内またはリンクされたプライベート DNS ゾーン内の VM のみの名前を解決します。 VNet 間の名前解決には、カスタム DNS サーバーまたは Azure プライベート DNS ゾーンが必要です。

原因 4: ボーダーゲートウェイプロトコルルートとピアリングルートの競合

VPN ゲートウェイまたは ExpressRoute と Border Gateway Protocol (BGP) を使用するハイブリッド環境では、オンプレミスからアドバタイズされたルートが仮想ネットワークピアリングルートと競合しているように見える場合があります。 BGP がより具体的なプレフィックスをアドバタイズする場合でも、ピアリングされた仮想ネットワークのシステムルートは BGP で学習されたルートよりも優先されます。ただし、ユーザー定義ルート (UDR) は、ピアリングと BGP の両方のシステムルートをオーバーライドする場合があります。この動作により、ゲートウェイまたは仮想アプライアンスを介してピアリングトラフィックが誤ってリダイレクトされる可能性があります。

Symptoms

ピアリングされた仮想ネットワークへのトラフィックは、ピアリングを介して直接ではなく、VPN ゲートウェイまたは Azure ExpressRoute 回線にルーティングされます。
VM のネットワークインターフェイス上の有効なルートには、ピアリングされた仮想ネットワークのアドレス空間と同じまたはより具体的なプレフィックスを持つ BGP ルートが表示されます。
ピアリングされた仮想ネットワークへの接続は断続的に動作するか、予想よりも待機時間が長くなります。トラフィックはオンプレミスパスを通過します。

解決策: BGP ルートの競合を特定して解決する

競合するルートを特定するには、影響を受ける VM のネットワークインターフェイスで有効なルートを確認します。 Azure CLI を使用して、次のコマンドを実行します。
```
az network nic show-effective-route-table \
  --resource-group <resource-group> \
  --name <nic-name> \
  --output table
```
アドレスプレフィックスがピアリングされた仮想ネットワークのアドレス空間と重複するルートを探します。次のホップ種類の列を比較します。
- 仮想ネットワークピアリング ルートは、ピアリングによって追加されるシステムルートです。
- VirtualNetworkGateway ルートは BGP から学習されます。
- ユーザー ルートは、関連付けられているルートテーブルの UDR です。
トラフィックが正しくルーティングされない場合は、次の方法を検討してください。
- 競合する UDR の削除: ユーザー定義ルートがピアリングルートをオーバーライドする場合は、UDR を削除または変更します。システムピアリングルートは既に BGP ルートよりも優先されるため、ピアリング接続を維持するために UDR は必要ありません。サブネットに関連付けられているルートテーブルを確認します。ピアリングトラフィックを誤ってゲートウェイまたは仮想アプライアンスに送信する UDR を削除します。 UDR で次ホップの種類として 仮想ネットワークピアリング を指定することはできません。
- BGP アドバタイズをフィルター処理する: オンプレミスルーターで、ピアリングされた仮想ネットワークのアドレス空間と重複するアドレス範囲のアドバタイズを停止します。システムピアリングルートは BGP よりも優先されますが、不要な重複するアドバタイズを削除すると、ルーティングとトラブルシューティングが簡単になります。
- アドレス空間を再設計する: オンプレミスとピアリングされた仮想ネットワークが同じアドレス範囲を共有しているため、重複が存在する場合に競合を排除するためにアドレス空間の移行を計画します。
仮想ネットワークゲートウェイによって学習されるルートを確認します。 Azure CLI を使用して、次のコマンドを実行します。
```
az network vnet-gateway list-learned-routes \
  --resource-group <resource-group> \
  --name <gateway-name> \
  --output table
```
重複を識別するには、これらの学習されたルートをピアリングされた仮想ネットワークアドレス空間と比較します。

原因 5: マルチピアリングトポロジにおけるピアリング状態の非同期化

複数のピアリングされた仮想ネットワーク（複数のスポークを持つハブスポークやメッシュトポロジなど）を含む複雑なトポロジでは、個々のピアリング接続が同期しなくなる可能性があります。このシナリオは、アドレス空間の変更をハブに適用しても、すべてのスポークピアリングに同期しない場合に一般的に見られます。

Symptoms

スポーク仮想ネットワークの中にはハブと通信できるものもありますが、通信できないスポーク仮想ネットワークもあります。
ハブ仮想ネットワークのルートは、一部のスポークに表示されますが、他のスポークでは欠落しています。
ハブでアドレス空間が変更された後、一部のピアリングでは更新されたアドレス空間が表示され、他のピアリングには古いアドレス空間が表示されます。

解決策: すべてのピアリング接続を監査して同期する

ハブ仮想ネットワークのすべてのピアリングを一覧表示し、その同期状態を確認します。 Azure CLI を使用して、次のコマンドを実行します。

az network vnet peering list \
  --resource-group <resource-group> \
  --vnet-name <hub-vnet-name> \
  --query "[].{Name:name, State:peeringState, RemoteAddressSpace:remoteAddressSpace.addressPrefixes, PeeringSyncLevel:peeringSyncLevel}" \
  --output table

PeeringSyncLevelが FullyInSync ではないピアリング、またはリモートアドレス空間が想定される値と一致しないピアリングを特定します。

Azure CLI を使用して、同期外の各ピアリングを同期します。

az network vnet peering sync \
  --resource-group <resource-group> \
  --vnet-name <hub-vnet-name> \
  --name <peering-name>

ハブへのピアリングにも正しいアドレス空間が表示されることを確認するには、各スポーク仮想ネットワークでチェックを繰り返します。

ピアリングが多い大規模な環境の場合は、Azure CLI のスクリプトを使用して監査を自動化します。

# List all peerings that need syncing
az network vnet peering list \
  --resource-group <resource-group> \
  --vnet-name <hub-vnet-name> \
  --query "[?peeringSyncLevel!='FullyInSync'].{Name:name, SyncLevel:peeringSyncLevel}" \
  --output table

Azure Monitor を使用してピアリングの状態を監視する

プロアクティブ監視は、接続に影響する前にピアリングの問題を検出するのに役立ちます。 Azure Monitor には、仮想ネットワークピアリングのメトリックとアラートが用意されています。

使用可能なピアリングメトリック

メトリクス	説明
VM への ping のラウンドトリップ時間 (`PingMeshAverageRoundtripMs`)	ピアリングされた仮想ネットワーク内の VM を含め、VM 間で送信される ping の平均ラウンドトリップ時間。急激な増加は、ピアリング接続の問題を示している可能性があります。
VM への ping の失敗 (`PingMeshProbesFailedPercent`)	宛先 VM に対して失敗した ping の割合。スパイクは、ピアリングルートが欠落しているか、トラフィックがブロックされていることを示している可能性があります。

注

ピアリングの状態 (接続済み、切断済み、または 開始済み) はリソースプロパティであり、Azure Monitor メトリックではありません。ピアリングの状態を確認するには、 az network vnet peering show を使用するか、Azure portal (設定>Peerings) でピアリングの詳細を表示します。

ピアリングの問題のアラートを設定する

Azure portal で、仮想ネットワークに移動します。
[ 監視>メトリック] を選択します。
VMへのPingの失敗またはVMへのPingのラウンドトリップ時間のメトリックを選択し、トラフィックパターンを確認します。
トラフィックが急激に減少した場合のアラートを作成するには:
1. [新しいアラートルール] を選択します。
2. VM への Ping の失敗 (PingMeshProbesFailedPercent) が接続エラーを示すしきい値を超えた場合、または VM への Ping のラウンドトリップ時間 (PingMeshAverageRoundtripMs) が許容される待機時間を超えたときにトリガーする条件を設定します。
3. 操作チームに通知するようにアクショングループを構成します。

ピアリング診断に Azure Network Watcher を使用する

Azure Network Watcher には、次の機能を含む、ピアリング接続を診断するためのツールが用意されています。

接続のトラブルシューティング: ピアリングされた仮想ネットワーク内の VM 間の接続をテストし、接続が失敗した場所 (NSG、UDR、またはルーティングの問題) を特定します。
次ホップ: ピアリングされた仮想ネットワーク内の VM 間のトラフィックの次ホップを確認します。このチェックでは、トラフィックがピアリングルートを使用しているか、UDR によってリダイレクトされるかが確認されます。
有効なルート: ネットワークインターフェイス上の有効なルートを表示して、ピアリングルートが存在し、オーバーライドされていないことを確認します。
IP フロー検証: NSG ルールがピアリングされた仮想ネットワーク間のトラフィックをブロックしているかどうかを確認します。

次のステップ

フィードバック

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

Last updated on 2026-03-24

仮想ネットワーク ピアリング ルートの伝達と同期に関する問題のトラブルシューティング

まとめ

前提条件

原因 1: ピアリングの作成または変更後のルート伝達の遅延

Symptoms

解決策: 有効なルートを確認し、伝達を待機する

原因 2: アドレス空間の変更後にピアリング同期が必要

Symptoms

解決策: ピアリングを同期し、更新されたルートを確認する

原因 3: ピアリングされた仮想ネットワーク間の DNS 解決エラー

Symptoms

解決策 1: Azure プライベート DNS ゾーンを使用する

解決策 2: カスタム DNS 転送を構成する

原因 4: ボーダー ゲートウェイ プロトコル ルートとピアリング ルートの競合

Symptoms

解決策: BGP ルートの競合を特定して解決する

原因 5: マルチピアリング トポロジにおけるピアリング状態の非同期化

Symptoms

解決策: すべてのピアリング接続を監査して同期する

Azure Monitor を使用してピアリングの状態を監視する

使用可能なピアリング メトリック

ピアリングの問題のアラートを設定する

ピアリング診断に Azure Network Watcher を使用する

次のステップ

フィードバック

その他のリソース

仮想ネットワークピアリングルートの伝達と同期に関する問題のトラブルシューティング

原因 4: ボーダーゲートウェイプロトコルルートとピアリングルートの競合

原因 5: マルチピアリングトポロジにおけるピアリング状態の非同期化

使用可能なピアリングメトリック