強制トンネリング利用時の VPN ゲートウェイの動作変更についてのアナウンス

Last Update: feedback 共有

こんにちは、Azure テクニカル サポート チームです。

Azure の仮想ネットワーク ゲートウェイ (以下「ゲートウェイ」) を用いたサイト間 VPN 接続について、2022 年 2 月 24 日以降に、強制トンネリングに関する一部の動作の変更が行われることがアナウンスされました。

影響が生じる可能性のあるお客様には通知がすでに送信されているか、近日中に送信されることが想定されます。しかしながら、通知に含まれる説明は要点のみとなっているため、本記事にてその補足をさせていただきます。

※追記
2023 年 5 月 再度、強制トンネリング利用時の仮想ネットワーク ゲートウェイの動作変更のアナウンス (Tracking ID:VK3J-580)が通知されました。
これは、2022 年に通知されたアナウンス (Tracking ID:ZTPX-19Z)と同様の内容となりますが、動作変更の延期により今回あらためて仮想ネットワーク ゲートウェイ は、2023/6/12 ~ 6/16 の間に動作変更が実施されるという旨のアナウンスとなります。
2022 年に通知を受け取ったお客様の中で、下記の対応を行っていない環境については、動作変更の影響を受ける条件や合致確認の方法、動作変更の内容および変更の影響を受けないようにする対処方法をご確認の上、2023/6/12 より前にご対応いただけますと幸いでございます。



本記事の内容

本記事では、動作変更の影響を受ける条件やその合致確認の方法、動作変更の内容および変更の影響を受けないようにする対処方法ついてまとめております。本記事を参考に影響有無を確認するとともに、影響が想定される場合は 2 月 24 日までにあらかじめ対処を実施いただければと思います。

前半ではリソース マネージャー モデル（新しいモデル）のための手順、後半ではクラシック モデル（古いモデル）のための手順をおまとめしておりますので、それぞれご利用の環境に合わせて確認ください。



今回の動作変更の背景

Azure のゲートウェイには、「SKU」と呼ばれるパラメーターがあり、ゲートウェイの性能や冗長構成を指定することができます。ゲートウェイの SKU には、大きくわけて以下の 2 種類があります。

  • 末尾に AZ がつく SKU: VpnGw1AZ、VpnGw2AZ、VpnGw3AZ、VpnGw4AZ、VpnGw5AZ
  • 末尾に AZ がつかない SKU: VpnGw1、VpnGw2、VpnGw3、VpnGw4、VpnGw5、Basic、Standard、HighPerformance

AZ がつく SKU とつかない SKU では、冗長性確保のためのデータセンター内部の配置が少し違うのみで、そのほかに機能面での基本的な違いはありません。

しかし今回、特定の条件下において、AZ がつく SKU と AZ がつかない SKU で強制トンネリングに関する一部の動作 (詳細は後述) に差異があることが判明しました。AZ がつかない SKU を対象に動作変更を行い、AZ がつく SKU の動作を正として動作を揃えるというのが、今回のアナウンスの内容です。



動作変更の内容

強制トンネリングを実現する 2 種類の方法

Azure のサイト間 VPN においては、Azure 仮想ネットワークから送信されるすべての通信を、データセンターのバックボーンネットワークではなく、VPN にルーティングする「強制トンネリング」という構成が可能です。サイト間 VPN で強制トンネリングを構成するためには、以下の 2 種類の方法があります。

  • 方法 1. 対向のルーターと BGP で経路交換を行い、対向のルーターからデフォルト ルート 0.0.0.0/0 (を広報する)
  • 方法 2. BGP は利用せず、ゲートウェイに DefaultSite の設定を行う

動作が変更される対象となる方法

このうち、方法 2 を利用している場合は、SKU によって強制トンネリングのために必要な作業が少し異なります。SKU に AZ がつく場合は、DefaultSite の設定を行うだけで、仮想ネットワーク内の全てのサブネットに対して、デフォルト ルートを VPN に向けるルートが反映されます。

しかし AZ がつかない場合は、DefaultSite の設定を行うだけでは強制トンネリングのためのルートが適用されません。DefaultSite の設定に加えて、0.0.0.0/0 のネクストホップをゲートウェイにしたユーザー定義ルート (UDR) を各サブネットに適用することで、はじめて強制トンネリングがそのサブネットで有効になります。

今回の動作変更では、この動作を AZ がつく SKU に合わせます。つまり、DefaultSite の設定がされている環境では、0.0.0.0/0 をゲートウェイに向ける UDR が適用されていなくても、強制トンネリングが有効になります。対象の環境においては、強制トンネリングが現状有効になっていないサブネットで、2 月 24 日以降に突然強制トンネリングが有効になる、ということが起こり得ます。

※ 方法 1 (BGP) を利用している場合は、今回の動作変更による影響はありません。



動作変更による影響が生じる条件

