AWSとCiscoルーター間でActive-StandbyのインターネットVPN冗長した話

オンプレ環境とAWSをインターネットVPNで冗長化して接続するノウハウをご紹介します！

この記事は アイソルート Advent Calendar 7日目の記事です。

こんにちはこんばんは、
プラットフォームソリューショングループでネットワークエンジニアをしているtahara.hです。

ハイブリットクラウドと言われて暫く経つと思いますが
オンプレ環境とAWSを「インターネットVPNで冗長化」して接続を行いたい場合
意外と情報が少なく困った事がありましたのでご紹介致します。

アジェンダ

1. やりたいこと
2. AWSとオンプレの接続方式
3. 冗長構成時の設計ポイント
   • オンプレ側インターネット回線
   • IPsec
   • ルーティング
   • AWS側からの通信の経路制御
   • オンプレ側からの通信の経路制御
   • チューニング
4. まとめ

やりたいこと

今回やりたい事ですが
社内からプライベートでAWS上のサーバーへ接続する際を想定しており、
以下の要件があるケースでした。

• AWS接続の足回りを高価なDirect Connectでは無く安価なインターネット回線を利用してSite-to-Site VPNで接続したい
• 物理やキャリア障害時も可用性を持たせる為、カスタマーゲートウェイとインターネット回線を冗長化したい
• 経路制御は回線利用を明確に分離して運用したいためActive-Standbyで動作させたい

AWSとオンプレの接続方式

初めにAWSへの接続方式を説明します。
AWSへオンプレミスから接続を行う場合は、大きく分けて2つ方式があります。

一つ目は
“Direct Connect”という専用線をequinixのデータセンターからAWSのVPC内に直接引き込む方式です。
専用の帯域が確保できて高速な通信が可能な為、クリティカルなシステムではこちらを利用すると良いのですが、
社内等の利用したいオンプレ環境からequinixのデータセンターまでは別途回線の設備が必要で敷居が少し高いサービスとなっています。

そのため二つ目にあるのが、
“インターネットVPN”を用いてAWSと接続をする方式です。
AWS内のVPC上で”仮想プライベートゲートウェイ（VGW）”と呼ばれるルーターにIPsecの終端点を作成し、オンプレミス内のIPsec装置である”カスタマーゲートウェイ”とIPsecを利用したSite-to-Site VPNを張ることで接続をおこないます。
カスタマーゲートウェイは、物理機器でも仮想でも良いですし、色々なメーカーの機器が対応しています。

今回は、二つ目のインターネットVPNを回線冗長でおこないます。
オンプレ側のカスタマーゲートウェイは「CiscoのISRルーター」を利用します。

最終的には下記のような構成イメージとなります。

冗長構成時の設計ポイント

AWSとインターネットVPNで冗長を行う場合以下の設計が必要となります。

• オンプレ側インターネット回線
• IPsec
• ルーティング
• AWS側からの通信の経路制御
• オンプレ側からの通信の経路制御
• チューニング

オンプレ側インターネット回線

オンプレ側は物理障害時もサービスを継続させるため、インターネット回線およびカスタマーゲートウェイを２つ準備します。
インターネット回線は、IPsecを張るためにグローバル固定IPアドレスが利用できる契約にする必要があります。
しかし、回線が異なると必ず異なるグローバル固定IPアドレスで払い出される為、
後述するIPsecやルーティングやゲートウェイの冗長化の設計が必要となってきます。

IPsec

AWSとのインターネットVPN接続はIPsecを用いておこないます。
AWSの仕様上1つのカスタマーゲートウェイ接続する際2つのVPNトンネルを張る様になります。
今回は2つカスタマーゲートウェイがあるため合計4つのIPsecを張ることとなります。

また、IPsecの暗号化アルゴリズム等の設定はAWS側の仮想プライベートゲートウェイ作成時に利用するカスタマーゲートウェイの固定IPアドレスとメーカーを指定するとコンフィグを自動生成してダウンロードする事が可能です。（冗長化を考えない場合は非常に簡単に利用が可能です）

ルーティング

さて、前置きが長くなりましたが
ここからが回線冗長時のネットワーク設計のポイントとなってきます。

仮想プライベートゲートウェイ（VGW）の経路選択の優先度は以下の仕様になっています。

1. ロンゲストマッチを優先
2. Direct ConnectとインターネットVPNの同時利用時はDirect Connectを優先
3. スタティックルートと動的ルーティングを同時利用時はスタティックルートが優先
4. BGPのAS-PATH属性を適用
5. 上記に当てはまらないまたは同じ場合はロードバランス

インターネットVPN利用時のAWS側のルーティングは「動的経路（BGP）」または「静的経路（スタティックルート）」を選ぶ事が可能です。
オンプレ側のプレフィック長を同一にした静的経路設定で仮想プライベートゲートウェイ（VGW）に複数のインターネットVPNを接続した場合
上記⑤のルーティングの優先度が同じため、Active-Activeのロードバランスされたルーティングとなってしまいます。
そのため、インターネットVPNのみでActive-Standbyの経路制御を行いたい場合はBGPを用いた動的な経路制御が必要となってきます。

