Azure S2S VPN の構築手順｜疎通確認と NSG による通信制御

はじめに

オンプレミスと Azure を接続する方法として、Azure VPN Gateway を使用したサイト間 VPN（S2S VPN）は代表的な構成です。ただし、Azure Portal でリソースを作成し、トンネルが確立しただけでは、業務通信が届くかどうかは判断できません。経路や NSG（ネットワークセキュリティグループ）の設定によって、トンネルが UP でも通信できない場合があるためです。

本記事では、Azure VPN Gateway による S2S VPN の構築手順と、構築後に確認すべきポイントを解説します。S2S VPN の仕組みや設計判断、障害切り分けと復旧試験は別記事で扱う予定のため、本記事では Azure 側の構築、対向ルーターの設定抜粋、疎通確認、NSG による通信制御に絞ります。

結論として、今回の検証では VPN Gateway（VpnGw1AZ / Active-Standby）とローカル側の仮想ルーターの間で IKEv2 / IPsec のトンネルを確立し、パブリック IP を持たない Azure VM へプライベート IP で SSH 接続できました。一方で、VPN の状態が正常でも、VM へ届く通信は NSG の規則によって別に制御されます。構築後はトンネルの状態だけでなく、実際の通信とセキュリティ規則の両方を確認することをおすすめします。

Azure S2S VPN の検証構成と事前準備

今回の検証では、Azure 側に VNet、VPN Gateway、ローカルネットワークゲートウェイ、VPN 接続、検証 VM、NSG を作成し、ローカル側は VMware Workstation 上の仮想ルーターと Ubuntu VM で拠点ネットワークを再現しました。

以下は、今回実際に接続を確認した検証構成です。ローカル Ubuntu から仮想ルーターを経由して Azure VPN Gateway へ接続し、VNet 内のパブリック IP を持たない VM と通信しています。VPN の終端は Azure VM ではなく VPN Gateway です。

Azure 側の構成

ローカル側の構成

ローカル側は、物理的な拠点ネットワークや実機ルーターを用意せずに S2S VPN を検証するため、VMware Workstation 上に VPN の対向となる仮想ルーター（Cisco CSR1000V）と、通信確認用の Ubuntu VM を構築しました。CSR1000V は IOS XE 03.15.00.S（show running-config では version 15.5 と表示）を使用しています。以下の Cisco 設定はこの検証環境の抜粋であり、現行版や別製品での動作保証を意味しません。

Ubuntu は 2 NIC 構成とし、通常の通信は NAT 側 NIC、Azure VNet 宛ての通信はホストオンリー NIC から仮想ルーターへ送るように経路を分けています。経路の確認結果は、疎通確認のセクションで説明します。

事前に確認すること（アドレス設計と NAT 環境）

Microsoft の S2S VPN チュートリアルでは、オンプレミス側のサブネットが、接続する VNet のサブネットと重複してはならないとされています。また、互換性のある VPN デバイスと、VPN デバイス用の外部向けパブリック IPv4 アドレスを用意することが前提条件として挙げられています。今回は Azure 側を 10.250.0.0/16、ローカル側を 172.29.50.0/24 とし、重複しないアドレスを割り当てました。

今回のローカル側は、VMware の NAT と自宅ルーターを経由する NAT 配下の構成です。IPsec は NAT との組み合わせで問題が起きやすいため、NAT 越えでは IKE のネゴシエーション中に NAT を検出し、ESP を UDP でカプセル化する NAT-T（NAT トラバーサル）が使用されます。VPN Gateway FAQ では、NAT-T をサポートしたうえで、この構成ではオンプレミス側のデバイスから IPsec トンネルを開始するよう求めています。

参考: Microsoft Learn「VPN Gateway に関する FAQ」
“In this configuration, ensure the on-premises device initiates the IPSec tunnel.”
（この構成では、オンプレミスのデバイスが IPsec トンネルを開始するようにしてください。）
https://learn.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-vpn-faq

