Azure VPN Gateway について

# はじめに
Azure の VPN ゲートウェイ についてまとめました。

:::note info
記事は、以下の構成となっています。
- 前半 = 解説
- 後半 = VPN ゲートウェイ を構成するための構築手順へのリンク
:::

本記事を読む前に、その他の Azure ネットワーク（パブリックインターネット、Microsoft グローバルネットワーク や、仮想ネットワーク などの基本的な通信についてなど）をまとめた記事があります。先に そちらを参照いただき、全体像を掴んでいただくことをおススメします。

https://qiita.com/carol0226/items/c43bcb5def13c7e0ebac

:::note warn
**本記事の記載レベルについて**
本記事の内容の信ぴょう性ですが、公開情報を見て 単に まとめました・・・と言うレベルには留まらず、各機能の コアな部分 については、筆者自身で 動作検証を行って 動きを見て理解した前提となっています。

その知識を元に、再度 公開情報を読み直し、さらに 理解しやすい体系に再構築して記載しています。
★ AZ-700 と AZ-720 の資格も所持しています。

とはいえ、非常に多岐に渡る内容をまとめているため、誤りがあれば ご質問、ご指摘をいただけますと助かります。都度、追加検証などを行い、内容を修正させていただきます。
:::

# Azure VPN Gateway とは？
Azure VPN ゲートウェイは、Azure 仮想ネットワークにデプロイすることができる、VPN ルーター です。

通常は、仮想ネットワーク内のホスト同士でしか通信ができませんが、Azure VPN ゲートウェイ をデプロイすることで、その他の仮想ネットワークや、オンプレミスのネットワークと VPN を介して 相互に通信を行う事が可能になります。

**公開情報**

https://learn.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-about-vpngateways?wt.mc_id=mvp_407731

# VPN Gateway で構成できる接続
VPN ゲートウェイ では、以下の構成を組むことが可能です。
なお、vNET ピアリングは VPN ではありませんが、仮想ネットワーク同士を接続するための類似のサービスのため、比較用に掲載しました。

|名称（略称） ▶<br>▼ できること|vNET 間接続<br>(V2V)|サイト間接続<br>(S2S)|ポイント対サイト接続<br>(P2S)|vNET<br>ピアリング<br>※比較用|
|:-:|:-:|:-:|:-:|:-:|
|仮想<br>ネットワーク<br>同士の接続|〇|〇|✖|〇|
|BGP ありの<br>トランジット<br>ルーティング|〇|〇|〇|✖|
|BGP 無しの<br>トランジット<br>ルーティング|✖|〇|✖|✖|
|ロンゲスト<br>マッチによる<br>優先制御、<br>強制トンネリング|✖|〇|✖|✖|
|オンプレミス<br>ネットワーク<br>との接続|✖|〇|✖|✖|
|PC との直接接続|✖|✖|〇|✖|
|ER 回線の<br>バックアップ|✖|〇|✖|✖|

**公開情報**

https://learn.microsoft.com/ja-jp/azure/vpn-gateway/design?wt.mc_id=mvp_407731

**V2V と vNETピアリング の違いについて**
vNET ピアリングは、VPN ゲートウェイが不要です。（比較のために記載しました）
vNET ピアリング は、トランジットルーティングができません。
そのため、トランジットルーティングが必要となる場合は、V2V が適しています。

:::note info
**トランジットルーティングとは？**
鉄道で目的地に向かう際に、乗り換えをすることを、トランジットと言いますが、それと同じです。
[vNET1] と [vNet2]、 [vNet2] と [vNet3] 同士をそれぞれ接続した場合に、[vNet1] と [vNet3] を通信できるようにする仕組みが トランジットルーティングです。

V2V では vNET2 でトランジットルーティングされて、vNET1 と vNET3 が通信可能です。

しかし、vNET ピアリングでは、トランジットルーティングされないため、vNET1 と vNET3 は通信できません。
:::

