😺

Transit Gatewayの複数のルートテーブル動作を確認してみる(1)ーstatic/dynamic routingー

2023/01/21に公開約6,200字

はじめに

Transit Gatewayを学習中、各VPCやIPsec-VPNに対して個別のルートテーブル(ingress/egress)を持たせというのがいまいちイメージが湧かず、実際に手を動かして検証してみました。

【目標】
・各VPCに対して、static routingとdynamic routingの設定方法を学ぶ
・複数のルートテーブルの設定、動作を確認する
・IPsec-VPNからのdynamic routingの設定方法を学ぶ

目次

  1. 構成概要
  2. 全体の流れ
  3. transit gatewayのstatic/dynamic routingを検証
  4. 複数ルートテーブルの動作検証 ★本記事ではここまで
  5. IPsec-VPNにてTGWへ接続し、dynamic routingを検証

構成概要

構成図

全体構成

【Branch1 VPC】
IPsec-VPN検証用のVPC。
Public SubnetにFortigate Instance、Private Subnetに Windows Server Instanceを設置。
FortigateからTransit GatewayにIPsecを張り、Private Subnet(10.1.10.0/24)のルート情報をTransit Gatewayに伝播する。

【Branch2、App1 VPC】
Transit Gateway Attachmentを各VPCにアタッチし、Transit Gatewayのルートに乗せる。

【Gateway VPC】
1つのVPCに複数のTransit Gateway Attachmentをアタッチ。
今後のGateway Load BalancerとTransit Gatewayを用いたEast-Westネットワーク検証のために分けているが、本ネットワークではBranch2, App1と同じとみなして差支えない。

ルートテーブル

ルートテーブル

・172.16.1.0/24 : TGW Left subnet on Gateway VPC
・172.16.2.0/24 : TGW Right subnet on Gateway VPC
・10.2.1.0/24 : Branch2 subnet on Branch2 VPC
・10.3.1.0/24 : App1 subnet on App1 VPC
VPCへTGWをアタッチする際、TGW専用のサブネットを作成するのがベストプラクティスです。
これは、TGWが持つルートテーブルとサブネットが持つルートテーブルが混在し意図しないルーティングをさけるためとのことです。

・172.16.10.0/24 : Private App Left subnet on Gateway VPC
・172.16.20.0/24 : Private App Right subnet on Gateway VPC
・10.2.10.0/24 : Branch2 subnet on Branch2 VPC
・10.3.10.0/24 : App1 subnet on App1 VPC
アクセス用デフォルトゲートウェイとしてIGWを設け、Gateway, Branch2, App1の各VPCへのルートはTGWのアタッチメントを宛先にします。

各VPCに設置されたPrivate APP、Windows-SV間の通信がTransit Gatewayのルート設定でどのように変わるか確認していきます。

全体の流れ

  1. Transit Gateway検証環境の準備
  2. TGWのdynamic Routeでの疎通確認
  3. TGWのStatic Routeでの疎通確認
  4. 複数ルートテーブルの動作検証 Hub and Spoke

Transit Gateway検証環境の準備

キーペアの準備

まずは、各Private APPにアクセスするためのSSH keyを作成します。

  1. EC2サービスの左ペインより、ネットワーク&セキュリティ->キーペアをクリックする
  2. キーペアの名前を適当に入力する(tokyoregion2)

検証環境の準備

githubから検証環境をcloudformationで構築していきます。

git clone https://github.com/pero0125/transitgateway0121.git

cloudformationの展開手順
network.yml -> security.yml -> branch_instance.yml -> appliance_security.yml
の順番で展開します。

TGWのdynamic Routeでの疎通確認

各Private Appへアクセス

検証環境が整ったら、各Private Appにアクセスして、検証を進めます。
tokyoregion2を保存しているフォルダに移動し、コマンドプロンプトを表示させます。