以下の 5 つの条件に すべて 合致した場合に、今回の動作変更の影響を受けます。

  • A. VPN 用の仮想ネットワーク ゲートウェイがある
  • B. ゲートウェイの SKU は末尾に AZ がつかないものである
  • C. サイト間 VPN を利用している
  • D. BGP でデフォルト ルートを 0.0.0.0/0 を受信していない
  • E. DefaultSiteの設定がされている

それぞれの条件についての合致確認の方法は、本記事の末尾にまとめております。



条件にすべて合致した場合の対応

上記の 5 つの条件に すべて 合致した場合、動作変更の影響が生じる可能性があります。つまり、0.0.0.0/0 をゲートウェイに向けるユーザー定義ルートが適用されていなくても、2 月 24 日以降の動作変更によって、強制トンネリングがそのサブネットで有効になります。

予期せず強制トンネリングが有効になることを防ぐためには、あらかじめ 0.0.0.0/0 のネクストホップをインターネットに向ける UDR を適用することが有効です。2 月 24 日よりも前にこの UDR を適用しておくことで、その UDR が適用されたサブネットでは、動作変更によって強制トンネリングが突然有効になる状況を回避することができます。

（したがって、現状ですでに 0.0.0.0/0 のネクストホップをインターネットに設定する UDR が適用されているサブネットについては、影響を受けません）

対応手順の例

具体的な手順の一例は以下のとおりです。各パラメーターについてはお客様の環境に合わせて確認および決定してください。

  1. Azure ポータルを開きます。

    https://portal.azure.com/

  2. すでに対象のサブネットにルート テーブルが適用されている場合は、手順 5) までスキップします。

  3. [ルート テーブル] を開き、[+作成] をクリックします。

  4. 以下のパラメーターを入力し、[確認および作成] をクリックします。(詳細なパラメーターは環境に合わせてください)

    　リソース グループ: 任意

    　リージョン: ルート テーブルの適用対象の仮想ネットワークと合わせる

    　名前: ルート テーブルの任意の名前

    　ゲートウェイのルートを伝達する: Yes

  5. 4) で作成したルート テーブルか、既存のルート テーブルを開きます。

  6. [ルート] メニューをクリックし、[+追加] をクリックします。

  7. 以下のパラメーターでルートを追加して [OK] をクリックします。

    　ルート名: 任意の名前

    　アドレス プレフィックス: 0.0.0.0/0

    　ネクスト ホップの種類: インターネット

  8. すでに対象のサブネットにルート テーブルが適用されている状態で作業を行った場合は、これで終了です。

  9. [サブネット] メニューをクリックし、[+関連付け] をクリックします。

  10. ルート テーブルの適用対象の仮想ネットワークとサブネットを選択して、[OK] をクリックします。

※ ルート テーブルの設定手順は 公開資料 でも説明されておりますので、あわせてご覧ください。


　
　

条件に合致しているかどうかを確認するための詳細手順

A～E それぞれの条件について、合致しているかどうかを確認するための手順の一例をご紹介いたします。

A. VPN 用の仮想ネットワーク ゲートウェイがあることの確認

Azure ポータルで [仮想ネットワーク ゲートウェイ] メニューを開き、[ゲートウェイの種類] が [Vpn] のものがあれば、この条件に合致しています。

画面イメージ

B. ゲートウェイの SKU は末尾に AZ がつかないものであることの確認

A. でみつけたゲートウェイをクリックし、[SKU] 欄を確認して「AZ」が含まれていないものであれば、この条件に合致しています。（以下の画像は「AZ」が含まれる場合の例、つまり条件に合致しない例です）

画面イメージ

C. サイト間 VPN を利用していることの確認

A. でみつけたゲートウェイをクリックし、[接続] メニューをクリックします。

画面イメージ

[接続] オブジェクトが表示されれば、この条件に合致しています。

画面イメージ

D. BGP でデフォルト ルートを 0.0.0.0/0 を受信していないことの確認

A. でみつけたゲートウェイをクリックし、[BGP ピア] メニューをクリックします。

[学習したルート] に 0.0.0.0/0 が含まれて いなければ、この条件に合致しています。（0.0.0.0/0 が含まれていたら、この条件に合致しませんので今回の変更の影響も受けません。少し紛らわしいのでご注意ください）

E. DefaultSiteの設定がされていることの確認

この確認は PowerShell での作業が必要になります。

  1. Azure PowerShell を起動するか、Cloud Shell (PowerShell を選択) を開きます。

  2. Azure PowerShell の場合、以下のコマンドを実行してサインインします。

    Login-AzAccount

  3. A. でみつけたゲートウェイが構築されているサブスクリプション ID を確認し、以下のコマンドを実行して操作対象のサブスクリプションを指定します。

    Select-AzSubscription -SubscriptionId <確認したサブスクリプション ID>

  4. 以下のコマンドを実行し、対象のゲートウェイの構成情報を取得・表示します。

    Get-AzVirtualNetworkGateway -Name <ゲートウェイの名前> -ResourceGroupName <ゲートウェイのリソース グループ名> | Format-List -Property *

  5. 出力結果の中から、GatewayDefaultSite という行を探します。サイト名の情報が入っている場合は、この条件に合致します。空欄または「null」となっている場合は合致しません。



　
　
　

