IDコラム

トップページ > コラム >  【エバンジェリスト・ボイス】松...

【エバンジェリスト・ボイス】松立てて 空ほのぼのとAWS Transit Gateway w/ BGP 2019/01/23 (水)

サイバー・セキュリティ・ソリューション(CSS)部
エバンジェリスト フェロー 関原 弘樹    顔写真2_1187x1313

こんにちは!
CSS部エバンジェリスト フェローの関原です。
 
1月も下旬となりましたが、私にとって本年最初のエントリーとなります。本年も本コラムをどうぞよろしくお願い申し上げます。

さて、re:Invent 2018で発表されたAWSの新サービス、AWS Transit Gatewayですが201812月中旬より東京リージョンでも利用可能となりました。今回はこの新しいAWSサービスの特徴と簡単な検証結果について書いてみます。

AWS Transit Gatewayとは?
一言でいえばAWSの既存のサイト接続機能
・(インターネット経由のIPSecSite-to-Site VPN 接続
VPC ピアリング接続(クロスアカウントを含む)
Direct Connect(執筆時点で予定)
を統合するGatewayサービスです。

公式ブログの図ですとこのようなイメージになります。

図1_430x456

出典:https://aws.amazon.com/jp/blogs/aws/new-use-an-aws-transit-gateway-to-simplify-your-network-architecture/

AWS中心のサイト構成を考えた場合、数個のVPCVPNサイトしか存在しない構成であれば既存のサービスでも十分構成と管理が可能ですが、二桁に手が届くところからかなり煩わしくなってくると思います。

AWS Transit Gatewayはこのような構成でも単一のインターワークGatewayとして機能し、簡単に構成や管理が可能なサービスとして開発されています。

ただし、一点だけ落とし穴があるようで、現時点では既存のSite-to-Site VPN 接続で可能であったAWSをハブサイトとしたAWSとオンプレミスサイトのハブアンドスポーク構成はAWS Transit Gatewayでは不可能です。別のサービスと組み合わせて使う必要があります。 

その他、制限事項等のFAQはこちらです。

外部サイト:AWS Transit Gateway よくある質問


AWS Transit Gatewayの具体的なメリットは
M個あるVPCをフルメッシュで接続し、N個のVPNサイトが各VPCVPN接続をすることを想定してみましょう。 

・既存のAWSサイト接続機能の場合・・・
⇒合計でM*(M-1)/2個のVPCピアリングとM*N本のVPN~サイト間VPN接続が必要となる。

AWS Transit Gatewayを利用した場合・・・
1つのAWS Transit GatewayM+N個のTransit Gateway Attachmentsが必要となる。

例えば
VPC=2=M VPNサイト=2=Nの場合
既存機能 ⇒合計で5接続の構成と管理
AWS Transit Gateway ⇒1つのAWS Transit Gateway4つのTransit Gateway Attachmentsの構成と管理

VPC=5=M VPNサイト=10=Nの場合
既存機能 ⇒合計で60接続の構成と管理
AWS Transit Gateway ⇒1つのAWS Transit Gateway15Transit Gateway Attachmentsの構成と管理

VPC=10=M VPNサイト=20=Nの場合
既存機能 ⇒合計で245接続の構成と管理
AWS Transit Gateway ⇒1つのAWS Transit Gateway30Transit Gateway Attachmentsの構成と管理

このように、大規模な構成になればなるほど差が開き、構成と管理の面でメリットが出てくることがお分かりいただけると思います。


■検証について
今回はVPN接続とVPCピアリングのインターワークを確認してみましょう。
大規模な構成の場合、スタティックルーティングでは設計と検証に大きな工数がかかりますので、ダイナミックルーティングを利用したいですね。

今回はBGPでのルーティングを採用してみます。オンプレのVPNデバイスにはちょうど手元にCisco891Fがありましたので今回はこちらを使ってみます。

--------
Test-01#sh ver
Cisco IOS Software, C800 Software (C800-UNIVERSALK9-M), Version 15.8(3)M, RELEASE SOFTWARE (fc4)

Cisco C891FJ-K9 (revision 1.0) with 488524K/35763K bytes of memory.
--------


AWS側の設定
東京リージョンからVPCダッシュボードの一番下をみて「Transit Gateways」を開きます。図2_622x485


①Create Transit Gateway
で名前以外はデフォルトのTransit Gatewayを作成

図3_973x759
以下未検証の情報もありますが。このような感じでしょうか。

DNS support
⇒別VPCからのプライベートFQDN解決の可否

VPN ECMP support
⇒帯域向上のためのサイト~AWS間の等コストマルチパス(Equal Cost Multipath)の可否

Default route table association
⇒Transit Gatewayのデフォルトのルートテーブルが各Gateway Attachmentに自動で関連付けられるかの可否

Default route table propagation
⇒各Gateway Attachment からアドバタイズされるルートがTransit Gatewayのデフォルトのルートテーブルに自動で関連付けられるかの可否

Auto accept shared attachments
⇒このTransit Gatewayに関連したクロスアカウント共有リクエストの自動承認の可否

少し待つとTransit Gatewayの完成!図4_932x651

 

②Transit Gateway AttachmentというVPCやVPN接続を統合するインターフェイスを作成

図5_790x835

 
かねて用意のVPC(ここでは10.255.0.0/16、IGWは無し)にアタッチ図6_779x823

Transit Gateway Attachmentの一つ目が完成図7_819x250

※VPCルーティングテーブルの設定

きっちりとドキュメントを読まなかったせいか数十分はまりました。
Transit GatewayとVPCのルーティングテーブルは独立していますのでVPCをアタッチした後、VPCのルートテーブルで必要なルートをTransit Gatewayに向ける必要があります。

ここではデフォルトルート(0.0.0.0/0)を向けておきます。図8_1581x538

 
③続いてVPNの統合
今回は既存で作成済のカスタマゲートウェイがあるので流用します。
図9_893x859

 #以下の理由よりTunnel Optionsのパラメータは隠しておりませんが、本番環境でご利用の際は空欄で設定し、AWS側がランダムで払い出す値を使用するほうが望ましいです。
#理由1 個人的にConfigはまるまるコピペしないのでパラメータが覚えやすい。
#理由2 トンネル内サブネットはルーティングテーブルに載らないので直接接続のVPNデバイスからしかリーチャビリティがなく、公開しても問題ない
#理由3 AWSが対応するISAKMPはメインモードのみのため、仮にPSKが知られたとしても第三者によるSAは事実上作成不能。
#まあ、検証が終わったらすぐに破棄するからということもあります。


Transit Gateway Attachmentが2つできました。図10_1515x278

 

④Site-to-Site VPN 接続のタブを開くと新しいVPN接続ができているので設定をダウンロード
今回はCisco ISRのIOS用です。
図11_1508x506

AWS側の設定はとりあえず以上です。


VPNデバイスの設定
ダウンロードしたConfigを確認し、VPNデバイス(今回は手元のCisco Router)に設定を流し込みます。
#ダウンロードしたコンフィグにはVPN関連のセクションしか記載していないので最低限のインターネット接続設定は事前にしておく必要があります。

#なぜか「③続いてVPNの統合です。」のスクリーンショットで設定したパラメータがTunnel1と2で逆になったものがダウンロードされます。
実用上問題ないのですが、精神上よくないので私のConfigは独自に修正しています。図12_758x267

 

##お年玉(!?)として以下より今回のConfig例がコピーできます。パラメータを確認の上、自己責任でご利用ください。




⇒アクセスはフレッツ(PPPoE)

⇒ローカル側サブネットは192.168.100.0/24
⇒VPNサイト内のクライアントからのインターネット接続は各サイトからCBAC(SPI)つきのNATでブレイクアウト

⇒VPC内のインスタンスからのインターネット接続は特定サイトからNATで接続


VPNBGPの疎通確認
紙面の関係で細かいところは端折りますが、うまくいくとこのようになります。
BGPによりVPNデバイス側はスタティックな設定なしで10.255.0.0/16を学習し、VPC側はスタティック設定なしで192.168.100.0/24を学習しています。

BGPネイバーとBGPルートの確認、VLAN1側から内部にPING成功図13_897x925

 

Transit Gateway route tableタブ
デフォルトルート(0.0.0.0/0)の先はBGPで0.0.0.0/0をアドバタイズしたVPNサイトとなります。図14_1574x549

 

VPCの追加
続けて別のVPC(ここでは172.16.0.0/24IGWは無し)を追加してみましょう。

Attachmentを作成し・・・図15_933x853

確認!図16_1404x465

 

例によってデフォルトをTransit Gatewayに向けてルートの確認図17_1456x534

 

VPNネイバーは増えずにルートがアドバタイズされています。図18_889x957

これは便利!


■ポイントをいくつか
Ciscoルータの設定にあたり2つほどポイントを。

①IPSecのセキュリティパラメータはDLしたものをそのまま使わない!
DLできるファイルのセキュリティパラメータはやや古いシステムとの互換性を考えており、ベースライン(許容される下限ギリギリ)のパラメータとなっています。許容範囲内という考え方もありますが、今後パラメータ部分がコピペで長く使用された場合、急な危殆化に対応できないリスクが残るため変更を強く推奨いたします。

紙面の都合でここでは詳細を解説できませんが、トラフィックを暗号化する共通鍵を共有するためのDiffie-Hellman key exchangeDH)のbit長が短い場合、鍵交換のトラフィックをキャプチャして共通鍵を推測される可能性、つまりVPNトラフィックを事後に解読されるリスクが高まります。よって特にDH Groupの値はGroup142048bit)への変更が必須と考えらえれます。