**V2V と S2S の違いについて**
V2V の場合は、２つの仮想ネットワークゲートウェイを **接続** という仕組みで繋ぐだけで通信が可能です。

S2S の場合は、さらに ローカルネットワークゲートウェイ を構成する必要があります。１手間必要になりますが、その代わりに、BGP 無しのトランジット通信や、ロンゲストマッチによる優先制御、強制トンネリングなどを行う事が可能になります。

そのため、仮想ネットワーク同士を接続する場合でも、S2S が使われる事があります。
<details><summary>その理由について、詳しくは、"ココ" をクリックしてください</summary>

**① P2S での影響**
以下の公開情報で説明されていますが P2S と トランジットルーティング を組み合わせて利用する場合に、P2S のアドレスプールの範囲を、各 仮想ネットワークに認識させる必要があるので、V2V を使うと P2S のマシンはトランジットルーティングが行われません。このような場合に S2S が出番になります（P2S で、BGP に対応していないプロトコルを使った場合は、V2V では、ルーティング情報が伝播されないことが原因です）

**公開情報：S2S VPN を使用して接続されている複数の VNet**
https://learn.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-about-point-to-site-routing?wt.mc_id=mvp_407731#multis2s

**② S2S での影響**
上記と同様に、オンプレミス拠点 が **BGP を採用していない場合** でも、同様な対処を行う事で、トランジットルーティング が可能になります（つまり、S2S を使って、スタティックルーティング的な対応を行う事が可能です）

**1. 以下の構成の場合、オンプレ拠点は、vNet1～3 と通信できる**
　[vNET3] - (**V2V**) - [vNET2] - (**V2V**) - [vNet1] - (**S2S**) - オンプレ拠点 (BGP 利用可)

**2. 以下の構成の場合、オンプレ拠点は、vNet1 としか通信できない**
　[vNET3] - (**V2V**) - [vNET2] - (**V2V**) - [vNet1] - (**S2S**※) - オンプレ拠点 (**非 BGP**)

**3. 以下の構成の場合、オンプレ拠点は、vNet1～3 と通信できる**
　[vNET3] - (**S2S**※) - [vNET2] - (**S2S**※) - [vNet1] - (**S2S**※) - オンプレ拠点 (**非 BGP**)

※各 ローカルネットワークゲートウェイのアドレス空間の欄に オンプレ拠点のネットワークアドレスを設定する必要あり。
</details>
　<br>

**強制トンネリングについて**
強制トンネリングとは、インターネット向けを含めたすべての通信を、VPN に流す事を言います。強制トンネリングを構成することで、Azure 仮想ネットワーク内の インターネット向けの通信を、オンプレミス拠点の Firewall を経由して 外に出す事が可能です。

https://learn.microsoft.com/ja-jp/azure/vpn-gateway/about-site-to-site-tunneling?wt.mc_id=mvp_407731

（上記の公開情報より抜粋）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/9c8285f5-895e-5d62-8ea4-c6072fa7b0a6.png)

以下の私の記事で、強制トンネリング の構成について 検証した結果を取り上げています。

https://qiita.com/carol0226/private/260734d1eda17413a316

**ゲートウェイ転送について**
一覧表には記載していませんが、ゲートウェイ転送 という仕組みがあります。
まず、VPN ゲートウェイ が構成されている 仮想ネットワーク を ハブ (HUB) と見立てます。
この HUB 仮想ネットワーク に、ピアリングで接続された 仮想ネットワークを スポーク (Spoke) と呼びます。

ゲートウェイ転送を使うと、Spoke 仮想ネットワーク は、HUB に構成された VPN ゲートウェイ を経由して、接続先（V2V , S2S , P2S) と通信をすることが出来るようになります。

https://learn.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-peering-gateway-transit?wt.mc_id=mvp_407731

（上記の公開情報より抜粋）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/e60b0c1b-de74-19a7-eb69-cc3816bbee2c.png)

