ExpressRoute プライベートピアリングのバックアップとしてのサイト間 VPN の使用

[アーティクル]
04/15/2024

「ExpressRoute プライベートピアリングを使用したディザスターリカバリーの設計」という記事では、ExpressRoute プライベートピアリング使用時のバックアップ接続ソリューションの必要性について説明しました。また、高可用性のために geo 冗長 ExpressRoute 回線を使用する方法についても説明しました。この記事では、ExpressRoute プライベートピアリングのバックアップとしてサイト間 (S2S) VPN を使用および維持する方法について説明します。

Note

ExpressRoute 接続のバックアップソリューションとしてサイト間 VPN を使用することは、待機時間の影響を受けやすいワークロード、ミッションクリティカルなワークロード、または帯域幅を集中的に消費するワークロードを処理する場合には推奨されません。このような場合は、最大限の可用性を確保するために、ExpressRoute マルチサイト回復性を使用してディザスターリカバリーのための設計を行うことをお勧めします。

geo 冗長 ExpressRoute 回線とは異なり、ExpressRoute と VPN のディザスターリカバリーの組み合わせはアクティブ/パッシブセットアップでのみ使用できます。パッシブモードでバックアップネットワーク接続を使用することの主な課題は、パッシブ接続がプライマリ接続と共に失敗することが多いことです。パッシブ接続のエラーの一般的な原因は、アクティブなメンテナンスが不足していることです。したがって、この記事では、ExpressRoute プライベートピアリングをバックアップするサイト間 VPN 接続を検証し、アクティブに維持する方法に焦点を当てます。

注意

ExpressRoute と VPN の両方を介して特定のルートをアドバタイズする場合、Azure では ExpressRoute 経由のルーティングが優先されます。

この記事では、Azure の観点からとオンプレミスネットワークエッジ側の両方から接続を検証する方法についても説明します。どちらの側からも検証できるということは、Microsoft ネットワークエンティティとピアリングするオンプレミスネットワークデバイスを管理するかどうかに関係なく役立ちます。

トポロジの例

このセットアップでは、オンプレミスネットワークが ExpressRoute 回線とサイト間 VPN 接続の両方を介して Azure ハブ仮想ネットワークに接続されています。次の図に示すように、Azure ハブ仮想ネットワークはスポーク仮想ネットワークにピアリングされています。

このセットアップでは、ExpressRoute 回線は、オンプレミスにある "顧客のエッジ" (CE) ルーターのペアで終端されています。オンプレミス LAN は、リーダー/フォロワーモードで動作するファイアウォールのペアで CE ルーターに接続されています。サイト間 VPN は、ファイアウォールで直接終端されています。

次の表に、トポロジの主要な IP プレフィックスを示します。

エンティティ	プレフィックス
オンプレミス LAN	10.1.11.0/25
Azure ハブ仮想ネットワーク	10.17.11.0/25
Azure スポーク仮想ネットワーク	10.17.11.128/26
オンプレミスのテストサーバー	10.1.11.10
スポーク仮想ネットワークテスト VM	10.17.11.132
ExpressRoute プライマリ接続 P2P サブネット	192.168.11.16/30
ExpressRoute セカンダリ接続 P2P サブネット	192.168.11.20/30
VPN ゲートウェイプライマリ BGP ピア IP	10.17.11.76
VPN ゲートウェイセカンダリ BGP ピア IP	10.17.11.77
オンプレミスファイアウォール VPN BGP ピア IP	192.168.11.88
ファイアウォールに向かうプライマリ CE ルーター i/f の IP	192.168.11.0/31
プライマリ CE ルーターに向かうファイアウォール i/f の IP	192.168.11.1/31
ファイアウォールに向かうセカンダリ CE ルーター i/f の IP	192.168.11.2/31
セカンダリ CE ルーターに向かうファイアウォール i/f の IP	192.168.11.3/31

次の表に、トポロジの ASN を示します。

自律システム	ASN
オンプレミス	65020
Microsoft Enterprise Edge	12076
仮想ネットワーク GW (ExR)	65515
仮想ネットワーク GW (VPN)	65515

非対称性のない高可用性

高可用性を実現するための構成

ExpressRoute およびサイト間の共存接続の構成に関する記事では、共存する ExpressRoute とサイト間 VPN 接続を設定する方法について説明しています。「ExpressRoute を使用した高可用性のための設計」で説明したように、このセットアップでは、ネットワークの冗長性を確保してエンドポイントまでの単一障害点を排除することで、ExpressRoute の高可用性を高めています。さらに、ExpressRoute 回線のプライマリ接続とセカンダリ接続の両方がアクティブであり、両方の接続を通じて同じ方法でオンプレミスプレフィックスをアドバタイズしています。

