AWS Site-to-Site VPNを静的ルーティングで冗長化する

記事タイトルとURLをコピーする

こんにちは!サーバーワークスの松井です。

今回は、社内ネットワーク環境とAWS環境をAWS Site-to-Site VPNで静的ルーティングで接続し、冗長化する時の設定方法について紹介したいと思います。

やりたいこと

・AWS上のEC2と社内ネットワーク上のオンプレサーバーが疎通できるようにする

・AWSと社内ネットワークを静的AWS Site-to-Site VPNでつなぐ

・AWS Site-to-Site VPNは冗長化する(アクティブ/アクティブ)

事前準備

以下を事前に作成しておきます。

・カスタマーゲートウェイ(CGW)x2

・仮想プライベートゲートウェイ(VGW)x1

・EC2が配置されたサブネットのルートテーブルにて、VPNで広報する範囲を仮想プライベートゲートウェイに向けるよう記載

※オンプレルータのGlobal IPアドレスをそれぞれのCGWに指定、VRRPを使っている場合はCGWは1つ)

※すでにDirectConnectを接続しており、ネットワーク長の短いCIDR重複した範囲で仮想プライベートゲートウェイ向けのルートテーブルの記載がある場合は変更不要

構成図

AWS Site-to-Site VPNの設定

仮想プライベートゲートウェイ

・事前に作成したVGWを指定

カスタマーゲートウェイ

・事前に作成したカスタマーゲートウェイを指定

静的CIDR

・優先させたいVPNが広報するCIDR範囲をよりネットワーク長が長くなるように設定する

設定例

VPN-A:10.1.0.0/32

VPN-B:10.1.0.0/31

※AWSから社内ネットワークへの通信に関しては、ネットワーク長がより長い経路を優先します

※上記で設定した場合よりネットワーク長の長いVPN-Aを優先します。

※Direct Connectと広報するCIDR範囲(例:10.0.0.0/8)が重複している場合でもネットワーク長がより長い経路が優先されます。

※オンプレ側からAWS側へのルーティングは優先制御可能ですが、 AWS側からオンプレへのルーティングは2つのIPSec VPNトンネルでロードバランスします。 そのため、オンプレルーター側での非対称ルーティングの設定をする必要があります。

参考リンク

https://aws.amazon.com/jp/premiumsupport/knowledge-center/vpn-configure-tunnel-preference

ローカルIPv4ネットワークCIDR

・AWSから社内ネットワークへ広報するCIDR範囲を記載する

設定例

VPN-A: 10.1.0.0/32

VPN-B: 10.1.0.0/31

リモートIPv4ネットワークCIDR

・社内ネットワークからAWS側へ広報する範囲を記載する

設定例

VPN-A: 176.10.0.10/32

VPN-B: 176.10.0.10/32

トンネル1,2の内部IPv4 CIDR

・AWSで自動生成可能だが、ルーター側で設定した値を指定可能

※内部IPアドレスは、他のネットワークのCIDR範囲と重複しないようにしてください

トンネル1,2の事前共有キー

・AWSで自動生成可能だが、ルーター側で設定した値を指定可能

構築後

・AWS Site-to-Site VPNは構築すると2つのGlobal IPアドレスと2つのIPSec VPNトンネルが作成されます。

・構築後にオンプレルーターの種類に合わせた設定ファイルをダウンロードすることができるので、オンプレルーター側に設定ファイルの情報を設定していきます。

・アクティブ/アクティブ構成で繋ぐ場合、ルーターの設定後マネージメントコンソール上でIPSec VPNトンネルがすべてアップになり、AWS上のEC2とオンプレサーバーが疎通可能な状態になります。

障害時

・IPSec VPNトンネルが一本ダウンした場合

オンプレルーター側の設定をしておくと、アップしている方のIPSec VPNトンネルにトラフィックを流します。

・片側のVPNのIPSec VPNトンネルが両方ダウンした場合

オンプレルーター側の設定をしておくと、仮想プライベートゲートウェイはアップしている方のVPNにトラフィックを流します。

※アクティブ/アクティブ構成を前提とする

まとめ

今回はAWSでAWS Site-to-Site VPNを静的ルーティングで冗長化してつなぐ際の設定方法を紹介しました。

AWS Site-to-Site VPNをを冗長化する場合、本来静的ルーティングは向いていませんが、通信が行われるCIDR範囲をお互いに認識した上で固定化できるので、AWS側とオンプレルーター側でCIDRが増えたとしても、手動で変更しない限り設定していないCIDR範囲からの通信は行われないことが保証されます。

動的ルーティングの場合は、障害時の切り替えの利便性が高いことやAWS側とオンプレルーター側でCIDR範囲が増えたときに自動でルーティングが追加され、毎回設定を更新する手間を省くことができるなどのメリットがあります。

通信可能範囲をステートレスかステートフルのどちらにするかは要件によって異なるかと思うので使い分けが必要になるかと思います。