# VPN Gateway のインスタンスとは？
VPN ゲートウェイ を作成すると、実は「２台の VM」が１組となって展開されています。
そして、各 VM が、VPN ルーターの役割を担うように動作するようになっています。
つまり、最初から 冗長構成が組まれているということです。
この 1 台の VM のことを、**インスタンス** と呼びます。

この インスタンス を、動作モードと、立地的な配置（AZ or 非AZ）などの構成の違いによって、VPN ゲートウェイ としての可用性に違いが生まれます。

|　　　▶動作モード<br>▼AZ 対応か否か？ |アクティブ／スタンバイ<br>※シンプルな構成|アクティブ／アクティブ<br>※複雑な構成|
|:-:|:-:|:-:|
|ゾーン冗長ゲートウェイ<br>(AZ タイプ)<br>コスト高|インスタンス障害時<br>にダウンタイムあり|可用性が最高|
|ゾーンゲートウェイ<br>(non AZ)<br>コスト低|インスタンス障害時<br>にダウンタイムあり、<br>データセンター障害では全滅 |データセンター障害では全滅|

:::note info
動作モードと AZ の有無が ごっちゃになりやすいので、注意しましょう。
:::

## VPN ゲートウェイの 動作モード
２台の インスタンス が動作する組み合わせを示したものが、動作モード です。
動作モードには、以下の２種類があります。

### アクティブ／スタンバイ モード
このモードでは、パブリック IP が１つ用意されています。
パブリック IP は、１台のインスタンスがのみに、割り当てられています。
パブリック IP が割り当てられた方を アクティブ、他方を スタンバイ と呼びます。

アクティブ側 に異常が発生した場合は、パブリック IP の割り当てを スタンバイ側 に切替える事で、ダウンタイムを低減する仕組みです。

**デバイス１台との組み合わせ**
以下の構成は、オンプレミス側で １台の VPN デバイスを手配していますが、Azure の接続先は １つのみです。
一番シンプルな構成でありながら、Azure 側は、冗長構成となっており、ダウンタイムがありますが、インスタンス のダウンに備える事が可能です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/4a8e8238-a408-340e-caf3-3dd67ceba7df.png)

**デバイス２台との組み合わせ**
以下の構成は、オンプレミス側で ２台の VPN デバイスを手配していますが、Azure の接続先は １つのみです。
これは、オンプレミス側のデバイスに障害が発生しても、瞬断レベルで通信が維持され、Azure 側のインスタンス障害では、アクティブなインスタンスに切り替わることで、ダウンタイムが生じますが 通信が自動回復されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/76ffb6f0-2dc8-a634-edae-4ad10865f504.png)
上記の図で、接続の矢印 の色が、黒と青で違っていますが、これは インターネット回線（プロバイダ）を別々のものにすることによって、物理的な回線障害の際でも、可用性を持たせることが可能であることを示しています。

### アクティブ／アクティブ モード
このモードでは、パブリック IP が２つ用意されています。
２つの パブリック IP は、各インスタンスに、割り当てられており、両方がアクティブな状態です。

**デバイス１台との組み合わせ**
以下の構成では、オンプレミス側は １台のデバイスのみですが、２つの VPN が接続されています。
もし、１つのインスタンスに障害が発生しても、BGP によって パケットは 他方の接続が利用されるため、瞬断レベルで通信が継続されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/10632d06-daba-4b21-b012-6acb90313da3.png)

**デバイス２台との組み合わせ**
以下の構成では、オンプレミス側は ２台のデバイスが使用され、それぞれが、２つの VPN が接続されています。
VPN デバイス または インスタンス のいずれか１つの障害が発生しても、瞬断レベルで通信が継続されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/6ccc69d4-0891-d0eb-cf35-55ce3c00c08d.png)
この構成にする事で、物理デバイス・物理回線・プロバイダ・インスタンス のどの箇所に障害が生じても、瞬断レベルで接続を維持できる構成が完成します。さらに、後述する AZ タイプのゲートウェイを採用することで、データセンター障害にも耐えられる構成にすることが出来ます。