AWS側からの通信の経路制御

上記のルーティングの優先度で、①の静的経路設定でプレフィックス長を細かくしたり、②のDirect Connectを利用するとActive側として経路が優先されるようになりますが、
VGWの経路情報に100ルート上限があったり、高額なコストが発生するため、
今回はAWS側からの通信をActive側に寄せる為には、
上記④に記載の”BGP AP-PATH属性”を利用したトラフィック制御をおこないます。

設定はオンプレ側のカスタマーゲートウェイStandby側のカスタマーゲートウェイに対して
BGP設定でAS-PATHを長くする設定します。

route-map aws-aspath permit 10 
 set as-path prepend 65000 65000

router bgp 65000
 address-family ipv4
 neighbor [AWS GIP2-1 iBGP IPアドレス] route-map aws-aspath out
 neighbor [AWS GIP2-2 iBGP IPアドレス] route-map aws-aspath out
 neighbor [オンプレActiveルータ 渡りIPアドレス] route-map aws-aspath out

AWS側でBGPの経路を受信した仮想プライベートゲートウェイ（VGW）は、
アドバイスされたAS-PATHが少ない方を優先するため
設定を行なっていない（AS-PATHが短い）Active側のカスタマーゲートウェイへ通信を行う様になります。

オンプレ側からの通信の経路制御

オンプレ側はルーティングの観点とゲートウェイの観点の2つで考慮を行う必要があります。

まず、ルーティングについては
インターネットVPNで接続をされたどの経路を使って通信をするのかを設計します。
オンプレ側からの通信経路制御については、BGPの”LOCAL-PREF属性”を用いて経路制御を行なっていきます。

LOCAL-PREF属性は同一AS内の経路を優先をさせたいカスタマーゲートウェイにlocal-preference値を大きくしたものを設定することで実現が可能となります。
そのため、Active側のカスタマーゲートウェイに対してBGPのlocal-preference値をデフォルトの100から200へ変更します。

router bgp 65000
 bgp default local-preference 200

次に、カスタマーゲートウェイとオンプレのコアスイッチとの接続部分（ゲートウェイ）について考えます。
カスタマーゲートウェイとコアスイッチ間でBGPを利用できる場合は、Active側のインターネット経路障害時、コアスイッチからのファーストホップをStandby側のカスタマーゲートウェイに向ける事が可能となるためベストプラクティスとなります。

ただし、今回はオンプレ側の利用したいセグメントを持つコアスイッチがBGPを利用しておらず、スタティックルートでの経路選択を希望されていました。
そのため、
コアスイッチから見たカスタマーゲートウェイのゲートウェイ部分を”HSRP”を用いて冗長化し、コアスイッチ側からカスタマーゲートウェイへはスタティックルートを利用するようにしています。
（もちろんVRRPでも問題はないです）

また、
AWS側のセグメントにはオブジェクトトラッキングの宛先に利用できるIPアドレス（ICMP応答があるVPC内のIPアドレス）は標準では存在せず、
インターフェーストラッキングの設定をVPNの仮想インターフェースに用いることができないため、
インターネット経路障害時のファーストホップのゲートウェイ設計が必要となります。
ゲートウェイ設計の方式としては「ルーティングトラッキングをおこないHSRPを切り替える方法」と「渡りセグメントを準備してBGPで制御する方式」があります。
今回は、ゲートウェイ切り替わりのバタつきを最小限にするために「渡りセグメントを準備してBGPで制御する方式」を採用しています。
Active側のインターネット経路障害時は、ファーストホップはActive側のカスタマーゲートウェイとなり、渡りセグメント経由のStandby側のカスタマーゲートウェイでの通信をおこなう設計となっています。

チューニング

最後にチューニングについて触れておきます。

BGPの設定をデフォルトのままで利用を行うと生存確認（keepalive)が60秒、ダウン検知（Hold Down Time)が180秒となっています。
つまり、経路障害から3分程度経たないと切り処理が始まらない設定となっています。
そのため、生存確認（keepalive)が10秒、ダウン検知（Hold Down Time)が30秒等短くすることで切り替わり時間を短縮することが可能となります。

router bgp 65000
  timers 10 30 

まとめ

AWSのインターネットVPNはシングル構成であればコンフィグも自動で出てきて非常にお手軽に導入が出来るのですが、
今回の様に少し複雑な構成ですとまだまだ細かい設計が必要となります。
本記事が誰かのお役に立てれば幸いです。

明日は、kikuchi.sさんの実際どうなの？Laravelを使う前に知っておくべきことです。

お楽しみに！

# プラットフォームソリューショングループ（ＰＳＧ）

クラウド、ネットワーク・サーバ など、ＩＴインフラの技術やサービスに精通した部門。
また、ＩＴサービスマネジメント分野のコンサルや運用設計、運用管理なども得意としています。
弊社は、システム開発だけではなく、インフラ領域のエキスパートも在籍しており、
例えば、クラウドシステム導入の際は、サーバ・ネットワークなどの基盤を含めた総合的なサービス提供が可能です。