IDコラム
IDコラム
【エバンジェリスト・ボイス】松立てて 空ほのぼのとAWS Transit Gateway w/ BGP 2019/01/23 (水)
サイバー・セキュリティ・ソリューション（CSS）部
エバンジェリスト フェロー 関原 弘樹 
こんにちは！
CSS部エバンジェリスト フェローの関原です。
1月も下旬となりましたが、私にとって本年最初のエントリーとなります。本年も本コラムをどうぞよろしくお願い申し上げます。
さて、re:Invent 2018で発表されたAWSの新サービス、AWS Transit Gatewayですが2018年12月中旬より東京リージョンでも利用可能となりました。今回はこの新しいAWSサービスの特徴と簡単な検証結果について書いてみます。
■AWS Transit Gatewayとは？
一言でいえばAWSの既存のサイト接続機能
・（インターネット経由のIPSec）Site-to-Site VPN 接続
・VPC ピアリング接続（クロスアカウントを含む）
・Direct Connect（執筆時点で予定）
を統合するGatewayサービスです。
公式ブログの図ですとこのようなイメージになります。
出典：https://aws.amazon.com/jp/blogs/aws/new-use-an-aws-transit-gateway-to-simplify-your-network-architecture/
AWS中心のサイト構成を考えた場合、数個のVPCとVPNサイトしか存在しない構成であれば既存のサービスでも十分構成と管理が可能ですが、二桁に手が届くところからかなり煩わしくなってくると思います。
AWS Transit Gatewayはこのような構成でも単一のインターワークGatewayとして機能し、簡単に構成や管理が可能なサービスとして開発されています。
ただし、一点だけ落とし穴があるようで、現時点では既存のSite-to-Site VPN 接続で可能であったAWSをハブサイトとしたAWSとオンプレミスサイトのハブアンドスポーク構成はAWS Transit Gatewayでは不可能です。別のサービスと組み合わせて使う必要があります。
その他、制限事項等のFAQはこちらです。
外部サイト：AWS Transit Gateway よくある質問
■AWS Transit Gatewayの具体的なメリットは
M個あるVPCをフルメッシュで接続し、N個のVPNサイトが各VPCにVPN接続をすることを想定してみましょう。
・既存のAWSサイト接続機能の場合・・・
⇒合計でM*(M-1)/2個のVPCピアリングとM*N本のVPN～サイト間VPN接続が必要となる。
・AWS Transit Gatewayを利用した場合・・・
⇒1つのAWS Transit GatewayとM+N個のTransit Gateway Attachmentsが必要となる。
例えば
・VPC=2=M VPNサイト=2=Nの場合
既存機能 ⇒合計で5接続の構成と管理
AWS Transit Gateway ⇒1つのAWS Transit Gatewayと4つのTransit Gateway Attachmentsの構成と管理
・VPC=5=M VPNサイト=10=Nの場合
既存機能 ⇒合計で60接続の構成と管理
AWS Transit Gateway ⇒1つのAWS Transit Gatewayと15のTransit Gateway Attachmentsの構成と管理
・VPC=10=M VPNサイト=20=Nの場合
既存機能 ⇒合計で245接続の構成と管理
AWS Transit Gateway ⇒1つのAWS Transit Gatewayと30のTransit 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」を開きます。
①Create Transit Gatewayで名前以外はデフォルトのTransit Gatewayを作成
以下未検証の情報もありますが。このような感じでしょうか。
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の完成！
②Transit Gateway AttachmentというVPCやVPN接続を統合するインターフェイスを作成
かねて用意のVPC（ここでは10.255.0.0/16、IGWは無し）にアタッチ
Transit Gateway Attachmentの一つ目が完成
※VPCルーティングテーブルの設定
きっちりとドキュメントを読まなかったせいか数十分はまりました。
Transit GatewayとVPCのルーティングテーブルは独立していますのでVPCをアタッチした後、VPCのルートテーブルで必要なルートをTransit Gatewayに向ける必要があります。
ここではデフォルトルート（0.0.0.0/0）を向けておきます。
③続いてVPNの統合
今回は既存で作成済のカスタマゲートウェイがあるので流用します。
#以下の理由よりTunnel Optionsのパラメータは隠しておりませんが、本番環境でご利用の際は空欄で設定し、AWS側がランダムで払い出す値を使用するほうが望ましいです。
#理由1 個人的にConfigはまるまるコピペしないのでパラメータが覚えやすい。
#理由2 トンネル内サブネットはルーティングテーブルに載らないので直接接続のVPNデバイスからしかリーチャビリティがなく、公開しても問題ない
#理由3 AWSが対応するISAKMPはメインモードのみのため、仮にPSKが知られたとしても第三者によるSAは事実上作成不能。
#まあ、検証が終わったらすぐに破棄するからということもあります。
Transit Gateway Attachmentが２つできました。
④Site-to-Site VPN 接続のタブを開くと新しいVPN接続ができているので設定をダウンロード
今回はCisco ISRのIOS用です。
AWS側の設定はとりあえず以上です。
■VPNデバイスの設定
ダウンロードしたConfigを確認し、VPNデバイス（今回は手元のCisco Router）に設定を流し込みます。
#ダウンロードしたコンフィグにはVPN関連のセクションしか記載していないので最低限のインターネット接続設定は事前にしておく必要があります。
#なぜか「③続いてVPNの統合です。」のスクリーンショットで設定したパラメータがTunnel1と2で逆になったものがダウンロードされます。
実用上問題ないのですが、精神上よくないので私のConfigは独自に修正しています。
##お年玉（！？）として以下より今回のConfig例がコピーできます。パラメータを確認の上、自己責任でご利用ください。
⇒アクセスはフレッツ（PPPoE）
⇒ローカル側サブネットは192.168.100.0/24
⇒VPNサイト内のクライアントからのインターネット接続は各サイトからCBAC(SPI)つきのNATでブレイクアウト
⇒VPC内のインスタンスからのインターネット接続は特定サイトからNATで接続
■VPNとBGPの疎通確認
紙面の関係で細かいところは端折りますが、うまくいくとこのようになります。
BGPによりVPNデバイス側はスタティックな設定なしで10.255.0.0/16を学習し、VPC側はスタティック設定なしで192.168.100.0/24を学習しています。
BGPネイバーとBGPルートの確認、VLAN1側から内部にPING成功
Transit Gateway route tableタブ
デフォルトルート（0.0.0.0/0）の先はBGPで0.0.0.0/0をアドバタイズしたVPNサイトとなります。
■VPCの追加
続けて別のVPC（ここでは172.16.0.0/24、IGWは無し）を追加してみましょう。
Attachmentを作成し・・・
確認！
例によってデフォルトをTransit Gatewayに向けてルートの確認
VPNネイバーは増えずにルートがアドバタイズされています。
これは便利！
■ポイントをいくつか
Ciscoルータの設定にあたり2つほどポイントを。
①IPSecのセキュリティパラメータはDLしたものをそのまま使わない！
DLできるファイルのセキュリティパラメータはやや古いシステムとの互換性を考えており、ベースライン（許容される下限ギリギリ）のパラメータとなっています。許容範囲内という考え方もありますが、今後パラメータ部分がコピペで長く使用された場合、急な危殆化に対応できないリスクが残るため変更を強く推奨いたします。
紙面の都合でここでは詳細を解説できませんが、トラフィックを暗号化する共通鍵を共有するためのDiffie-Hellman key exchange（DH）のbit長が短い場合、鍵交換のトラフィックをキャプチャして共通鍵を推測される可能性、つまりVPNトラフィックを事後に解読されるリスクが高まります。よって特にDH Groupの値はGroup14（2048bit）への変更が必須と考えらえれます。
外部サイト：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が高速なフェイルオーバーを可能とする。BFD（Bidirectional Forwarding Detection）をサポートしているか確認してみました。
この結果を見ると残念ながらサポートされていないようです・・・
※BFDとは
外部サイト：BFD概説（AX7800R・AX7700Rソフトウェアマニュアル解説書 Vol.1）
いかがでしたでしょうか。
このようにAWS Transit GatewayをBGPと組み合わせて利用するとクラウドのトポロジーをスケーラブルかつフレキシブルに構成することが可能となります。
ではまた、次回のエントリーでお会いしましょう。
Hiroki Sekihara CRISC, CISSP, CEH, PMP, CCIE #14607
-
有益な情報が
メルマガ登録
ほしい