:::note alert
**注意**
オンプレミス側からは、１つの VPN 接続しか行わないのに、アクティブ／アクティブ の構成にはしないでください。アクティブ／アクティブ のモードでは、インスタンス障害が発生しても パブリック IP の付け替えが発生しないため、通信断のまま 自動回復とはなりません。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/c106be01-6885-455e-5bf0-7d89b766f026.png)
:::

:::note warn
つまり、アクティブ／アクティブの方が優れている・・・という訳では無く、オンプレミス側の構成に合わせた動作モードを選ぶ必要があるという事になります。
:::

**参考となる 公開情報**

https://learn.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-highlyavailable?wt.mc_id=mvp_407731

https://learn.microsoft.com/ja-jp/azure/vpn-gateway/about-active-active-gateways?wt.mc_id=mvp_407731

:::note info
以下の公開情報の抜粋では、両動作モードに 利用料の差はないことが説明されています。これは スタンバイ のインスタンスも常時稼働しているため、費用が掛かっていることが理由です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/2475701a-2bf7-a0ed-027d-dc0e29074d25.png)

**公開情報：仮想ネットワーク ゲートウェイのコンピューティング コスト**
上記の記述は、この公開情報から抜粋しています。
https://learn.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-about-vpngateways?wt.mc_id=mvp_407731#pricing
:::

**参考**
動作モードは、以下の手順で 後から 変更する事が可能です。

https://learn.microsoft.com/ja-jp/azure/vpn-gateway/gateway-change-active-active?wt.mc_id=mvp_407731

## AZ タイプの VPN ゲートウェイとは？
VPN ゲートウェイ には、ゾーン冗長ゲートウェイ (AZ タイプ）と、ゾーンゲートウェイ（非 AZ タイプ）のものがあります。

:::note info
**おさらい：Azure の 可用性ゾーン**
以下のように、可用性ゾーンをサポートするリージョン（ex：東日本リージョン）と、しないリージョン（ex：西日本リージョン）があります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/c5e5f5eb-7c87-f001-a4df-f7d94a3ee018.png)


**公開情報：可用性ゾーンとは**
上記の図の詳しい説明（上記の図は、このページから抜粋および加筆しています）
https://learn.microsoft.com/ja-jp/azure/reliability/availability-zones-overview?wt.mc_id=mvp_407731

**公開情報：可用性ゾーンをサポートする Azure リージョン**
どのリージョンが、可用性ゾーンに対応しているのか 一覧化されています。
https://learn.microsoft.com/ja-jp/azure/reliability/availability-zones-service-support?wt.mc_id=mvp_407731
:::

ゾーン冗長ゲートウェイ は、可用性ゾーンに跨って ２つのインスタンスを配置する事ができます（下図の紫マル）
ゾーンゲートウェイ は、同一のデータセンター内に ２つのインスタンスが配置されます（下図の桃マル）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/6c37f9a2-e10e-920e-1104-0627454777dc.png)
オンプレミス 1：AZ タイプ に対して アクティブ／アクティブ を構成したイメージです。
オンプレミス 2：非 AZ タイプ に対して、アクティブ／スタンバイ を構成したイメージです。
オンプレミス 3：非 AZ タイプ に対して、２台のデバイスで、アクティブ／アクティブ を構成したイメージです。

**（再掲）**

|　　　▶動作モード<br>▼AZ 対応か否か？ |アクティブ／スタンバイ<br>※シンプルな構成|アクティブ／アクティブ<br>※複雑な構成|
|:-:|:-:|:-:|
|ゾーン冗長ゲートウェイ<br>(AZ タイプ)<br>コスト高|インスタンス障害時<br>にダウンタイムあり|可用性が最高|
|ゾーンゲートウェイ<br>(non AZ)<br>コスト低|インスタンス障害時<br>にダウンタイムあり、<br>データセンター障害では全滅 |データセンター障害では全滅|