今回の検証では、対向ルーターで IKE / IPsec が NAT-T（UDP 4500）で確立していることを確認しました。ただし、NAT 配下であれば同じ条件で接続できるとは限りません。NAT 機器やファイアウォールで IKE と NAT-T の通信が許可されているか、Azure から見えるグローバル IP アドレスが固定されているか、Azure 側から対向へ到達できるかといった条件によって、結果は変わります。

なお、NAT-T は IPsec の通信を NAT 越えさせるための仕組みです。VPN 接続の作成画面にある NAT ルールの関連付け（Ingress / Egress）は、VPN Gateway が持つアドレス変換の機能であり、NAT-T とは別のものです。

スクリーンショットやログには、サブスクリプション ID、テナント情報、実際のパブリック IP アドレス、PSK などが含まれる場合があります。記事や社内資料に掲載する前に、必ずマスクしてください。

Azure VPN Gateway とローカルネットワークゲートウェイの構築

Azure 側では、VNet と GatewaySubnet を用意してから VPN Gateway を作成し、続いてオンプレミス側を表すローカルネットワークゲートウェイを作成します。手順は Microsoft の公式チュートリアル（チュートリアル: Azure portal でサイト間 VPN 接続を作成する）に沿い、今回の検証値を当てはめています。

手順

VNet と VM 用サブネットを作成する

Azure Portal で仮想ネットワークを作成し、IPv4 アドレス空間に 10.250.0.0/16、VM 用サブネットに 10.250.1.0/24 を設定しました。オンプレミス側と重複しないアドレス範囲を、事前にネットワーク管理者と調整しておくことが重要です。

手順

GatewaySubnet を作成する

VNet の［サブネット］から、サブネットの目的に［Virtual Network Gateway］を選択して追加します。名前は GatewaySubnet が自動で入力され、今回は 10.250.255.0/27 を割り当てました。VPN Gateway の VM とサービスは、このサブネットにデプロイされます。

参考: Microsoft Learn「チュートリアル: Azure portal でサイト間 VPN 接続を作成する」
“It’s best to specify /27 or larger (/26, /25, etc.) for your gateway subnet.”
（ゲートウェイサブネットには /27 以上（/26、/25 など）を指定することをおすすめします。）
https://learn.microsoft.com/ja-jp/azure/vpn-gateway/tutorial-site-to-site-portal

手順

仮想ネットワークゲートウェイを作成する

［仮想ネットワークゲートウェイ］の作成画面で、ゲートウェイの種類に VPN、SKU に VpnGw1AZ を選択し、対象の VNet を指定しました。アクティブ-アクティブモードは無効（Active-Standby）、BGP も無効です。公式チュートリアルでは、ゲートウェイの作成とデプロイに 45 分以上かかる場合があるとされています。

手順

ローカルネットワークゲートウェイを作成する

［ローカルネットワークゲートウェイ］を作成し、エンドポイントに対向 VPN 機器の IP アドレス、アドレス空間にローカル側ネットワークの 172.29.50.0/24 を指定しました。Azure は、ここで指定したアドレス範囲宛ての通信を VPN 機器へルーティングします。

各リソースの役割と設定時の注意点

Azure の S2S VPN は複数のリソースで構成されます。設定値を入力するだけでなく、それぞれが何を表すかを押さえておくと、構築後の確認や設定変更で迷いにくくなります。

GatewaySubnet

VPN Gateway の VM とサービスが使用する専用サブネットです。公式チュートリアルでは、GatewaySubnet への NSG の関連付けはサポートされず、関連付けるとゲートウェイが想定どおり動作しなくなる可能性があると明記されています。NSG は VM 側のサブネットまたは NIC に適用します。

仮想ネットワークゲートウェイ（VPN Gateway）

Azure 側の VPN 終端です。公式チュートリアルでは、可能な場合は可用性ゾーンをサポートする AZ 付きの SKU を選択するよう推奨しています。また、VPN Gateway SKU の統合と移行によると、2025 年 11 月 1 日以降は可用性ゾーンに対応しない VpnGw1〜5 で新しいゲートウェイを作成できません。

アクティブ-アクティブモード