※ 以下は、クラシック デプロイ モデルをご利用の方に向けた手順です。

(クラシックの場合) 条件にすべて合致した場合の対応

クラシック デプロイ モデルをご利用の場合における具体的な手順の一例は以下のとおりです。各パラメーターについてはお客様の環境に合わせて確認および決定してください。

事前準備: Azure PowerShell の利用

クラシック デプロイ モデルにおける対処のためには、Azure PowerShell をご利用いただくことができます。対処用のコマンドを実行するためには、事前に以下のコマンドを実行する必要があります。

  1. 以下のコマンドを実行し、サインインします。

    Add-AzureAccount

  2. 以下のコマンドを実行し、対象のサブスクリプションを指定します。

    Select-AzureSubscription -SubscriptionId <サブスクリプション ID>

対応手順の例

具体的な手順の一例は以下のとおりです。各パラメーターについてはお客様の環境に合わせて確認および決定してください。

  1. 対象のサブネットにすでにルート テーブルが適用されているかどうかを確認します。

    Get-AzureSubnetRouteTable -VirtualNetworkName “仮想ネットワーク名” -SubnetName “サブネット名”

  2. すでに対象のサブネットにルート テーブルが適用されている場合は、手順 4) までスキップします。

  3. 任意の名前でルート テーブルを作成します。

    New-AzureRouteTable -Name “ルート テーブルの名前” -Location “リージョン名”

  4. ルート テーブルに、0.0.0.0/0 のネクストホップを Internet に指定したルートを追加します。

    Get-AzureRouteTable -Name “ルート テーブルの名前” | Set-AzureRoute -RouteName “DefaultRoute” -AddressPrefix “0.0.0.0/0” -NextHopType Internet

  5. すでに対象のサブネットにルート テーブルが適用されている状態で作業を行った場合は、これで終了です。

  6. ルート テーブルをサブネットに適用します。

    Set-AzureSubnetRouteTable -VirtualNetworkName “仮想ネットワーク名” -SubnetName “サブネット名” -RouteTableName “ルート テーブルの名前”



(クラシックの場合) 条件に合致しているかどうかを確認するための詳細手順

クラシック デプロイ モデルをご利用の場合において、A～E それぞれの条件について、合致しているかどうかを確認するための手順の一例をご紹介いたします。

事前準備: Azure PowerShell の利用

クラシック デプロイ モデルにおける合致確認には、Azure PowerShell をご利用いただくことができます。合致確認用のコマンドを実行するためには、事前に以下のコマンドを実行する必要があります。

  1. 以下のコマンドを実行し、サインインします。

    Add-AzureAccount

  2. 以下のコマンドを実行し、対象のサブスクリプションを指定します。

    Select-AzureSubscription -SubscriptionId <確認したサブスクリプション ID>

A. VPN 用の仮想ネットワーク ゲートウェイがあることの確認

(確認不要) 下記 E. の手順に包含されるため、本手順は割愛します。

B. ゲートウェイの SKU は末尾に AZ がつかないものであることの確認

(確認不要) クラシックでは、必ず AZ がつかない SKU となりますので、本手順は割愛します。

C. サイト間 VPN を利用していることの確認

(確認不要) 下記 E. の手順に包含されるため、本手順は割愛します。

D. BGP でデフォルト ルートを 0.0.0.0/0 を受信していないことの確認

(確認不要) クラシックでは BGP は利用できないため、本手順は割愛します。

E. DefaultSiteの設定がされていることの確認

  1. Azure PowerShell で以下のコマンドを実行します。

    Get-AzureVirtualNetworkGateway

  2. 表示されたゲートウェイの一覧から、以下のように DefaultSite に値が入っているものがあれば、合致しています。

    GatewayId : xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

    GatewayName : Default

    LastEventData :

    GatewayType : DynamicRouting

    LastEventTimeStamp : xx/xx/xxxx xx:xx:xx

    LastEventMessage : Successfully updated the gateway for the following virtual network: xxxx ← 通常、ここに対象の仮想ネットワーク名が入ります。

    LastEventID : xxxxx

    State : Provisioned

    VIPAddress : x.x.x.x

    DefaultSite : Site01 ← ここにサイト名が入っていれば該当しています。該当しない場合空欄です。

    GatewaySKU : Standard

    Location : Japan East

    VnetId : xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

    SubnetId :

    EnableBgp : False

    Asn : xxxxx

    BgpPeeringAddress : x.x.x.x

    PeerWeight : 0

    OperationDescription :

    OperationId :

    OperationStatus :

※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。