【正しい順序】

1. ステップ 1: 対象 VNet に GatewaySubnet (/27 推奨) を作成する
2. ステップ 2: Virtual Network Gateway (VpnGw1 等 SKU) をデプロイする (約 30 分かかる)
3. ステップ 3: オンプレ機器の Public IP + アドレス空間を持つ Local Network Gateway を作成する
4. ステップ 4: VNet Gateway と Local Gateway を結ぶ Connection リソース (IPsec/IKE 共有キー) を作成する
5. ステップ 5: Azure 側で Effective Routes を確認し、オンプレ機器側の設定と Public IP 一致を確認する

【各ステップの理由】

ステップ 1 が最初の理由 (GatewaySubnet)

GatewaySubnet は名前が固定 (変更不可) で、Virtual Network Gateway のデプロイに必須のサブネットです。Gateway は通常のサブネットには配置できず、必ず GatewaySubnet という名前のサブネットを必要とします。/27 以上 (16+ アドレス) が推奨されます (将来の Gateway スケールアップ時に余裕を持たせるため)。

ステップ 2 の理由 (Gateway デプロイ = 約 30 分)

Virtual Network Gateway のデプロイには約 30 分かかります。後続作業 (Local Gateway / Connection) はこのデプロイ完了を必要としないため、並行して進めると効率的です (時系列としては手順 2 → 3 → 4 で記述します)。

ステップ 3 の理由 (Local Network Gateway)

Local Network Gateway はオンプレ機器側の Public IP とアドレス空間を Azure に登録するメタデータ リソースです。実際の VPN トンネルではなく「相手側の定義」です。Gateway デプロイ完了を待つ必要はなく、並行作業可能です。

ステップ 4 の理由 (Connection で結ぶ)

Virtual Network Gateway (Azure 側) と Local Network Gateway (オンプレ側の定義) を Connection リソースで結びます。ここで IPsec/IKE 共有キー (PSK) を設定します。PSK はオンプレ機器側と完全に一致させる必要があり、不一致だと SA (Security Association) 確立がフェーズ 1 で失敗します。両 Gateway が存在しないと Connection リソースを作成できません。

ステップ 5 の理由 (検証)

Effective Routes (有効なルート) を確認することで、VPN Gateway 経由でオンプレ アドレス空間へのルートが BGP/Static で広告されているか検証できます。トンネル確立後の動作確認は最後のステップとして必須です。

【誤った順序の問題点】

❌ Virtual Network Gateway → GatewaySubnet の順

Gateway のデプロイには GatewaySubnet という名前のサブネットを必要とします。先にこのサブネットを作成していないと Gateway デプロイがエラーになります。

❌ Connection → Local Network Gateway の順

Connection リソースは「VNet Gateway」と「Local Gateway」を結ぶリソースのため、両者が存在しなければ作成できません。Local Gateway を先に作成する必要があります。

❌ Gateway デプロイ完了を待ってから Local Gateway 作成

順序としては正しいですが、Gateway デプロイは 30 分かかるため、並行作業することで全体時間を短縮できます (Local Gateway は Gateway デプロイ完了を必要としない)。

【VPN Gateway SKU の選び方 (参考)】

【参考】

Site-to-Site VPN 接続を作成する / Virtual Network Gateway の概要 / なぜ GatewaySubnet が必要か