Hybrid Connectivity参照資料確認: 2026-09-11

VNet-to-VNet VPN

VPN Gateway同士でVNet間をIPsec接続するVNet-to-VNetを、peeringとの差、active-active、BGP、route propagation、検証から整理する。

Scope: Microsoft Learn / Azure Architecture Centerの一次資料を2026-09-11時点で確認し、旧来の短い記事を公開運用向けdeep diveへ更新。SKU、region、limits、Preview statusは変わるため、実装直前にOfficial sourcesを再確認してください。

VNet-to-VNet VPNを理解するための前提

VNet-to-VNetは各VNetのVPN GatewayをIPsec/IKEで接続し、Azure backbone上でも暗号化tunnelを提供する。 VNet peeringよりgateway resource/cost/throughput/crypto overheadがあるため、暗号化要件等で選ぶ。

route-based VPN Gatewayを使用し、cross-subscriptionではportal以外の手段が必要な場合がある。 active-active構成ではgateway instance/public IPごとのtunnel設計とpeer capabilityを確認する。

BGPを使う場合はstatic prefixとdynamic route advertisement/ASNを明確にする。 VNet-to-VNet connectionはforward/reverse connection objectとshared key/BGP statusを確認する。

通信や判断の流れを追う
On-premisesVPN / ProviderGateway / HubVNetWorkload

Control plane と data plane

Control planeVirtual Network Gateway、connection、local/remote gateway relation、BGP settingsがcontrol plane。
Data planepacketはsource VNet route→VPN Gateway→IPsec tunnel→remote gateway→destination VNet routeの順でdata planeを通る。

仕組みと設計上の意味

peeringとVPNを同じprefix間に重ねるとroute preference/意図が不明瞭になるため、migration時はeffective routeを確認する。

GatewaySubnetへNSG/UDRを安易に適用しない。service requirementsを優先する。

BGP session establishedでも必要prefixがlearned/advertisedされているかを別確認する。

active-activeでは片tunnel failure drillでremaining pathのthroughput/route convergenceを測る。

Packet / decision path

source→destinationを1本のflowとして固定し、名前解決・routing・security・NAT/service processing・return pathを必要な範囲で順に確認する。

  1. 両VNet address overlapがないことを確認。
  2. gateway SKU/active-active/BGPを確認。
  3. connection status/shared keyを確認。
  4. learned/advertised/effective routesを確認。
  5. 片系停止/再接続を含むruntime testを実施。

設計判断

判断点推奨理由
Peering vs VPN暗号化/gateway要件がある時VPN通常のAzure VNet接続はpeeringが簡素
BGPprefix変動/scaleで利用static route管理を削減
HAactive-active + AZ SKUを検討gateway/tunnel failure耐性
MonitoringTunnel/BGP logs + metricscontrol/data plane両方を観測

確認手順

Azure Portal

  • Virtual network gateway → ConnectionsでConnected statusを確認。
  • BGP peers/learned routesを確認。
  • Network Watcher/VMからremote private IPへtest。

Evidence contract

Identitysubscription / resource group / resource ID / regionを固定。
Before / After同じsource・destination・protocol・portで比較。
Effective state設定値だけでなくeffective route/security/health/logを取得。
Runtimecontrol-plane Succeededとapplication successを分けて判定。
Azure CLI — read-only first
az network vpn-connection show -g <rg> -n <connection> -o jsonc
az network vnet-gateway show -g <rg> -n <gateway> -o jsonc
az network vnet-gateway list-learned-routes -g <rg> -n <gateway> -o table
PowerShell — read-only first
Get-AzVirtualNetworkGateway -ResourceGroupName <rg> -Name <gateway>
Get-AzVirtualNetworkGatewayConnection -ResourceGroupName <rg> -Name <connection>

障害切り分け

症状疑う点証拠次の確認
connection DisconnectedIKE/shared key/gateway issueconnection/tunnel logsIKE/IPsec layer確認
Connectedだが到達不可route/NSG/return pathlearned/effective routeprefix propagation確認
BGP flapASN/timer/firewall/pathRouteDiagnosticLogBGP原因確認
片系停止で断active-active peer不足tunnel stateboth instances/tunnels確認

変更・rollback

  • gateway/connection/BGP configをexport。
  • shared key changeは両端coordinated。
  • route migration時はpeering/VPN path overlapを監視。
  • rollback後にnew IPsec sessionとremote applicationを確認。

Official sources