上記の表の組み合わせに加えて、オンプレミス側のデバイスを １台にするか、２台にするかで、計 8 パターンの組み合わせが存在する事になります。

上記の図と表を見ても判るように、データセンター全体がダウンする障害が発生しても、ゾーン冗長ゲートウェイ を利用していた場合には、他方のインスタンスが生き残るため、可用性が高い構成です。

なお、西日本リージョンなどの 可用性ゾーンに対応していないリージョンは、ゾーンゲートウェイ しか展開できません。上記の図の「東京２」の桃マルのように あえて ゾーンゲートウェイ をデプロイすることは可能です（AZ タイプはコストが高いので、非 AZ タイプは コストを抑えたい場合の選択肢となります）

**参考となる 公開情報**

https://learn.microsoft.com/ja-jp/azure/vpn-gateway/about-zone-redundant-vnet-gateways?wt.mc_id=mvp_407731

# VPN Gateway のメンテナンス について
VPN ゲートウェイは、VM であり、インスタンスと呼ぶことを冒頭の章で説明しました。
Azure 上の VM は、メンテナンス が行われる運命にあり、これを逃れる事はできません。
VPN ゲートウェイも、VM と同様に、以下の Support Blog で説明されているメンテナンスの影響があります。

https://jpaztech.github.io/blog/vm/vm-maintenance/

以下の機能を使うと、ある程度 メンテナンスが行われるタイミングを調整する事ができるようです。

https://jpaztech.github.io/blog/network/gw-maintenance/

:::note warn
**動作モードごとの メンテナンス の影響**
アクティブ／スタンバイ の場合は、メンテナンス時に 数十秒の切断時間が発生します。
これを回避するためには、アクティブ／アクティブ モードを採用することで、瞬断レベル（実質 ダウンタイム無し）にすることができます。

詳細は、以下の公開情報で 説明されています。

**VPN Gateway の冗長性について**
https://learn.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-highlyavailable?wt.mc_id=mvp_407731#about-vpn-gateway-redundancy
:::

# VPN Gateway の SKU
VPN ゲートウェイには、SKU があり、選択する プラン によって、利用できる機能と性能、価格、可用性 に差があります。

前章までに説明した、動作モード、AZ タイプ、メンテナンスの影響 などを鑑みて、ゲートウェイ の SKU を選択します。

大きく分けて、レガシ SKU , Generation 1 , Generation 2 の３世代 x AZ 可否 で分類できます。