ExpressRoute 回線のプライマリ接続を介したプライマリ CE ルーターのオンプレミスルートのアドバタイズを以下に示します (Junos コマンド):

user@SEA-MX03-01> show route advertising-protocol bgp 192.168.11.18 

Cust11.inet.0: 8 destinations, 8 routes (7 active, 0 holddown, 1 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.1.11.0/25            Self                                    I

ExpressRoute 回線のセカンダリ接続を介したセカンダリ CE ルーターのオンプレミスルートのアドバタイズを以下に示します (Junos コマンド):

user@SEA-MX03-02> show route advertising-protocol bgp 192.168.11.22 

Cust11.inet.0: 8 destinations, 8 routes (7 active, 0 holddown, 1 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.1.11.0/25            Self                                    I

バックアップ接続の高可用性を向上させるために、サイト間 VPN もアクティブ/アクティブモードで構成されます。 Azure VPN Gateway 構成を以下に示します。 VPN 構成の一部として、ゲートウェイの BGP ピア IP アドレス (10.17.11.76 と 10.17.11.77) も示されていることに注意してください。

オンプレミスルートは、ファイアウォールによって、VPN ゲートウェイのプライマリおよびセカンダリ BGP ピアにアドバタイズされます。ルートアドバタイズは次のようになります (Junos)。

user@SEA-SRX42-01> show route advertising-protocol bgp 10.17.11.76 

Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.1.11.0/25            Self                                    I

{primary:node0}
user@SEA-SRX42-01> show route advertising-protocol bgp 10.17.11.77    

Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.1.11.0/25            Self                                    I

注意

サイト間 VPN をアクティブ/アクティブモードで構成すると、ディザスターリカバリーバックアップネットワーク接続に高可用性が提供されるだけでなく、バックアップ接続のスループットも向上します。したがって、アクティブ/アクティブモードでのサイト間 VPN の構成は、基になる複数のトンネルが作成されるため、推奨されます。

対称トラフィックフローを実現するための構成

特定のオンプレミスルートが ExpressRoute とサイト間 VPN の両方を介してアドバタイズされる場合、Azure で ExpressRoute パスが優先されることは既に述べました。共存する ExpressRoute よりもサイト間 VPN のパスが Azure で優先されるように強制するには、VPN 接続経由でより具体的なルート (より大きなサブネットマスクを持つ、より長いプレフィックス) をアドバタイズする必要があります。目的は、VPN 接続をバックアップ専用として使用することです。したがって、Azure の既定のパス選択の動作はここでの目的に一致しています。

オンプレミスから Azure へのトラフィックでも、サイト間 VPN よりも ExpressRoute パスが優先されるようにする必要があります。このオンプレミスセットアップでの CE ルーターとファイアウォールの既定のローカル設定は 100 です。そのため、ExpressRoute プライベートピアリングを介して受信するルートのローカル設定を 100 より大きく構成することにより、Azure 宛てのトラフィックで ExpressRoute 回線が優先されるようにできます。

ExpressRoute 回線のプライマリ接続を終端させるプライマリ CE ルーターの BGP 構成を次に示します。 iBGP セッション経由でアドバタイズされたルートのローカル設定の値が 150 に構成されていることに注意してください。同様に、ExpressRoute 回線のセカンダリ接続を終端させるセカンダリ CE ルーターのローカル設定も、150 に構成されていることを確認する必要があります。

user@SEA-MX03-01> show configuration routing-instances Cust11
description "Customer 11 VRF";
instance-type virtual-router;
interface xe-0/0/0:0.110;
interface ae0.11;
protocols {
  bgp {
    group ibgp {
        type internal;
        local-preference 150;
        neighbor 192.168.11.1;
    }
    group ebgp {
        peer-as 12076;
        bfd-liveness-detection {
            minimum-interval 300;
            multiplier 3;
        }
        neighbor 192.168.11.18;
    }
  }
}

オンプレミスファイアウォールのルーティングテーブルにより、Azure 宛てのオンプレミストラフィックの優先パスが、定常状態で ExpressRoute 経由であることが裏付けられます。

user@SEA-SRX42-01> show route table Cust11.inet.0 10.17.11.0/24

Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.17.11.0/25      *[BGP/170] 2d 00:34:04, localpref 150
                      AS path: 12076 I, validation-state: unverified
                    > to 192.168.11.0 via reth1.11
                      to 192.168.11.2 via reth2.11
                    [BGP/170] 2d 00:34:01, localpref 150
                      AS path: 12076 I, validation-state: unverified
                     > to 192.168.11.2 via reth2.11
                    [BGP/170] 2d 21:12:13, localpref 100, from 10.17.11.76
                       AS path: 65515 I, validation-state: unverified
                    > via st0.118
                    [BGP/170] 2d 00:41:51, localpref 100, from 10.17.11.77
                       AS path: 65515 I, validation-state: unverified
                     > via st0.119
10.17.11.76/32     *[Static/5] 2d 21:12:16
                     > via st0.118
10.17.11.77/32     *[Static/5] 2d 00:41:56
                    > via st0.119
10.17.11.128/26    *[BGP/170] 2d 00:34:04, localpref 150
                       AS path: 12076 I, validation-state: unverified
                     > to 192.168.11.0 via reth1.11
                       to 192.168.11.2 via reth2.11
                    [BGP/170] 2d 00:34:01, localpref 150
                      AS path: 12076 I, validation-state: unverified
                     > to 192.168.11.2 via reth2.11
                    [BGP/170] 2d 21:12:13, localpref 100, from 10.17.11.76
                       AS path: 65515 I, validation-state: unverified
                    > via st0.118
                     [BGP/170] 2d 00:41:51, localpref 100, from 10.17.11.77
                       AS path: 65515 I, validation-state: unverified
                     > via st0.119

上記のルーティングテーブルで、ハブとスポークの仮想ネットワークルート (10.17.11.0/25 と 10.17.11.128/26) では、VPN 接続よりも ExpressRoute 回線が優先されることがわかります。 192.168.11.0 と192.168.11.2 は、CE ルーターに向かうファイアウォールインターフェイスの IP です。

サイト間 VPN 経由のルート交換の検証

この記事の前半で、VPN ゲートウェイのプライマリおよびセカンダリ BGP ピアに対するファイアウォールのオンプレミスルートアドバタイズを検証しました。ここではさらに、VPN ゲートウェイのプライマリおよびセカンダリ BGP ピアからファイアウォールが受信した Azure ルートを確認します。

user@SEA-SRX42-01> show route receive-protocol bgp 10.17.11.76 table Cust11.inet.0 

Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  10.17.11.0/25           10.17.11.76                             65515 I
  10.17.11.128/26         10.17.11.76                             65515 I

{primary:node0}
user@SEA-SRX42-01> show route receive-protocol bgp 10.17.11.77 table Cust11.inet.0    

Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  10.17.11.0/25           10.17.11.77                             65515 I
  10.17.11.128/26         10.17.11.77                             65515 I

同様に、Azure VPN ゲートウェイが受信したオンプレミスのネットワークルートプレフィックスを確認します。

PS C:\Users\user> Get-AzVirtualNetworkGatewayLearnedRoute -ResourceGroupName SEA-Cust11 -VirtualNetworkGatewayName SEA-Cust11-VNet01-gw-vpn | where {$_.Network -eq "10.1.11.0/25"} | select Network, NextHop, AsPath, Weight

Network      NextHop       AsPath      Weight
-------      -------       ------      ------
10.1.11.0/25 192.168.11.88 65020        32768
10.1.11.0/25 10.17.11.76   65020        32768
10.1.11.0/25 10.17.11.69   12076-65020  32769
10.1.11.0/25 10.17.11.69   12076-65020  32769
10.1.11.0/25 192.168.11.88 65020        32768
10.1.11.0/25 10.17.11.77   65020        32768
10.1.11.0/25 10.17.11.69   12076-65020  32769
10.1.11.0/25 10.17.11.69   12076-65020  32769

前述のように、VPN ゲートウェイには、VPN ゲートウェイのプライマリおよびセカンダリの両方の BGP ピアによって受信されたルートがあります。また、プライマリおよびセカンダリの ExpressRoute 接続を介して受信されたルートも確認できます (AS-path の前に 12076 が付加されたもの)。 VPN 接続を介して受信されたルートを確認するには、接続のオンプレミス BGP ピア IP を把握している必要があります。検討対象のこのセットアップでは、IP は 192.168.11.88 であり、そこから受信されたルートが表示されています。

次に、Azure VPN ゲートウェイによってオンプレミスのファイアウォール BGP ピア (192.168.11.88) にアドバタイズされたルートを検証します。

PS C:\Users\user> Get-AzVirtualNetworkGatewayAdvertisedRoute -Peer 192.168.11.88 -ResourceGroupName SEA-Cust11 -VirtualNetworkGatewayName SEA-Cust11-VNet01-gw-vpn |  select Network, NextHop, AsPath, Weight

Network         NextHop     AsPath Weight
-------         -------     ------ ------
10.17.11.0/25   10.17.11.76 65515       0
10.17.11.128/26 10.17.11.76 65515       0
10.17.11.0/25   10.17.11.77 65515       0
10.17.11.128/26 10.17.11.77 65515       0

ルート交換が表示されない場合は、接続エラーを示しています。 VPN 接続のトラブルシューティングについては、「トラブルシューティング: Azure サイト間 VPN が動作を停止して接続できない」をご覧ください。

フェールオーバーのテスト

VPN 接続を介した正常なルート交換 (コントロールプレーン) を確認したので、ExpressRoute 接続から VPN 接続へのトラフィックの切り替え (データプレーン) を行います。

Note

運用環境でのフェールオーバーのテストは、サービスを停止させる可能性があるため、スケジュールされたネットワークメンテナンスの作業期間中に行う必要があります。

トラフィックの切り替えを行う前に、オンプレミスのテストサーバーからスポーク仮想ネットワーク内のテスト VM に至るセットアップ内の現在のパスをトレースルートしてみましょう。

C:\Users\PathLabUser>tracert 10.17.11.132

Tracing route to 10.17.11.132 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  10.1.11.1
  2    <1 ms    <1 ms    11 ms  192.168.11.0
  3    <1 ms    <1 ms    <1 ms  192.168.11.18
  4     *        *        *     Request timed out.
  5     6 ms     6 ms     5 ms  10.17.11.132

Trace complete.

このセットアップのプライマリおよびセカンダリの ExpressRoute ポイントツーポイント接続サブネットは、それぞれ 192.168.11.16/30 と 192.168.11.20/30 になります。上記のトレースルートでは、ステップ 3 で、プライマリ MSEE のインターフェイス IP である192.168.11.18 に到達していることがわかります。 MSEE インターフェイスが存在することにより、予想通り現在のパスが ExpressRoute 経由であることが裏付けられます。

「ExpressRoute 回線のピアリングをリセットする」で報告されているように、次の PowerShell コマンドを使用して、ExpressRoute 回線のプライマリとセカンダリの両方のピアリングを無効にします。

$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Disabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt

フェールオーバーの切り替え時間は BGP のコンバージェンス時間によって異なります。このセットアップでは、フェールオーバーの切り替えにかかる時間は数秒 (10 秒未満) です。切り替え後に traceroute を再び実行すると、次のパスが表示されます。

C:\Users\PathLabUser>tracert 10.17.11.132

Tracing route to 10.17.11.132 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  10.1.11.1
  2     *        *        *     Request timed out.
  3     6 ms     7 ms     9 ms  10.17.11.132

Trace complete.

traceroute の結果により、サイト間 VPN 経由のバックアップ接続がアクティブであり、プライマリとセカンダリの両方の ExpressRoute 接続に障害が発生した場合にサービスの継続性を確保できることが裏付けられます。フェールオーバーテストを完了するには、次のコマンドセットを使用して、ExpressRoute 接続を有効に戻し、トラフィックフローを正常化します。

$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Enabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt

トラフィックが ExpressRoute に戻されたことを確認するには、traceroute を再び実行し、トラフィックが ExpressRoute プライベートピアリングを通過することを確認します。

次のステップ

ExpressRoute は、Microsoft ネットワーク内で単一障害点のない高可用性を実現するように設計されています。ただし、ExpressRoute 回線は、1 つの地理的リージョンおよび 1 つのサービスプロバイダーに限定されています。サイト間 VPN は、ExpressRoute 回線に対する優れたディザスターリカバリーパッシブバックアップソリューションです。信頼できるパッシブバックアップ接続ソリューションを実現するには、パッシブ構成の定期的なメンテナンスと接続の定期的な検証を行うことが重要です。 VPN 構成を陳腐化させないようにし、この記事に記載されている検証とフェールオーバーのテスト手順をメンテナンス期間中に定期的に (たとえば四半期ごとに) 繰り返すことが不可欠です。

VPN Gateway メトリックに基づいて監視とアラートを有効にするには、「VPN Gateway メトリックにアラートを設定する」を参照してください。

ExpressRoute の障害後に BGP コンバージェンスを迅速に行うには、ExpressRoute 経由の BFD の構成を行います。

次の方法で共有

ExpressRoute プライベートピアリングのバックアップとしてのサイト間 VPN の使用

トポロジの例

非対称性のない高可用性

高可用性を実現するための構成

対称トラフィックフローを実現するための構成

サイト間 VPN 経由のルート交換の検証

フェールオーバーのテスト

次のステップ

フィードバック

その他のリソース

次の方法で共有

ExpressRoute プライベート ピアリングのバックアップとしてのサイト間 VPN の使用

トポロジの例

非対称性のない高可用性

高可用性を実現するための構成

対称トラフィック フローを実現するための構成

サイト間 VPN 経由のルート交換の検証

フェールオーバーのテスト

次のステップ

フィードバック

その他のリソース

ExpressRoute プライベートピアリングのバックアップとしてのサイト間 VPN の使用

対称トラフィックフローを実現するための構成