公式チュートリアルは高可用性のためにアクティブ-アクティブを推奨しており、その場合は 2 つのゲートウェイインスタンスそれぞれへトンネルを張る必要があります。対向機器が対応していない場合は無効にするよう案内されています。今回は Active-Standby で構成したため、ゲートウェイのパブリック IP は 1 つです。

ローカルネットワークゲートウェイ

オンプレミス拠点を Azure 上で表すオブジェクトです。公式チュートリアルでは、エンドポイントの IP アドレスを Azure VPN Gateway が接続する VPN デバイスのパブリック IP アドレスと説明しています。NAT 配下の環境では、Azure から見える NAT 後のグローバルアドレスを指定することになります（編集上の整理です）。アドレス空間はオンプレミス側のプレフィックスで、VNet と重複させないようにします。

S2S VPN 接続設定とトンネル確立の確認

VPN Gateway とローカルネットワークゲートウェイを作成したら、両者を関連付ける接続を作成します。今回は既定のポリシーではなく、カスタム IPsec / IKE ポリシーを指定しました。

S2S VPN 接続を作成する

カスタム IPsec / IKE ポリシーの注意点

上の表は今回の検証時の設定値であり、すべての環境で推奨される唯一の組み合わせではありません。カスタムポリシーを指定すると、Azure VPN Gateway はその接続で指定したアルゴリズムと鍵強度の提案だけを送受信します。対向 VPN 機器が同じ組み合わせを使用または受け入れない場合、トンネルは確立しません。

参考: Microsoft Learn「S2S VPN と VNet 間のカスタム IPsec / IKE 接続ポリシーを構成する」
“…uses or accepts the exact policy combination…”
（オンプレミス VPN デバイスが、ポリシーとまったく同じ組み合わせを使用または受け入れるようにしてください。そうでない場合、S2S VPN トンネルは確立しません。）
https://learn.microsoft.com/ja-jp/azure/vpn-gateway/ipsec-ike-policy-howto

同じ資料では、次の点も説明されています。対向機器の設定と照合する際に確認しておくと、パラメーターの不一致を防ぐことにつながります。

• DHGroup14 と PFS2048 は、いずれも DH グループ 14（2048 ビット MODP）に対応します。
• IKE メインモード SA の有効期間は、Azure VPN Gateway 側で 28,800 秒に固定されています。
• IPsec（クイックモード）SA の有効期間の既定値は 27,000 秒で、今回の設定値は既定値と同じです。
• DPD タイムアウトの既定値は 45 秒で、短くすると IKE の再キー処理が頻繁になり、接続が切断されたように見える場合があります。
• ポリシーは接続単位で 1 つだけ指定でき、追加や変更時には数秒程度の切断が発生する可能性があります。

接続モード ResponderOnly を選んだ理由

接続モードは、どちらのゲートウェイが接続を開始できるかを指定する設定です。VPN Gateway の構成設定に関する資料では、IKEv2 を使用するルートベースの VPN Gateway のみが対象で、最初の IKE 接続の確立方向だけに適用されると説明されています。再キーなどは、どちらからでも開始できます。

参考: Microsoft Learn「VPN Gateway の構成設定について」
“ResponderOnly means the connection needs to be initiated by the on-premises device.”
（ResponderOnly は、オンプレミスのデバイスが接続を開始する必要があることを意味します。）
https://learn.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-about-vpn-gateway-settings

既定値の Default は、先に接続した側を受け入れ、Azure 側からも接続を開始します。今回は対向機器が NAT 配下にあり、FAQ でオンプレミス側からの開始が求められているため、ResponderOnly としました。

対向ルーター（Cisco CSR1000V）の設定抜粋

Azure 側の接続設定に対応する、CSR1000V 側の設定を必要な部分だけ紹介します。今回の検証は IKEv2 とルートベースの IPsec VTI（Tunnel1）を使用しています。Azure の設定画面だけでトンネルが確立するわけではなく、対向側でも暗号化方式、認証、トンネルの接続先、経路を設定する必要があります。

次のコードは実際の show running-config から抜粋したものです。実パブリック IP は説明用の 203.0.113.10 に置き換え、PSK は伏せています。この IP は文書用のサンプルであり、実環境では Azure VPN Gateway のパブリック IP に置き換えてください。<PSKを安全に設定> も実際の鍵ではなく説明用表記です。このまま投入できる完成設定ではありません。