一度作成した VPN ゲートウェイは、同一世代 内であれば サイズ変更が可能ですが、別の世代 (AZ への変更も含む）への変更はできないため、再作成が必要になります（サイズ変更については、次章で解説）

※公開情報では、Basic も Generation 1 に分類されていますが、レガシ SKU と考えた方が良いと思います（自説）

|機能・性能 ▶<br>▼ 世代|SKU|S2S<br>V2V<br>トンネル|P2S<br>※1|スループット|BGP|AZ|月額<br>概算<br>(円)|
|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|
|レガシ SKU|Basic<br>Standard<br>HighPerf|10<br>10<br>30|128|100 Mbps<br>100 Mbps<br>200 Mbps|✖<br>〇<br>〇|✖|0.4万<br>2万<br>5.2万|
|Gen 1|VpnGw1<br>VpnGw2<br>VpnGw3|30<br>30<br>30|250<br>500<br>1000|650 Mbps<br>1 Gbps<br>1.25 Gbps|〇|✖|2万<br>5.2万<br>13.2万|
|Gen 1<br>(AZ)|VpnGw1AZ<br>VpnGw2AZ<br>VpnGw3AZ|30<br>30<br>30|250<br>500<br>1000|650 Mbps<br>1 Gbps<br>1.25 Gbps|〇|〇|3.8万<br>6万<br>15.2万|
|Gen 2|VpnGw2<br>VpnGw3<br>VpnGw4<br>VpnGw5|30<br>30<br>100<br>100|500<br>1000<br>5000<br>1 万|1.25 Gbps<br>2.5 Gbps<br>5 Gbps<br>10 Gbps|〇|✖|5.2万<br>13.2万<br>22.3万<br>38.5万|
|Gen 2<br> (AZ)|VpnGw2AZ<br>VpnGw3AZ<br>VpnGw4AZ<br>VpnGw5AZ|30<br>30<br>100<br>100|500<br>1000<br>5000<br>1 万|1.25 Gbps<br>2.5 Gbps<br>5 Gbps<br>10 Gbps|〇|〇|6万<br>15.2万<br>25.6万<br>44.3万|

※１：表に記載した数値は、P2S の IKEv2 または OpenVPN での同時接続数です。
SSTP 接続の場合は、すべての SKU で 128 が同時接続数です。

上記の表は、以下の公開情報より抜粋しています。詳細は 公開情報を参照してください。

**公開情報**

https://learn.microsoft.com/ja-jp/azure/vpn-gateway/about-gateway-skus?wt.mc_id=mvp_407731

https://azure.microsoft.com/ja-jp/pricing/details/vpn-gateway?wt.mc_id=mvp_407731

:::note warn
**注意点**
VPN ゲートウェイは、一度 作成すると、停止する事ができず、動作し続けます。
そのため、展開しっぱなしの場合、価格表に記載された １ヵ月あたりの費用が 丸々請求されることになるため、注意が必要です。

時間単価で精算されるため、不用な VPN ゲートウェイは、削除 することが コスト削減に繋がります。
:::

## SKU の サイズ変更について
サイズ変更は、同一世代間 でのみ 変更が可能です。
それから、AZ と 非 AZ の状態を変更する事もできません。
変更できない SKU を利用したい場合は、作り直す必要があります。

**変更可能な組み合わせ**
- レガシ SKU：Basic <-> Standard <-> High Performance
- Generation 1：VpnGw1 <-> VpnGw2 <-> VpnGw3
- Generation 1 (AZ)：VpnGw1AZ <-> VpnGw2AZ <-> VpnGw3AZ
- Generation 2：VpnGw2 <-> VpnGw3 <-> VpnGw4 <-> VpnGw5
- Generation 2 (AZ)：VpnGw2AZ <-> VpnGw3AZ <-> VpnGw4AZ <-> VpnGw5AZ

**SKU の変更またはサイズ変更**
https://learn.microsoft.com/ja-jp/azure/vpn-gateway/about-gateway-skus?wt.mc_id=mvp_407731#resizechange

**レガシ SKU の変更またはサイズ変更**
https://learn.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-about-skus-legacy?wt.mc_id=mvp_407731#resize-migrate-and-change-skus

## レガシ SKU のサポート終了（2024/9/2 時点の内容）
Generation 1 や、Generation 2 は、新しい SKU と呼ばれています。
レガシ SKU は、それ以前から提供されていた SKU です。

このレガシ SKU のうち、**Basic SKU** は、廃止されずに 引き続き 提供されることが発表されています。コレの関連として、パブリック IP アドレス の Basic SKU の廃止が発表されているため、VPN Gateway Basic SKU で、 パブリック IP アドレス の Standard SKU が利用できるように、構成が変更される予定があるようです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/9f2a408c-3bc5-3325-cd97-3884ca392029.png)

**VPN Gateway Basic SKU も廃止されますか?**
https://learn.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-about-skus-legacy?wt.mc_id=mvp_407731#is-the-vpn-gateway-basic-sku-also-retiring

しかし、Standard SKU と High Performance SKU は、2025 年 9 月 30 日に非推奨となることが発表されています。

以下の公開情報に記載がある通り、現時点（2024/9/2）では、レガシ SKU から、新しい SKU への移行手段は提供されていないため、作り直すしかありませんが、2024 年 11 月末までに、移行する方法が提供されることが予告されています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1619637/36ddbe54-5fe6-a64c-f1e8-fbbebf1c1e21.png)

