Site-to-Site VPN (S2S)を理解するための前提
S2SはAzure VPN Gatewayとon-premises VPN deviceの間にIPsec/IKE tunnelを作る。Azure側Local Network Gatewayにはremote endpointとreachable prefixes/BGP peerを定義する。 route-based gatewayでは複数connectionやBGPなど拡張的な構成を取りやすく、productionの標準的な選択になる。
active-active Azure VPN Gatewayではon-prem側から両gateway instanceのpublic IPへtunnelを作り、片tunnelだけの構成を「active-active」と誤認しない。 shared key方式ではAzureとremote deviceで同一PSKが必要。custom IPsec/IKE policyを使う場合は両端のproposal整合をchange管理する。
BGPを有効にするとprefix changeをdynamicに交換できるが、BGP EstablishedとIPsec Connectedの両方を別々に確認する。 2026年にはX.509 certificate authenticationがAzure public cloudで提供され、certificateをKey Vaultへ置きUAMIでgatewayから参照する方式を選べる。Basic 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の実転送を証明できない。
仕組み
Local Network Gatewayのaddress prefixesは「on-prem側で到達可能とAzureへ教える範囲」。実際のremote router/FWがそのprefixへ転送できるかは別確認する。
custom IPsec/IKE policyは暗号強度・互換性要件に有効だが、片側変更でnegotiationが失敗しやすい。proposalをticket/CMDBへ明記する。
PSKは運用が単純だがshared secret管理が必要。certificate authenticationではKey Vault、UAMI、certificate chain/expiry/RBACという別の運用surfaceが増える。
overlapをNATで解消する場合、pre-NAT/post-NAT prefixとBGP route translationの有無をdiagramへ明示する。
HAではAzure gateway instance、on-prem VPN device、Internet circuitを別failure domainとして評価し、maintenance時にどのtunnelへ収束するか試験する。
Packet / route path
同一prefix/flowを広告元からdestinationまで追い、connection state・BGP table・effective route・実packetを混同しません。
- source subnetのeffective routeがon-prem prefixをVirtualNetworkGatewayへ向ける。
- Azure VPN Gatewayがconnectionを選び、IKE SA/IPsec SAを使用してpacketを暗号化する。
- public Internet/ISP/NAT装置を経由しremote VPN endpointへ到達する。
- on-prem VPN deviceが復号し、inside routing/firewallでdestinationへ転送する。
- replyがAzure prefixへのrouteを持ち、同一または冗長tunnelの許可されたpathからAzureへ戻る。
- stateful firewallが両端/途中にある場合、ECMPや複数tunnelによるasymmetric flowを許容するかを設計・検証する。
BGP / route state の読み方
| 観測点 | 何を確認するか |
|---|---|
| Azure advertisements | 静的prefixならLocal Network Gateway、BGPならadvertised routesでAzureがremoteへ示すprefixを確認する。 |
| Remote advertisements | BGP利用時はlearned routesにremote prefixが現れ、workload effective routeへ反映されることを確認する。 |
| IPsec selectors | policy/proposal/traffic selector不一致はrouting以前にtunnel negotiationまたは特定prefixだけの通信障害を起こす。 |
| NAT translation | NAT使用時はlearned/advertised prefixがどの表現(pre/post NAT)で見えるかを記録し、ACL/routeを同じ表現で合わせる。 |
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| Authentication | 新規高セキュリティ要件ではPSKとcertificate方式を比較し、certificateならKey Vault/UAMI/RBAC/expiry運用まで設計する。 | 認証方式は単なる接続parameterではなく秘密情報/証明書lifecycleの運用責任を決める。 |
| BGP | prefix数・変更頻度・冗長pathが多い場合はBGPを優先する。 | static prefix更新漏れを減らし、failure時のwithdrawalを利用できる。 |
| Tunnel count | HA構成では全Azure instanceと必要remote device間のtunnel matrixを明文化する。 | 片系未構成でも平常時に気づかず、maintenanceで初めてfailする事故を防ぐ。 |
| Crypto policy | custom policyは必須security baselineがある場合に限定し、両端で一元管理する。 | 不要なcustomizationはinteroperabilityと変更リスクを増やす。 |
確認手順
Azure Portal / provider / edge
- Local network gatewayでremote public IP/FQDN、address space、BGP settingsを確認する。
- Connection resourceでStatus、Connection type、authentication、shared key/certificate、IPsec policy、BGP enabledを確認する。
- VPN Gateway → BGP peersでroute countを確認し、on-prem routerでもreceived/advertised prefixesを採取する。
- Azure Monitor diagnostic logsとremote VPN device logsでIKE phase / SA / rekey / disconnect時刻を相関させる。
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 local-gateway show -g <rg> -n <local-gateway> -o jsonc
az network vpn-connection show -g <rg> -n <connection> -o jsonc
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-AzLocalNetworkGateway -ResourceGroupName <rg> -Name <local-gateway>
Get-AzVirtualNetworkGatewayConnection -ResourceGroupName <rg> -Name <connection>
Get-AzVirtualNetworkGatewayBgpPeerStatus -ResourceGroupName <rg> -VirtualNetworkGatewayName <gateway>障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| IKEが上がらない | endpoint/PSK/certificate/proposal/NAT-T | Azure connection log + remote IKE log | 双方のpeer IP・認証・proposalを同一時刻で比較する |
| tunnelは上がるが特定prefixだけ不可 | selector、Local Network Gateway prefix、BGP filter、NAT mapping | learned/advertised route + remote route/ACL | 問題prefixのpre/post NAT表現を固定して追跡する |
| rekey時に瞬断が増える | device interoperability、SA lifetime、片系HA | disconnect時刻、IKE/IPsec logs、片/両tunnel state | custom policy変更前にvendor interoperabilityと冗長tunnelを確認する |
| Azure片系maintenanceで通信断 | on-premが両active-active endpointへ接続していない | instance別tunnel/BGP status | 未構成peerを追加し実failover testを行う |
変更時の確認と rollback
- 変更前にLocal Network Gateway、Connection、IPsec policy、BGP/NAT、remote device running configを保存する。
- crypto/auth変更は両端でmaintenance windowを合わせ、旧policyへ戻せる状態を保持する。
- certificate方式ではKey Vault version、certificate chain、UAMI/RBACをrollback対象として管理する。
- rollback後はtunnel Connectedだけでなく、両方向prefixと実application flowを確認する。
What changed recently
X.509 certificate authentication for S2Sが2026年のcurrent機能として追加されています。Azure public cloud限定、Basic SKU非対応で、outbound certificateはKey Vaultへ保存しUser-Assigned Managed Identityでgatewayから参照します。