crypto ikev2 proposal AZURE-PROP
 encryption aes-cbc-256
 integrity sha256
 group 14
!
crypto ikev2 policy AZURE-POL
 proposal AZURE-PROP
!
crypto ikev2 keyring AZURE-KR
 peer AZURE-GW
  address 203.0.113.10
  pre-shared-key <PSKを安全に設定>
!
crypto ikev2 profile AZURE-IKEV2
 match fvrf any
 match address local interface GigabitEthernet1
 match identity remote address 203.0.113.10 255.255.255.255
 authentication remote pre-share
 authentication local pre-share
 keyring local AZURE-KR
 dpd 10 2 on-demand
 nat keepalive 20

crypto ikev2 proposal では、Azure 側の IKE 暗号化 AES256、整合性 SHA256、DHGroup14 に対応する値を指定しています。keyring と profile では、対向先の特定と事前共有キーによる相互認証を構成します。鍵の値は Azure 側と一致させる必要があります。鍵を設定した実機のコンフィグを公開する際は、平文の PSK を必ず削除してください。

crypto ipsec transform-set AZURE-TS esp-aes 256 esp-sha256-hmac
 mode tunnel
!
crypto ipsec profile AZURE-IPSEC
 set transform-set AZURE-TS
 set pfs group14
 set ikev2-profile AZURE-IKEV2
!
interface GigabitEthernet1
 ip address 192.168.46.254 255.255.255.0
!
interface GigabitEthernet2
 ip address 172.29.50.1 255.255.255.0
!
interface Tunnel1
 description S2S_VPN_TO_AZURE
 ip unnumbered GigabitEthernet2
 ip tcp adjust-mss 1350
 tunnel source GigabitEthernet1
 tunnel mode ipsec ipv4
 tunnel destination 203.0.113.10
 tunnel protection ipsec profile AZURE-IPSEC
!
ip route 0.0.0.0 0.0.0.0 192.168.46.2
ip route 10.250.0.0 255.255.0.0 Tunnel1

GigabitEthernet1 は VMware NAT 側、GigabitEthernet2 は検証用 Ubuntu と接続するホストオンリー側です。Tunnel1 は GigabitEthernet2 の IP アドレスを ip unnumbered で利用し、IPsec プロファイルを適用しています。Azure VNet（10.250.0.0/16）宛ては Tunnel1 へ、通常のインターネット宛ては VMware NAT のゲートウェイへ送ります。実運用では接続先機器とネットワーク設計に応じて変更してください。

なお、上記の dpd 10 2 on-demand は CSR1000V 側の設定値であり、Azure 側で指定した「DPD タイムアウト 45 秒」と同じ設定項目ではありません。設定値の数値だけを見て不一致と判断しないでください。また、実際に構成した set pfs group14 と、再鍵交換後に PFS が使用されたかどうかの実測は区別します。

設定の構成要素と VTI については Cisco の IPsec VTI の構成例 も参照してください。ただし、資料の掲載バージョンと今回の旧 IOS XE は同一とは限りません。本節は実機で取得した設定を優先して記載しています。

トンネル確立の確認結果

公式チュートリアルでは、Azure Portal で VPN Gateway の［接続］を開き、接続の状態が Succeeded および Connected になっていることを確認する手順が示されています。今回、接続リソースの画面では「接続済み」を確認できました。また、対向ルーター側でも IKEv2 SA が READY、IPsec SA が ACTIVE、VPN セッションが UP-ACTIVE となりました。

対向ルーターでは、次のコマンドで接続状態と暗号化・復号カウンターを確認します。

show crypto ikev2 sa
show crypto ipsec sa
show crypto session detail

以下は検証時の表示から、公開 IP を伏せ、判定に必要な行だけを抜粋した結果です。[IP非公開] はマスク表記です。数値はこの確認時点のもので、接続のたびに変わります。

Tunnel-id Local Remote fvrf/ivrf Status
1 [IP非公開] [IP非公開] none/none READY
Encr: AES-CBC, keysize: 256, PRF: SHA256, Hash: SHA256, DH Grp:14

