「オンプレミスのサーバーからAzureのスポークVNetにVPN Gateway経由で通信しようとしても応答がない」
この記事では、Azure CLIが使えるLinux環境（Ubuntu 22.04 LTS～24.04 LTS、またはAzure Cloud Shell）を想定環境として、Azure VNet Peeringの基本設定からオンプレミス統合まで、azコマンドを使った実践的な手順を解説します。特に「トランジットルーティングがなぜ通らないのか」という設計上の落とし穴と、その回避策まで踏み込んで説明します。
この記事のポイント
・ VNet Peeringは双方向設定が必須（片方だけでは通らない）
・ Gateway Transitを使えばスポークからオンプレへ通信できる
・ スポーク間のトランジットはデフォルト非推移的（通らない設計仕様）
・ Azure Route Server＋NVAでトランジットルーティングを実現できる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
Azure VNet Peeringとは何か？なぜ必要なのか
Azure Virtual Network Peering（VNet Peering）は、異なるVNet同士をMicrosoftのバックボーンネットワーク経由で接続する機能です。VPN GatewayのようなゲートウェイデバイスやIPsecトンネルを必要とせず、低レイテンシー・高帯域幅でVNet間通信を実現します。インターネットを経由しないため、通信は常にMicrosoftのバックボーン上に留まります。VNet Peeringには2種類あります。
・Local VNet Peering：同一リージョン内のVNet同士を接続。レイテンシーは最小限
・Global VNet Peering：異なるリージョンのVNet同士を接続。クロスリージョン通信が可能
典型的なユースケースは「ハブ&スポーク構成」です。共有サービス（VPN Gateway・Azure Firewall・DNS）をハブVNetに集約し、システムごとのスポークVNetをピアリングで接続します。オンプレミスとの接続はハブに集約することで、スポークごとにVPN Gatewayを用意するコストを削減できます。
ただし、VNet Peeringには重要な制限があります。それが「トランジットルーティング」の問題です。この点は後半で詳しく説明します。
VNet Peeringの基本設定手順
1. 準備：VNetを2つ作成する
まずリソースグループと2つのVNetを作成します。ここではHub-VNetとSpoke1-VNetを作る例で進めます。# リソースグループを作成 az group create --name rg-peering-lab --location japaneast # Hub VNet（10.0.0.0/16）を作成 az network vnet create --resource-group rg-peering-lab --name Hub-VNet --address-prefix 10.0.0.0/16 --subnet-name HubSubnet --subnet-prefix 10.0.1.0/24 # Spoke1 VNet（10.1.0.0/16）を作成 az network vnet create --resource-group rg-peering-lab --name Spoke1-VNet --address-prefix 10.1.0.0/16 --subnet-name Spoke1Subnet --subnet-prefix 10.1.1.0/24
2. ピアリングを設定する（双方向が必須）
VNet Peeringは必ず双方向で設定する必要があります。Hub→Spoke1の設定だけでは通信できません。# Hub から Spoke1 へのピアリングを作成 az network vnet peering create --resource-group rg-peering-lab --name Hub-to-Spoke1 --vnet-name Hub-VNet --remote-vnet Spoke1-VNet --allow-vnet-access true # Spoke1 から Hub へのピアリングを作成（逆方向も必須） az network vnet peering create --resource-group rg-peering-lab --name Spoke1-to-Hub --vnet-name Spoke1-VNet --remote-vnet Hub-VNet --allow-vnet-access true
3. ピアリングの状態を確認する
ピアリングが正しく設定されると `Peering state` が `Connected` になります。az network vnet peering list --resource-group rg-peering-lab --vnet-name Hub-VNet --output table # 出力例（環境により異なります） # Name PeeringState AllowVnetAccess AllowGatewayTransit UseRemoteGateways # -------------- -------------- ----------------- --------------------- ----------------- # Hub-to-Spoke1 Connected True False False
疎通確認はスポークVMにSSHしてから行います。LinuxのVMを使っている場合はLinux ポート確認の全コマンドを使って、ピア先VNetのVMへの到達性を確認できます。
ハブ&スポーク構成でオンプレミスと統合する
オンプレミスのネットワークをAzureと接続する構成では、ハブVNetにVPN Gatewayを配置し、スポークVNetはピアリングでハブに接続します。この構成で「Gateway Transit（ゲートウェイ転送）」を有効にすると、スポークのVMがハブのVPN Gateway経由でオンプレミスと通信できるようになります。1. ハブVNetにGatewaySubnetとVPN Gatewayを配置する
VPN GatewayはGatewaySubnetという名前のサブネットにのみデプロイできます（名前は固定）。# GatewaySubnetを作成（名前はGatewaySubnetで固定。/27以上が推奨） az network vnet subnet create --resource-group rg-peering-lab --vnet-name Hub-VNet --name GatewaySubnet --address-prefix 10.0.255.0/27 # パブリックIPを作成 az network public-ip create --resource-group rg-peering-lab --name Hub-GW-PIP --sku Standard --allocation-method Static # VPN Gatewayを作成（デプロイに20分～45分かかります） az network vnet-gateway create --resource-group rg-peering-lab --name Hub-VPN-GW --vnet Hub-VNet --public-ip-address Hub-GW-PIP --gateway-type Vpn --vpn-type RouteBased --sku VpnGw1
2. Hub側ピアリングでGateway Transitを有効にする
VPN Gatewayのデプロイが完了（`provisioningState: Succeeded`）したら、Hub側ピアリングでGateway Transitを有効にします。# Hub-to-Spoke1 ピアリングで Gateway Transit を有効化 az network vnet peering update --resource-group rg-peering-lab --name Hub-to-Spoke1 --vnet-name Hub-VNet --set allowGatewayTransit=true
3. スポーク側でUse Remote Gatewaysを設定する
スポーク側のピアリングで `useRemoteGateways=true` を設定すると、スポークVMがハブのVPN Gatewayを使えるようになります。# Spoke1-to-Hub ピアリングで Use Remote Gateways を有効化 az network vnet peering update --resource-group rg-peering-lab --name Spoke1-to-Hub --vnet-name Spoke1-VNet --set useRemoteGateways=true
なお、オンプレミスのDNSサーバーをスポークVMから参照したい場合は、VNet側のDNS設定でカスタムDNSサーバーを指定する必要があります。LinuxクライアントのDNS動作確認方法はLinux DNS 設定の基本を参照してください。
トランジットルーティングの制限と回避策
スポーク間トランジットはデフォルトで通らない
ハブ&スポーク構成でよく起きる誤解が「スポーク同士はハブ経由で通信できる」という思い込みです。実際には、VNet Peeringはトランジットルーティングをサポートしていません。VNet Peeringは非推移的（non-transitive）な接続のため、ピアリングのチェーン転送は行われません。
たとえば以下の構成を考えます。
・Spoke1-VNet（10.1.0.0/16）― Hub-VNetとピアリング済み
・Hub-VNet（10.0.0.0/16）― Spoke1・Spoke2両方とピアリング済み
・Spoke2-VNet（10.2.0.0/16）― Hub-VNetとピアリング済み
Spoke1のVMからSpoke2のVMへ通信しようとしても、Hub-VNet経由では到達できません。Spoke1とSpoke2を直接ピアリングしないと通信できないのがAzureの仕様です。
同様に、Hub-VNetにAzure Firewallを置いて全スポークのトラフィックを検査したい場合も、デフォルトでは機能しません。UDR（ユーザー定義ルート）でスポークのデフォルトルートをAzure FirewallのプライベートIPに向ける必要があります。
Azure Route Serverを使ったトランジット回避策
スポーク間のトランジットルーティングを実現するアプローチの一つが「Azure Route Server＋NVA（Network Virtual Appliance）」の組み合わせです。・Azure Route Server：Hub-VNetに配置し、NVAとBGPでルート情報を交換する管理プレーン
・NVA：Hub-VNetに配置したルーターVM（Cisco CSR・FortiGate・Linux（FRR）など）
Azure Route Serverを使うことで、NVAが学習したルートをスポークVNetに伝播させられます。Spoke→ハブのNVA→別スポークという経路でトランジットが可能になります。Azure Route ServerのデプロイはRouteServerSubnetという専用サブネット（/27以上）が必要です。
# RouteServerSubnetを作成 az network vnet subnet create --resource-group rg-peering-lab --vnet-name Hub-VNet --name RouteServerSubnet --address-prefix 10.0.254.0/27 # RouteServer用パブリックIPを作成 az network public-ip create --resource-group rg-peering-lab --name Hub-RouteServer-PIP --sku Standard # Azure Route Serverを作成 az network routeserver create --resource-group rg-peering-lab --name Hub-RouteServer --hosted-subnet $(az network vnet subnet show --resource-group rg-peering-lab --vnet-name Hub-VNet --name RouteServerSubnet --query id -o tsv) --public-ip-address Hub-RouteServer-PIP # ブランチ間通信を有効化（NVA経由のトランジットに必要） az network routeserver update --resource-group rg-peering-lab --name Hub-RouteServer --allow-b2b-traffic true
トラブルシュート・よくあるエラー対処
「PeeringStateがInitiatedのまま変わらない」
逆方向のピアリングが設定されていません。両方のVNetから `az network vnet peering list` を実行して、双方向とも `Connected` になっているか確認してください。一方が `Initiated` の場合、未設定のピアリングを作成すると自動的に `Connected` になります。# Hub側とSpoke1側の両方を確認 az network vnet peering list --resource-group rg-peering-lab --vnet-name Hub-VNet --query "[].{Name:name,State:peeringState}" --output table az network vnet peering list --resource-group rg-peering-lab --vnet-name Spoke1-VNet --query "[].{Name:name,State:peeringState}" --output table
「Use Remote GatewaysでエラーになりRemoteGateways設定できない」
`--set useRemoteGateways=true` 実行時に `VirtualNetworkGateway ... is not provisioned` のようなエラーが出る場合は、ハブVNetのVPN Gatewayのデプロイがまだ完了していません。VPN Gatewayのデプロイには20分以上かかるため、以下でプロビジョニング状態を確認してから再試行してください。az network vnet-gateway show --resource-group rg-peering-lab --name Hub-VPN-GW --query "provisioningState" --output tsv # 出力例（環境により異なります） # Succeeded
「アドレス空間が重複していてピアリングできない」
VNet PeeringはCIDRの重複を許可しません。たとえば2つのVNetがどちらも `10.0.0.0/16` を使っている場合、ピアリング作成は失敗します。既存のVNetのアドレス空間を変更する場合は `az network vnet update` で対応できますが、変更前にサブネットとVMのIPが競合しないことを確認してください。「ピアリングはConnectedなのに通信できない」
NSG（ネットワークセキュリティグループ）がブロックしているケースが多いです。サブネット・NIC両方のインバウンドルールを確認してください。Azure PortalのNetwork Watcher「IP フロー確認」機能を使うと、特定の通信がNSGで許可されているかをすぐに調べられます。本記事のまとめ
Azure VNet Peeringの設定と、オンプレミス統合時の注意点を以下にまとめます。| やりたいこと | 設定・コマンド |
|---|---|
| VNet同士を接続する | az network vnet peering create（双方向2回必須） |
| ピアリング状態を確認する | az network vnet peering list --output table |
| スポークからオンプレへ通信する | az network vnet peering update --set allowGatewayTransit=true（Hub） |
| スポーク側でリモートGWを使う | az network vnet peering update --set useRemoteGateways=true（Spoke） |
| スポーク間トランジットを実現する | Azure Route Server＋NVA（BGP）、またはSpoke間を直接ピアリング |
AzureのVNetアーキテクチャをLinuxサーバー管理と合わせて体系的に習得したい方は、Azureエンジニア育成コースでLinuxとクラウドの両面からスキルを身につけてみてください。
＞＞ Azureエンジニア育成コースの詳細を見る
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
- 次のページへ：awsとazureの違いはサブネット設計にあり｜azure NAT構成で検証
- 前のページへ：Azure Network Outageを想定したVNet障害設計と復旧手順｜az cliで冗長化を実装する
- この記事の属するカテゴリ：Azureへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます