Azure VPN Gatewayを理解するための前提
VPN GatewayはVNet内の専用GatewaySubnetへ配置され、Azure側public IPをendpointとして暗号化trafficを処理する。GatewaySubnetへ通常workloadを配置しない。 productionの複雑なS2S/BGP/active-active用途ではroute-based gatewayを基準にする。Basic SKUは機能制約が大きく、本番の標準選択肢として扱わない。
S2S connectionを複数持つ場合、それぞれが独立した専用gateway帯域を持つわけではなく、gateway SKUのaggregate capacityを共有する。 BGPを使う場合はAzure/on-prem双方のadvertised/learned routesを確認し、単にtunnel Connectedだけでrouting成立と判定しない。
active-activeでは2つのgateway instanceそれぞれへpublic IPを持たせ、on-prem側から両instanceへtunnelを確立できる設計にする。 2026-09-11時点ではNon-AZ VpnGw1-5のretirement/migration期限が目前であり、旧SKUのまま新規設計を固定しない。
Control plane と data plane
Provider / responsibility boundary
VPN Gateway resource、GatewaySubnet、public IP、connection、Local Network Gateway、BGP設定を管理する。
IPsec packetが通るunderlay。Azure VPN GatewayがSucceededでも、途中のNAT・firewall・ISP品質は別failure domain。
VPN deviceのIKE/IPsec proposal、route/BGP、NAT、policy、HA状態を管理する。Azure側だけではremote peerの実転送を証明できない。
仕組み
Gateway type VPNとVPN type(route-based/policy-based)は別概念。BGP、active-active、複数tunnel、custom IPsec/IKEなど高度な構成はroute-basedを前提に設計する。
GatewaySubnetのaddress sizeは将来のSKU変更・coexistence・機能追加を見越して余裕を持たせる。gateway VM自体を直接管理する設計ではない。
Local Network Gatewayはon-prem VPN deviceのpublic IP/FQDNとon-prem address prefixes/BGP peer情報をAzureへ表現するresourceであり、実機そのものではない。
S2S、P2S、VNet-to-VNet、ExpressRoute coexistenceは同じgateway周辺のroutingとcapacityへ影響するため、接続種別ごとに「独立した箱」と考えない。
overlapping address spaceが避けられないS2SではVPN Gateway NATが選択肢になるが、BGP併用時はroute translationまで含めて設計する。
Packet / route path
同一prefix/flowを広告元からdestinationまで追い、connection state・BGP table・effective route・実packetを混同しません。
- Azure workloadがon-prem prefix宛のpacketを生成し、NIC/subnetのeffective routeがVirtualNetworkGateway next hopを選ぶ。
- VPN Gatewayが対象connectionとrouteを選択し、IPsec SAが成立していればpacketを暗号化する。
- 暗号化packetはAzure public IPからInternet/provider経路を通りon-prem VPN deviceへ到達する。
- on-prem deviceが復号し、内部route/firewall policyに従ってdestinationへ転送する。
- replyはon-prem側のreturn routeが同じVPN pathを選び、Azure VPN Gatewayで復号された後VNet内へ転送される。
- 障害時はGateway state → Connection state → IKE/IPsec → BGP/route → effective route → NSG/NVA → applicationの順でlayerを分離する。
BGP / route state の読み方
| 観測点 | 何を確認するか |
|---|---|
| Tunnel state | Connected/DisconnectedはIPsec connectionの状態。Connectedはprefixが正しく選択されることやapplication成功を保証しない。 |
| BGP state | peer state、RoutesReceived、learned routes、advertised routesを組み合わせる。Establishedでも必要prefixが0件ならroute policyを疑う。 |
| VNet route | workload NICのeffective routesでVirtualNetworkGateway next hopと期待prefixを確認する。よりspecificなUDR/BGP/system routeが選ばれる場合がある。 |
| Return path | on-prem router/FWでAzure prefixへのreturn routeを確認する。stateful deviceがある場合は非対称returnでdropされないことを確認する。 |
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| SKU | 新規/移行はAZ対応VpnGw SKUを基準にし、必要throughput・S2S/P2S scale・BGP/feature requirementでtierを決める。 | 旧Non-AZ SKUはretirement対象で、単純な「今動く」だけではlifecycle要件を満たさない。 |
| HA | 重要系はactive-activeとon-prem側の冗長tunnel/BGPを検討する。 | Azure gatewayだけ冗長でもremote deviceやISPがsingle pointならend-to-end HAにならない。 |
| Routing | 静的prefixの羅列より、変更頻度と規模が大きい環境ではBGPを優先する。 | route advertisement/withdrawalを自動化できるが、prefix leak/overlapを防ぐpolicyが必要。 |
| Coexistence | ExpressRoute + VPNを併用する場合、平常時/障害時のpreferred pathを明文化する。 | 複数pathがあるとavailabilityは上がる一方、意図しないasymmetryやdefault routeの影響が増える。 |
確認手順
Azure Portal / provider / edge
- Virtual network gateway → Overview / ConfigurationでSKU、VPN type、active-active、BGP、public IP、GatewaySubnetを確認する。
- Connectionsで各S2S/VNet connectionのStatus、Ingress/Egress、peer endpoint、shared key/certificate方式を確認する。
- Monitoring → BGP peersでpeer state、learned routes、advertised routesを確認し、必要ならCSVで全routeを取得する。
- Network Watcher / effective routes、NSG、Azure Monitor metrics/logsを接続状態とは別の証拠として保存する。
Verification discipline
- subscription / resource group / resource ID / region / connection名を固定し、同名resourceの取り違えを防ぐ。
- control-planeのProvisioningStateだけで完了判定せず、peer/session/route/metricと実packetの結果を別々に保存する。
- advertised route・learned route・effective routeを混同しない。各段階で「誰が誰へ何を広告し、最終的にどのFIBへ入ったか」を確認する。
- 変更前後で同一source/destination/protocolを再試験し、既存sessionの継続を新規flowの成功と誤認しない。
az network vnet-gateway show -g <rg> -n <gateway> -o jsonc
az network vpn-connection list -g <rg> -o table
az network vnet-gateway list-bgp-peer-status -g <rg> -n <gateway> -o table
az network vnet-gateway list-learned-routes -g <rg> -n <gateway> -o tableGet-AzVirtualNetworkGateway -ResourceGroupName <rg> -Name <gateway>
Get-AzVirtualNetworkGatewayConnection -ResourceGroupName <rg>
Get-AzVirtualNetworkGatewayBgpPeerStatus -ResourceGroupName <rg> -VirtualNetworkGatewayName <gateway>
Get-AzVirtualNetworkGatewayLearnedRoute -ResourceGroupName <rg> -VirtualNetworkGatewayName <gateway>障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| GatewayはSucceeded、connectionはDisconnected | remote public IP、IKE proposal、authentication、Internet path | connection diagnostic logs、remote VPN log、public endpoint reachability | Azure resource再作成より先にIKE/IPsec negotiationのどこで止まるか特定する |
| Tunnel Connectedだが通信不可 | route未学習/誤広告、UDR、NSG/NVA、on-prem return route | learned/advertised/effective routeとpacket capture/flow log | 同一5-tupleのforward/return pathを両側で追う |
| 片系だけ流れる | active-activeの片tunnel/BGP session不成立、on-prem ECMP/policy差 | instance別public IP、peer state、route count | 両instanceへ同一prefixとpolicyが存在するか比較する |
| 移行/resize後に性能や接続が不安定 | SKU capacity、GatewaySubnet、旧Non-AZ依存、remote reconnect | SKU/generation、metric、connection count、Microsoft migration state | lifecycle移行と性能問題を分け、必要なら段階的にtier/HAを見直す |
変更時の確認と rollback
- 変更前にgateway JSON、public IP、GatewaySubnet、connection一覧、BGP peer/learned/advertised routesを保存する。
- connection policy変更は片connectionずつ行い、remote側のproposal/route policyと同期させる。
- rollback後はcontrol-plane stateだけでなく新規flow、BGP route count、双方向application testを再実行する。
- gateway削除・再作成はpublic IPやdowntimeへ影響し得るため、通常rollbackとして安易に選ばない。
What changed recently
Non-AZ VpnGw1-5は2025-11-01以降新規作成不可で、2026年9月までが移行期間です。Microsoftはavailability-zone対応SKUへのmanual upgradeを推奨しているため、2026-09-30のretirement horizonまでにSKU、GatewaySubnet、public IP、HA、接続再確立を含めて移行状態を確認します。