#pkts encaps: 20, #pkts encrypt: 20
#pkts decaps: 21, #pkts decrypt: 21
in use settings ={Tunnel UDP-Encaps, }
Status: ACTIVE(ACTIVE)

Session status: UP-ACTIVE
Active SAs: 2

Tunnel UDP-Encaps は、この SA で UDP カプセル化による NAT-T が使われていることを示しています。encaps と decaps は暗号化トンネルを通過したパケットの確認に利用できます。Cisco の IKEv2 接続確認資料では show crypto ikev2 sa と show crypto ipsec sa による確認方法が示されています。

なお、対向ルーターの IPsec SA の表示では、PFS が N、DH group が none となっていました。Cisco の資料（ASA とルーター間の IKEv2 の構成例）では、IKEv2 の最初の Child SA ではこの表示になり、再鍵交換後に PFS の DH グループが表示されると説明されています。この表示だけで、PFS の設定ミスと判断する必要はありません。ただし、今回の検証では再鍵交換後の SA 表示を取得していないため、PFS が適用されたことまでは確認していません。

Azure VM を使用した双方向の疎通確認

トンネルが確立しても、利用者の通信が届くとは限りません。今回はパブリック IP を持たない検証 VM を作成し、確認の対象を段階ごとに分けて、それぞれ別の方法で確認しました。

パブリック IP なしの検証 VM を作成する

検証 VM は、Azure Portal の［仮想マシン］の作成画面で作成しました。操作の流れは Microsoft の Linux VM のクイックスタート（Azure portal で Linux 仮想マシンを作成する）と同じで、今回の検証値は次のとおりです。

ローカル側の経路を確認する

疎通確認の前に、検証用 Ubuntu から Azure 宛ての通信が仮想ルーターへ向かうことを確認しました。Ubuntu には Azure VNet 全体（10.250.0.0/16）宛ての経路として、10.250.0.0/16 via 172.29.50.1 を設定しています。実際に使用される経路は、次のコマンドで確認できます。

ip route get 10.250.1.4

結果は、ネクストホップが 172.29.50.1、送信インターフェースがホストオンリー NIC、送信元 IP が 172.29.50.20 となり、NAT 側 NIC ではなく仮想ルーター経由で送信されることを確認できました。

この送信元 172.29.50.20 は、Azure 側のローカルネットワークゲートウェイに登録したアドレス空間 172.29.50.0/24 に含まれます。Azure は、このアドレス空間宛ての応答を VPN 経由でローカル側へ返します。送信元がローカルネットワークゲートウェイのアドレス空間に含まれない場合、Azure VM からの応答は VPN へ戻らないため、ローカル側の経路と Azure 側の登録内容は対で確認することをおすすめします。

ローカル Ubuntu から Azure VM への ping

ローカル側の検証用 Ubuntu から、Azure VM のプライベート IP へ ICMP を送信しました。

ping -c 5 10.250.1.4

5 回送信して 5 回受信し、パケット損失率は 0%、平均 RTT は約 15.7 ms でした。

パブリック IP がない Azure VM へ VPN 経由で SSH 接続

続いて、同じ Ubuntu から Azure VM のプライベート IP へ SSH 接続しました。認証は SSH 公開鍵認証です。

ssh -i ~/.ssh/azure_s2s_lab azureuser@10.250.1.4

Azure VM へのログインに成功しました。通信は、Ubuntu のホストオンリー NIC から仮想ルーター（172.29.50.1）、IPsec トンネル、VPN Gateway を経由して VNet 内の VM に届いています。Azure VM にはパブリック IP を割り当てておらず、インターネットへ SSH を公開せずに、拠点側からプライベート IP で管理接続できることが S2S VPN の利用価値の 1 つです。

Azure VM からローカル Ubuntu への ping

逆方向として、Azure VM からローカル側の Ubuntu へ ICMP を送信しました。

ping -c 5 172.29.50.20

5 回送信して 5 回受信し、パケット損失率は 0%、平均 RTT は約 330.6 ms でした。往復遅延にはばらつきがあり、これは今回の単発の測定結果です。Azure VPN Gateway の標準的な性能や平均レイテンシを示す値ではありません。

