しばたです。
現在AWS Transit Gateway環境におけるNetwork ACL(以後NACL)の動作について調べており、その挙動については以下のドキュメントでTransit Gatewayの関連付けを専用のサブネットにする場合とそうでない場合について書かれています。
ただ、残念ながら記載の文章を見ても正直よくわかりませんでした...
(翻訳の問題ではなく英語の原文で読んでも謎の文章にしか思えずでした)
このため簡単な検証環境を作ってVPC Reachability Analyzerを併用しつつ実際に動作確認をすることにしました。
公開後の更新について
記事を公開した後に検証環境でVPC CIDRがRFC 1918外の範囲だったことに気が付いたため、環境を作り直して検証をやりなおしています。(結果については最初に公開したときと同じです)最初に公開した内容と環境面の記述が若干異なっていますのでご承知おきください。
検証環境について
私の検証用AWSアカウントの東京リージョンに2つのVPC(10.0.0.0/16, 10.20.0.0/16)とTransit Gatewayを新規に用意してVPC同士を疎通可能にしました。
検証用でシンプルな構成で構わないため、
- デフォルトルートテーブルの関連付け
- デフォルトルートテーブル伝播
はどちらも有効にしています。
1. Transit Gatewayの関連付けを専用のサブネットにする場合
まずはAWSの推奨構成である「Transit Gatewayの関連付けを専用のサブネットにする」場合を検証します。
ドキュメントでは
EC2 インスタンスのサブネットに対して、次のようにネットワーク ACL ルールが適用されています。
・アウトバウンドルールでは、送信先 IP アドレスを使用して、インスタンスから Transit Gateway へのトラフィックを評価します。
・インバウンドルールでは、送信元 IP アドレスを使用して、Transit Gateway からインスタンスへのトラフィックを評価します。
および
Transit Gateway のサブネットに対して、次のように NACL ルールが適用されています。
・アウトバウンドルールでは、送信先 IP アドレスを使用して、Transit Gateway からインスタンスへのトラフィックを評価します。
・アウトバウンドルールは、インスタンスから Transit Gateway へのトラフィックの評価には使用されません。
・インバウンドルールでは、送信元 IP アドレスを使用して、インスタンスから Transit Gateway へのトラフィックを評価します。
・インバウンドルールは、Transit Gateway からインスタンスへのトラフィックの評価には使用されません。
という記述がなされています。
各サブネットに紐づくNACLを中心にした文章のため初見では非常に分かりにくいですが、動作確認しながら読み直すと割と直感的に理解できると思います。
1-1. 構成図
構成図は以下となります。
左側のVPC(10.0.0.0/16)に2つのサブネットを用意しそれぞれEC2インスタンス用(10.0.21.0/24)、Transit Gateway用(10.0.31.0/24)としています。
各サブネットには別のNACLを紐づけすべての通信を許可する設定としています。
EC2-01(10.0.21.65)と右のVPCにある宛先EC2(10.20.143.33)における通信を分析・検証します。
なお、便宜上EC2-01から宛先EC2の向きを「上り方向」、その逆方向を「下り方向」としています。
パケットの行き・戻りとは別ですのでご注意ください。
1-2. VPC Reachability Analyzer (上り方向)
上り方向となるEC2-01(10.0.21.65)から宛先EC2(10.20.143.33)への通信を分析した結果は以下の様になりました。
(EC2-01からTransit Gatewayに到達するまでを記載)
構成図に記載の通りルートテーブルの設定上はTransit Gatewayに直接向かう様な設定をしますが、実際の通信はTransit Gatewayによって生成されたENI(ENI-TGW)向かう通信を行います。
EC2-01にアタッチされたENI(ENI-01)から出た通信はサブネットを超えてENI-TGWへ向かうため、
- NACL-01に対するアウトバウンド通信
- NACL-TGWに対するインバウンド通信
の順で評価されます。
ENI-TGWに到達した後はTransit Gatewayのサービス(Transit Gatewayアタッチメント)へ向かうため「NACL-TGWに対するアウトバウンド通信」は評価されませんでした。
1-3. VPC Reachability Analyzer (下り方向)
Transit Gateway環境ではリバースパスを表示できないため、宛先EC2(10.20.143.33)からEC2-01(10.0.21.65)への通信を分析した結果を下り方向として扱います。
結果は以下の通りです。
(Transit GatewayからEC2-01までを記載)
ENI-TGWから出た通信はEC2-01(ENI-01)へ向かいサブネットを超えた通信をするため、
- NACL-TGWに対するアウトバウンド通信
- NACL-01に対するインバウンド通信
の順で評価されます。
1-4. 結果まとめ
結果をまとめると、この場合は単純に2つのサブネットにまたがる通信を行う時と同様に考えて大丈夫なことがわかります。
作図の都合上ENI-TGWからTransit Gatewayへサブネットを超える様な形になっていますが、実際にはここでNACLは評価されません。
改めてドキュメントの記述と付け合わせると
EC2 インスタンスのサブネットに対して、次のようにネットワーク ACL ルールが適用されています。
・アウトバウンドルールでは、送信先 IP アドレスを使用して、インスタンスから Transit Gateway へのトラフィックを評価します。
は「上り方向の通信においてEC2サブネットを出るとき」の評価を指しており、
・インバウンドルールでは、送信元 IP アドレスを使用して、Transit Gateway からインスタンスへのトラフィックを評価します。
は「下り方向の通信においてEC2サブネットに入るとき」の評価を指していました。
続けて、
Transit Gateway のサブネットに対して、次のように NACL ルールが適用されています。
・アウトバウンドルールでは、送信先 IP アドレスを使用して、Transit Gateway からインスタンスへのトラフィックを評価します。
は「下り方向の通信においてTransit Gatewayサブネットから出るとき」の評価を指しており、
・アウトバウンドルールは、インスタンスから Transit Gateway へのトラフィックの評価には使用されません。
は「ENI-TGWからTransit Gatewayアタッチメントへの通信は評価しない」ことを指している模様です。
・インバウンドルールでは、送信元 IP アドレスを使用して、インスタンスから Transit Gateway へのトラフィックを評価します。
は「上り方向の通信においてTransit Gatewayサブネットに入るとき」の評価を指しており、
・インバウンドルールは、Transit Gateway からインスタンスへのトラフィックの評価には使用されません。
は「Transit GatewayアタッチメントからENI-TGWへの通信は評価しない」ことの様です。
2. Transit Gatewayの関連付けを専用のサブネットにしない場合
次に「Transit Gatewayの関連付けを専用のサブネットにしない」場合を検証します。
技術的には可能な構成ですがAWSとしては非推奨なのでご注意ください。
こちらの場合、ドキュメントでは
インスタンスから Transit Gateway へのトラフィックに対して、次のように NACL ルールが適用されています。
・アウトバウンドルールでは、評価に送信先 IP アドレスを使用します。
・インバウンドルールでは、評価に送信元 IP アドレスを使用します。
および
Transit Gateway からインスタンスへのトラフィックに対して、次のように NACL ルールが適用されています。
・アウトバウンドルールは評価されません。
・インバウンドルールは評価されません。
という記述がなされています。
同一サブネット内の通信においてNACLが評価されないのは以前の記事で書きましたが、それとも異なるかなり謎な内容となっています。
2-1. 構成図
構成図は以下となります。
左のVPCにあるTransit Gateway用サブネット(10.0.31.0/24)に別の検証用EC2-11(10.0.31.212)を用意し、右のVPCにある宛先EC2(10.20.143.33)に対する通信を分析・検証します。
併せてルートテーブルの設定も見直し宛先EC2への疎通ができる様に設定変更しています。
こちらも便宜上EC2-11から宛先EC2の向きを「上り方向」、その逆方向を「下り方向」としています。
2-2. VPC Reachability Analyzer (上り方向)
上り方向となるEC2-11(10.0.31.212)から宛先EC2(10.20.143.33)への通信を分析した結果は以下の様になりました。
(EC2-11からTransit Gatewayに到達するまでを記載)
こちらはかなり変わった結果となり、内部的には同一サブネット内のENI-11からENI-TGWへの通信なのですが
- NACL-TGWに対するアウトバウンド通信
- NACL-TGWに対するインバウンド通信
の順でNACLが評価され、一度サブネットを出てまた戻る様な挙動になっています。
NACL-TGWの設定を変えたところ実際の通信にも影響があったためReachability Analyzerが間違えてるというわけではない様です。
2-3. VPC Reachability Analyzer (下り方向)
Transit Gateway環境ではリバースパスを表示できないため、宛先EC2(10.20.143.33)からEC2-11(10.0.31.212)への通信を分析した結果を下り方向として扱います。
結果は以下の通りです。
(Transit GatewayからEC2-11までを記載)
こちらにおいてNACLは一切評価されませんでした。
2-4. 結果まとめ
結果をまとめると下図の様になります。
上り方向の通信はNACLがインバウンド・アウトバウンド両方評価され、下り方向の通信はNACLが一切評価されない結果になりました。
こちらもドキュメントの記述と付け合わせると
インスタンスから Transit Gateway へのトラフィックに対して、次のように NACL ルールが適用されています。
・アウトバウンドルールでは、評価に送信先 IP アドレスを使用します。
・インバウンドルールでは、評価に送信元 IP アドレスを使用します。
は上り方向の通信に対する挙動と一致し、
Transit Gateway からインスタンスへのトラフィックに対して、次のように NACL ルールが適用されています。
・アウトバウンドルールは評価されません。
・インバウンドルールは評価されません。
は下り方向の通信に対する挙動と一致しました。
確かにドキュメント通りです。
2-5. 推測
何故この結果になるのかわからなかったので社内で質問してみたところ「(上り方向の通信に対して)宛先IPがサブネット外のアドレスであるため、サブネットに紐づくルートテーブルに従い一旦VPCルーターにルーティングされているのでは？」という回答を得ました。
この回答に対して裏取りできませんでしたが、物理ネットワークであればごく自然な話であるため私としては非常に納得できました。
これなら下り方向の通信についても「(ENI-TGWから見た)宛先が同一サブネットであるためNACLが評価されない」理由が説明できます。
もちろん物理ネットワークとVPCは違いますし上記の内容についてきちんと裏取りも出来ていません。
とはいえ実際の挙動を説明するにはとても都合が良いので、私としてはこの内容を推していきたいです。
補足 : NACL設定のベストプラクティスについて
最後に改めてAWSのベストプラクティスについて触れておくと、
- 各 Transit Gateway VPC アタッチメントに個別のサブネットを使用します
- Transit Gateway サブネットに関連付けられているインバウンドおよびアウトバウンド NACL を開いたままにします
- トラフィックフローに応じて、ワークロードサブネットに NACL を適用できます
とされており、今回の例で言えば
- Transit Gatewayの関連付けを専用のサブネットにすること
- Transit GatewayサブネットのNACL(
NACL-TGW)は全ての通信を許可すること - 必要に応じてEC2サブネットのNACL(
NACL-01)を設定すること
となります。
本記事をここまで読んだ後であれば「直感的な挙動を期待できる」＋「考慮すべき箇所を増やし過ぎない」という点においてこのベストプラクティスに従うべきであることが理解できると思います。
最後に
以上となります。
AWS公式ドキュメントの内容が分からなかったので何気なく調べはじめたのですが、かなり頭を悩ませる結果となりました。
仕様理解のしやすさという点においてもAWS Transit Gatewayを構築する際はベストプラクティスに沿った構成にすることを強くお勧めします。
4
