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

関連するソリューション

ID-Cross/クラウドサービス

サイバー・セキュリティ・ソリューション（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例がコピーできます。パラメータを確認の上、自己責任でご利用ください。

! service timestamps debug datetime msec localtime show-timezone year service timestamps log datetime msec localtime show-timezone year service password-encryption service sequence-numbers ! hostname AWS-TEST ! !本ConfigではCon 0以外からルータのCLIに入れないが必要に応じて特権パスワードを設定 enable secret hogehoge ! no aaa new-model clock timezone jst 9 0 ! ip dhcp excluded-address 192.168.100.1 192.168.100.99 ! ip dhcp pool VLAN1-SUBNET network 192.168.100.0 255.255.255.0 default-router 192.168.100.1 dns-server 192.168.100.1 ! ip name-server 8.8.8.8 ip inspect name CBAC tcp ip inspect name CBAC udp ip inspect name CBAC icmp ip cef ! !本番環境では「Key」以下ののパラメータはAWSにより払い出されたものか十分に長くランダムな値を使用のこと crypto keyring KEY-1 local-address <<VPNサイトのグローバルIPアドレス>> pre-shared-key address <<トンネル1のIPSecエンドポイントIPアドレス>> key hogehoge1 crypto keyring KEY-2 local-address <<VPNサイトのグローバルIPアドレス>> pre-shared-key address <<トンネル2のIPSecエンドポイントIPアドレス>> key hogehoge2 ! crypto isakmp policy 10 encr aes 256 hash sha256 authentication pre-share group 14 crypto isakmp keepalive 10 10 crypto isakmp profile ID-PROFILE-1 keyring KEY-1 match identity address <<トンネル1のIPSecエンドポイントIPアドレス>> 255.255.255.255 local-address <<VPNサイトのグローバルIPアドレス>> crypto isakmp profile ID-PROFILE-2 keyring KEY-2 match identity address <<トンネル2のIPSecエンドポイントIPアドレス>> 255.255.255.255 local-address <<VPNサイトのグローバルIPアドレス>> ! crypto ipsec security-association replay window-size 128 ! crypto ipsec transform-set IDSET esp-aes 256 esp-sha256-hmac mode tunnel crypto ipsec df-bit clear ! crypto ipsec profile ID-TUNNEL set transform-set IDSET set pfs group14 ! !本番環境では Tunnel1のIPアドレスはAWSにより払い出された値を使用のこと interface Tunnel1 ip address 169.254.100.2 255.255.255.252 !「ip nat inside」はVPCのトラフィックをNAT経由でインターネットにルーティングする拠点のみ設定 ip nat inside ip virtual-reassembly in tunnel source <<VPNサイトのグローバルIPアドレス>> tunnel mode ipsec ipv4 tunnel destination <<トンネル1のIPSecエンドポイントIPアドレス>> tunnel protection ipsec profile ID-TUNNEL ! !本番環境では Tunnel2のIPアドレスはAWSにより払い出された値を使用のこと interface Tunnel2 ip address 169.254.200.2 255.255.255.252 !「ip nat inside」はVPCのトラフィックをNAT経由でインターネットにルーティングする拠点のみ設定 ip nat inside ip virtual-reassembly in tunnel source <<VPNサイトのグローバルIPアドレス>> tunnel mode ipsec ipv4 tunnel destination <<トンネル2のIPSecエンドポイントIPアドレス>> tunnel protection ipsec profile ID-TUNNEL ! interface GigabitEthernet8 no ip address duplex auto speed auto pppoe enable group global pppoe-client dial-pool-number 1 !Cisco891F使用のためSVI（interface Vlan1）はデフォルトでG0～7とブリッジング済 !他機種では物理インターフェイス等に設定 interface Vlan1 ip address 192.168.100.1 255.255.255.0 ip nat inside ip virtual-reassembly in interface Dialer1 mtu 1454 ip address negotiated ip access-group IPSEC in ip nat outside ip inspect CBAC out ip virtual-reassembly in encapsulation ppp ip tcp adjust-mss 1414 dialer pool 1 dialer-group 1 ppp authentication chap callin ppp chap hostname <<フレッツ接続のユーザ名>> ppp chap password <<フレッツ接続のパスワード>> ! !BGPのASNはVPCのカスターマーゲートウェイもしくはダウンロードしたConfigファイルで確認 !本番環境ではAWSにより払い出されたASNを使用のこと router bgp [ASN] bgp log-neighbor-changes neighbor 169.254.100.1 remote-as 64512 neighbor 169.254.100.1 timers 10 30 30 neighbor 169.254.200.1 remote-as 64512 neighbor 169.254.200.1 timers 10 30 30 ! address-family ipv4 network 192.168.100.0 !「network 0.0.0.0」はデフォルトルートをアドバタイズしたい拠点のみ設定 network 0.0.0.0 neighbor 169.254.100.1 activate neighbor 169.254.100.1 soft-reconfiguration inbound neighbor 169.254.200.1 activate neighbor 169.254.200.1 soft-reconfiguration inbound exit-address-family ! no ip http server no ip http secure-server ! ip dns server ip nat inside source list 1 interface Dialer1 overload ip route 0.0.0.0 0.0.0.0 Dialer1 ! !「ip access-list extended IPSEC」の許可範囲を限定できる場合はできる限り限定する ip access-list extended IPSEC permit esp any any permit udp any eq isakmp any eq isakmp permit udp any eq non500-isakmp any eq non500-isakmp permit udp host 8.8.8.8 eq domain any permit icmp any any permit udp any eq ntp any eq ntp ! dialer-list 1 protocol ip permit access-list 1 permit 192.168.100.0 0.0.0.255 !「access-list 1」の以下の行はVPCのトラフィックをNAT経由でインターネットにルーティングする拠点のみ設定 !追加するサブネットは本例の場合 access-list 1 permit 10.0.0.0 0.255.255.255 access-list 1 permit 172.16.0.0 0.0.255.255 ! no vstack ! line con 0 exec-timeout 0 0 logging synchronous no modem enable line vty 0 4 login transport input none ! ntp server ntp.jst.mfeed.ad.jp ! end

⇒アクセスはフレッツ（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

当サイトの内容、テキスト、画像等の転載・転記・使用する場合は問い合わせよりご連絡下さい。

エバンジェリストによるコラムやセミナー情報、
IDグループからのお知らせなどをメルマガでお届けしています。