**公開情報：SKU の非推奨**
https://learn.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-about-skus-legacy?wt.mc_id=mvp_407731#sku-deprecation

:::note info
2024/12/14 に 上記のサイトを確認した段階では、どの SKU に移行する事が可能になるのかの見込みが記載されていました。ただし、まだ 実際の移行ができるようにはなっていませんでした。

:::

# 構築手順
構築手順については、今後 私の方で検証を終え次第、追加で投稿していく予定です。
それまでは、公開情報 のリンクをご覧ください。

## VPN Gateway の デプロイ 手順
以下の記事で、VPN ゲートウェイのデプロイ手順のキャプチャ付き に加えて、ARM テンプレートによる 再作成 について紹介しています。

https://qiita.com/carol0226/items/2504c08a88a53bb35f2b

**公開情報：チュートリアル - VPN ゲートウェイを作成して管理する**
https://learn.microsoft.com/ja-jp/azure/vpn-gateway/tutorial-create-gateway-portal?wt.mc_id=mvp_407731

## V2V の 構築手順
以下の記事で、V2V の構成手順をキャプチャ付き で紹介しています。

https://qiita.com/carol0226/private/635408e1f343ba8bc649

**公開情報：VNet 間 VPN ゲートウェイ接続の構成**
https://learn.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-howto-vnet-vnet-resource-manager-portal?wt.mc_id=mvp_407731

## S2S の 構築手順
以下の記事で、YAMAHA ルーター と S2S 接続をする際の手順を キャプチャ付き で紹介しています。

https://qiita.com/carol0226/private/1091c683dd6bd43eeb31

**公開情報：チュートリアル: Azure portal でサイト間 VPN 接続を作成する**
https://learn.microsoft.com/ja-jp/azure/vpn-gateway/tutorial-site-to-site-portal?wt.mc_id=mvp_407731

## P2S の 構築手順
P2S は、以下の公開情報に記載されている通り、３つの方法があります。
- Azure 証明書認証
- Microsoft Entra ID 認証
- RADIUS 認証

**現在、"Azure 証明書認証" のみ Qiita 記事を投稿済み。残りの手順も 投稿を予定しています。**

https://learn.microsoft.com/ja-jp/azure/vpn-gateway/point-to-site-about?wt.mc_id=mvp_407731

### Azure 証明書認証

**公開情報ベースで 自己署名証明書 を使った簡単な手順**

https://qiita.com/carol0226/items/283497c10c94785ebd28

**Intune に登録した PC へ VPN プロファイルを展開する手順**

https://qiita.com/carol0226/items/29bdc47e98e43aa32141

**公開情報**

https://learn.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-howto-point-to-site-resource-manager-portal?wt.mc_id=mvp_407731

### Microsoft Entra ID 認証

https://learn.microsoft.com/ja-jp/azure/vpn-gateway/point-to-site-entra-gateway?wt.mc_id=mvp_407731

### RADIUS 認証

https://learn.microsoft.com/ja-jp/azure/vpn-gateway/point-to-site-how-to-radius-ps?wt.mc_id=mvp_407731

## VPN Gateway のログを Log Analytics に保存する手順

https://qiita.com/carol0226/items/de5591af1464230d102b

## トラブルシューティング

https://learn.microsoft.com/ja-jp/azure/vpn-gateway/troubleshoot-vpn-with-azure-diagnostics?wt.mc_id=mvp_407731

https://jpaztech.github.io/blog/network/vpngw-how-to-check-maintenance/

# FAQ

## Support Blog の FAQ

https://jpaztech.github.io/blog/network/vpngw-FAQ1/

https://jpaztech.github.io/blog/network/vpngw-support-policy/

## 公開情報 の FAQ

https://learn.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-vpn-faq?wt.mc_id=mvp_407731

**IPsec/IKE ポリシーに関する FAQ**
https://learn.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-about-compliance-crypto?wt.mc_id=mvp_407731#ipsecike-policy-faq