暗号化カウンターで実通信のトンネル通過を確認

対向ルーターでは、SA やセッションの状態に加えて、show crypto ipsec sa で IPsec の暗号化・復号カウンターが疎通確認の通信に応じて増加していることを確認しました。SA の状態は「トンネルを使用できる状態か」を示し、カウンターの増加は「実際の通信がそのトンネルで暗号化・復号されたか」を示します。両者を分けて確認することで、ping の応答が VPN 以外の経路から返っていないことの裏付けにもなります。

NSG による SSH / ICMP の通信制御と検証結果

S2S VPN で拠点と VNet をつないだ後、拠点側から VM へ届く通信は NSG で制御できます。今回は独立した NSG を作成して Azure VM の NIC に関連付け、SSH を許可したまま ICMP だけを拒否できるかを確認しました。

明示的な規則を追加した理由（既定規則と VirtualNetwork タグ）

NSG には、優先度 65000 の既定規則 AllowVNetInBound があり、送信元・宛先とも VirtualNetwork サービスタグの通信を許可します。サービスタグの資料によると、VirtualNetwork タグには VNet のアドレス空間だけでなく、接続されたオンプレミスのアドレス空間も含まれます。

参考: Microsoft Learn「Azure サービスタグの概要」
“all connected on-premises address spaces”
（VirtualNetwork タグには、接続されているすべてのオンプレミスのアドレス空間が含まれます。）
https://learn.microsoft.com/ja-jp/azure/virtual-network/service-tags-overview

今回の検証構成では、ローカル側ネットワーク 172.29.50.0/24 からの通信が、VirtualNetwork サービスタグを用いた既定の許可規則の対象になります。そこで、拠点側からの通信を必要なプロトコルに限定する目的で、既定規則より優先度の高い許可規則と、明示的な拒否規則を追加しました。なお、実際に通信できるかどうかは、NSG のほかの規則、ルーティング、ゲスト OS のファイアウォールなどにも左右されます。

NSG を作成して NIC に関連付ける

操作は Microsoft の資料（ネットワークセキュリティグループの作成、変更、削除、ネットワークインターフェイスの作成、変更、削除）に沿って行いました。

ネットワークセキュリティグループの概要によると、優先度は 100〜4096 の数値で、小さい番号から順に処理され、通信が規則に一致した時点で処理が停止します。今回の規則では、検証用 Ubuntu からの SSH と ICMP を個別に判定し、それ以外のローカル側ネットワークからの通信を優先度 400 で拒否しています。いずれも既定規則（65000 以降）より先に評価されます。

受信通信では、サブネットに関連付けた NSG、NIC に関連付けた NSG の順に評価されます（ネットワークセキュリティグループによるネットワークトラフィックのフィルター処理のしくみ）。同じ資料では、規則の競合を避けるため、NSG はサブネットか NIC のどちらか一方に関連付けることを推奨しています。今回は VM 用サブネットに NSG を関連付けず、NIC のみに適用しました。

ICMP を拒否したときの検証結果

優先度 310 の規則を Allow と Deny で切り替え、ローカル Ubuntu から Azure VM への通信を確認しました。

• ICMP を許可した状態では、ping が成功しました。
• ICMP を拒否した状態では、ping 5 回がすべて失敗しました。
• ICMP を拒否した状態でも、新規の SSH 接続は成功しました。

この結果から、VPN トンネルを維持したまま、NSG によってプロトコル単位で通信を許可・拒否できることを確認できました。SSH が成功していることから、ping の失敗はトンネルの切断ではなく、NSG の規則によるものと判断できます。

VM 側で ICMP を拒否している環境では、ping の失敗だけで VPN の障害と判断できません。疎通確認の手順書には、ping に加えて業務で使用するポートへの接続確認や、VPN 機器の SA 状態の確認を含めておくことをおすすめします。

NSG はステートフルで、規則の変更は新規接続に適用される