※上図のフォルダでcmdと入力し、Enterをたたくとコマンドプロンプトが立ち上がります。
 4画面用意します。

  1. EC2サービスの左ペインより、インスタンス->インスタンスをクリックする。
  2. 下図のようにインスタンスが作成されているので、各PrivateAppのチェックし、右上の接続をクリック
    ・tgw-Syslog-Left-Instance (GatewayVPCに所属)
    ・tgw-Syslog-Right-Instance (GatewayVPCに所属)
    ・tgw-Linux-Blanch2-Instance (Branch2VPCに所属)
    ・tgw-Linux-App2-Instance (App1VPCに所属)

インスタンスに接続から、SSHクライアントのコマンドをコピーする。

ssh -i "tokyoregion2.pem" ec2-user@xx.xx.xx.xx


上図のように各Private APPにアクセスします。

疎通確認

Transit Gatewayでは、デフォルトルートが存在し、各VPCのルート情報がdynamicに伝搬するように設定されています。

  1. VPCサービスの左ペインより、Transit Gateway->Transit Gatewayルートテーブルをクリック
  2. 既に一つあるルートテーブルにチェックを付け、『ルート』タブをクリック
    下図のようにルート情報のルートタイプが伝達済みとなっています。
    これがデフォルトでのAWSのBGPによるdynamic routingが有効となっている状態です。

【GatewayVPC -> Branch2への疎通確認】

【Branch2 -> App1への疎通確認】

TGWのStatic Routeでの疎通確認

新しいルートテーブルの作成

まずはデフォルトのルートテーブルから各VPCをデタッチします。

  1. デフォルトルートテーブルにチェックを付け、『関連付け』タブをクリック
  2. 各VPCにアタッチしているTGW attachmentをすべてデタッチしていきます。
  3. 右上の『Transit Gatewayルートテーブルを作成』をクリックします。
Item Value
名前タグ static_route_table
Transit Gateway ID TGW
  1. 作成したstatic_route_tableにチェックを付け、『関連付け』タブをクリック
  2. 3つのVPCのTGW attachmentを関連付けていきます。
  3. 続けて、『ルート』タブをクリック
  4. 下の『静的ルートを作成』をクリックします。各VPCのセグメント(伝播したい宛先)のルート設定を行います。
Item Value
CIDR 172.16.0.0/16
タイプ アクティブ
アタッチメントを選択 tgw-TGW-Gatewayvpc-attachment
Item Value
CIDR 10.2.0.0/16
タイプ アクティブ
アタッチメントを選択 tgw-TGW-Blanch2vpc-attachment
Item Value
CIDR 10.3.0.0/16
タイプ アクティブ
アタッチメントを選択 tgw-TGW-Applicationvpc-attachment

疎通確認

デフォルトルートテーブルと同じように各VPCへ疎通確認を実施します。
各VPCに対して、疎通確認が取れると思います。

複数ルートテーブルの動作検証 Hub and Spoke

検証図

複数のルートテーブルを用いて、Gateway VPCからBranch2 VPCおよびApp1 VPCへの疎通は可能だが、
Branch2とApp1 VPC間の疎通は不可という構成を作成していきます。

経路図


Branch2からGateway VPCのPrivateApp Rightへの通信経路
※Transit Gatewayのルーティングの仕様上、まず同じAZを優先して通るため、GatewayVPCにアタッチしている二つのTGW Attachmentを経由します。

Spokeルートテーブルの作成

  1. static_route_tableを作成した時と同様に、spoke_route_tableを作成します。
  2. Branch2とApp1 VPCをspoke_route_tableにアタッチします。

  3. static_route_tableからBranch2とApp1 VPCをデタッチします。合わせて172.16.0.0/16のスタティックルートを削除します。

疎通確認

【Branch2 -> GatewayVPCへの疎通確認】

【Branch2 -> App1への疎通確認】

※Gateway VPCまでパケットは飛んでいるので、GatewayVPC通信のみに絞るのが適切

以上、Transit Gatewayの検証でした!

続きは、IPsec-VPNにてTGWへ接続し、dynamic routingを検証 していきます。

Discussion

ログインするとコメントできます