外部サイト:768ビット素数位数の有限体上の離散対数問題の状況とDSA, DHの今後のパラメータ選択について(CRYPTREC)


--
crypto isakmp policy 10
 encr aes 256
 hash sha256
 authentication pre-share
 group 14
!
crypto ipsec transform-set IDSET esp-aes 256 esp-sha256-hmac
 mode tunnel
!
crypto ipsec profile ID-TUNNEL
 set transform-set IDSET
 set pfs group14
--

②各定義のネーミングはミス防止のため簡潔なものが望ましい!
AWSからダウンロードできるConfigファイルは設定を変えるたびにコピペで設定を流し込む人のためにネーミングがダブないようにとの配慮でしょうが見づらいです・・・

--
crypto keyring KEY-1
crypto keyring KEY-2
!
crypto isakmp profile ID-PROFILE-1
   keyring KEY-1
crypto isakmp profile ID-PROFILE-2
   keyring KEY-2
!
crypto ipsec transform-set IDSET esp-aes 256 esp-sha256-hmac
!
crypto ipsec profile ID-TUNNEL
 set transform-set IDSET
!
interface Tunnel1
 tunnel protection ipsec profile ID-TUNNEL
!
interface Tunnel2
 tunnel protection ipsec profile ID-TUNNEL
--


■まとめ
最後にAWS Transit Gatewayが高速なフェイルオーバーを可能とする。BFDBidirectional Forwarding Detection)をサポートしているか確認してみました。

この結果を見ると残念ながらサポートされていないようです・・・図19_901x959

 

BFDとは
外部サイト:BFD概説(AX7800RAX7700Rソフトウェアマニュアル解説書 Vol.1 

いかがでしたでしょうか。
このようにAWS Transit GatewayBGPと組み合わせて利用するとクラウドのトポロジーをスケーラブルかつフレキシブルに構成することが可能となります。

ではまた、次回のエントリーでお会いしましょう。

Hiroki Sekihara CRISC, CISSP, CEH, PMP, CCIE #14607

お問い合わせ