NSG はフローレコードによる接続状態をもとに許可・拒否を判断するステートフルなフィルターです。受信を許可した通信の応答には、送信規則を別途作成する必要がありません。Azure VM からローカル側への ping では、送信方向が既定規則 AllowVnetOutBound で許可され、応答もこの接続状態に基づいて許可されます。

参考: Microsoft Learn「ネットワークセキュリティグループの概要」
“Network security group rules only affect new connections.”
（ネットワークセキュリティグループの規則は、新しい接続にのみ影響します。）
https://learn.microsoft.com/ja-jp/azure/virtual-network/network-security-groups-overview

同じ資料では、SSH を許可する規則を削除しても、確立済みの SSH セッションは維持され、新しい接続だけがブロックされる例が示されています。今回 ICMP 拒否後の確認を「新規の SSH 接続」で行ったのは、既存セッションの影響を受けずに、変更後の規則で判定された結果を確認するためです。規則を絞り込んだ後の確認も、新しい接続で行うことをおすすめします。

構築時に発生した問題と注意点

構築中には、VM の作成とトンネルの初期接続で次の事象が発生しました。VM サイズに関する 2 件は今回の検証環境の設定に起因するもので、すべての Azure サブスクリプションで発生する問題ではありません。

Azure Policy による VM サイズの拒否（環境固有）

当初選択した Standard_B2als_v2 は、検証に使用したサブスクリプションに設定されている Azure Policy によってデプロイが拒否されました。ポリシーで許可されている Standard_B1ms を選択して対応しました。組織のサブスクリプションで構築する場合は、許可されている VM サイズなどのポリシーを事前に確認しておくと、手戻りの防止につながります。

高速ネットワークと VM サイズの選択（環境固有）

VM サイズの選択時、高速ネットワークとの互換性によって対象サイズを選択できない状態がありました。高速ネットワークを無効にしたことで、対象サイズを選択できました。今回の検証の範囲での対処です。

VPN トンネルの初期接続

初期段階では対向ルーターに IKEv2 SA が表示されず、トンネルが確立しませんでした。対向ルーターの IKEv2 プロファイルや PSK などの設定を Azure 側の接続設定と整合させ、トンネルインターフェースを再初期化した後、IKEv2 / IPsec の確立を確認しました。根本原因の詳細な解析は行っていません。

VM からインターネットへの送信

今回の検証 VM はパブリック IP を持たず、プライベートサブネットに配置しています。SSH ログイン時には、Ubuntu の更新情報の取得に失敗したことを示すメッセージが表示されました。VPN 経由でプライベート通信ができることと、Azure VM からインターネットへ送信できることは別の話です。Microsoft の資料（Azure の既定の送信アクセス）では、プライベートサブネットの VM がパブリックエンドポイントへ到達するには、明示的な送信方法が必要とされています。OS の更新などが必要な場合は、送信経路を別途検討してください。

トンネルが確立しない場合は、まず IKE バージョン、PSK、カスタムポリシーの各パラメーター、ローカルネットワークゲートウェイのアドレス空間、接続モードと開始側の設定が両側で一致しているかを確認することをおすすめします。詳しい障害切り分けと復旧試験は、別記事で扱う予定です。

まとめ

Azure S2S VPN は、VNet、GatewaySubnet、VPN Gateway、ローカルネットワークゲートウェイ、接続の各リソースを順に作成することで構築できます。構築後は、トンネルの確立、ローカル側の経路、E2E 疎通、実通信のトンネル通過、NSG による通信制御を分けて確認することで、利用可能かどうかを判断しやすくなります。

• GatewaySubnet には /27 以上のアドレス範囲を割り当てます。
• 新規の VPN Gateway は AZ 付きの SKU から選択します。
• カスタム IPsec / IKE ポリシーは対向機器と同じ組み合わせにそろえます。
• 対向機器が NAT 配下の場合は、オンプレミス側から接続を開始させます。
• 送信元がローカルネットワークゲートウェイのアドレス空間に含まれるか確認します。
• パブリック IP のない VM にも、VPN 経由でプライベート IP から SSH できます。
• NSG の明示的な規則で、VPN を維持したままプロトコル単位の制御が可能です。

以上、最後までお読みいただきありがとうございました。