NTTドコモR&Dの技術ブログです。

Transit GatewayとNACLでハマった話

はじめに

この記事はドコモR&D Advent Calendar 2024の14日目の記事です。

初めまして!NTTドコモ サービスイノベーション部 ビッグデータ基盤担当の竹鼻です。入社2年目になります。社内のビッグデータ基盤の保守運用や新機能の開発に携わる担当をしています。本記事ではAWSのサービスの勉強をしているときにハマったTransit GatewayとNACLの関係について紹介しようと思います。

1.要約

初めに結論を述べますと、Transit Gatewayを使う際にNACLを使ってアクセス制御を行う際は、NACLが評価されるタイミングが複雑なのでちゃんと評価されるタイミングを把握した上で設計を行うようにしよう!になります。この記事を読んで少しでもTransit Gatewayについて理解が深まれば幸いです。

2. Transit Gatewayとは

Transit Gateway(トランジットゲートウェイ)は、Amazon Web Services(AWS)のネットワークサービスで、複数のVPC(Virtual Private Cloud)やオンプレミスネットワークを一元的に接続するための仮想的なクラウドルータのようなものになります。これにより、複雑なネットワーク構成をシンプルに管理できるようになります。AWSでサービスを開発する際に、一つのVPCだけでサービスが完了するなら問題ないですが、大規模な開発になると複数のVPCを扱ってそれぞれのVPC毎に機能を持たせるような構成になります。その際にVPC間の接続を担うのがTransit Gatewayになります。

①VPC Peeringを使う場合

②Transit Gatewayを使う場合

VPC間の通信の方法の一つとしてVPC Peeringがあります。VPC Peeringは1対1の関係でVPC間を接続することが可能で、シンプルに設計することができます。しかし、上図のように接続するVPCが多くなると、接続の管理が複雑になるという問題があります。そのような場合にTransit Gatewayを使うことでVPC間の通信を一元的に管理することができます。

3. NACLとは

NACL(Network Access Control List)は、VPC内のサブネットに適用されるファイアウォールのようなもので、サブネット内のリソース全部に対してルールが適用されます。インバウンドのルールとアウトバウンドのルールをステートレスに設定することができます。これにより、サブネット毎に接続先や接続元の制限を行うことが可能です。今回はこのNACLを使って接続の制御を行うことを考えます。

4. Transit Gateway利用時によるNACLによるアクセス制御

4.1 構成図

今回のTransit Gatewayを利用してVPC間の通信を以下のような構成を使って実験しようと思います。左側のVPCをSourceVPC、右側のVPCをDestVPCとして、それぞれのVPCにプライベートサブネットを二つ作成します。

一つのサブネットはEC2を建て、もう一つのサブネットにはAWS公式ドキュメントのペストプラクティスを参考にTransit Gateway Attachmentを作成します。

今回はNACLを用いたアクセス制御についてみていくため、それぞれのサブネットに別々のNACLを紐付けます。またTransit Gatewayを利用する場合、VPC間の通信はTransit Gatewayを経由して行うため、SourceVPCとDestVPCのそれぞれのルートテーブルにTransit Gatewayを経由するルートを追加する必要があるため、その設定もしておきます。

4.1 NACLのアクセス制御なしの場合

上記構成において、NACLの設定について全ての通信を許可するように設定します。

この場合において、EC2間の疎通確認をしてみますと問題なく通信ができることが確認できます。

4.2 NACLによるアウトバウンドの制限の場合

では次に、NACL周りを設定していて嵌ったポイントについて紹介します。

NACLを利用してアクセス先を制御することを考えます。SourceVPCからのアクセス先を制御するために、SourceTgwaNaclにアウトバウンドのルールを設定してみます。設定は以下のように、DestVPCのCIDR(10.86.0.0/16)への通信を拒否するルールを設定します。

この構成において、EC2間の疎通確認をしてみますと、意図に反して通信ができてしまうことが確認できます。

4.3 原因

なぜ通信が可能なのかを調べるために、Reachability Analyzerを利用して通信経路を確認してみます。結果は以下になります。

Reachability Analyzerの結果から分かるように、SourceEc2から通信が始まり、SourceEc2Sgのアウトバウンド → SoueceEc2Naclのアウトバウンド → SourceTgwaNaclのインバウンドの評価を受けてTransit Gatewayに辿り着いていることがわかります。つまり、SourceTgwaNaclのアウトバウンドの評価は受けていないこということです。

このように、Transit Gateway Attachment専用のサブネットのNACLのアウトバウンドルールは無視されてしまうため、このNACLでアウトバウンドを絞っても外に通信ができてしまうという落とし穴があります。 なのでもしNACLを使ってアクセス制御を行いたい場合は、EC2の存在するSourceEc2Naclのアウトバウンドでルールを設定する必要があると言えます。

実際にSourceEc2Naclにて、DestVPCへの通信を拒否するアウトバウンドのルールを設定して確認してみますと、SourceVPC → DestVPCの通信において拒否されることが確認できます。

4.4 専用サブネットがない場合

次にTransit Gateway Attachment用の専用サブネットをしない構成についても、どのようなアクセス経路を取っているのかを確認してみたいと思います。この構成の際にReachability Analyzerを調べてみると以下のようになります。

結果を順に追っていくとNACLのアウトバウンド → ルートテーブル → NACLのインバウンド → Transit Gateway Attachmentという経路を辿っています。つまり同一のサブネットにおいて一度アウトバウンドが評価され、その後にインバウンドの評価がされてからTransit Gatewayに向かっているということになります。どうしてこのような通信経路を辿っているのか、調べたのですが詳しい解説は見つけることはできませんでした。ただ同様な検証を行なって考察をしている記事を見つけたので是非参考記事【1】を参考にしてください。

このようにTransit Gateway Attachment専用サブネットがない場合においては、直感に反したアクセス経路を辿るため、アクセス制御の面においても専用サブネットを作った方が良さそうと言えそうです。

5.まとめ

ここまで読んでいただきありがとうございました。Transit GatewayはAttachmentやAssociation、Propagation等の専用の用語も多いこともあり理解するのが大変ですが、一つ一つ触りながら試してみることで理解を深めることができました。しっかりと理解しないまま設定をすると意図しないところにアクセス許可をしてしまっていたり、接続不可の状態になってしまっていたりするので、しっかりと検証をして設定を行うのがよさそうです。この記事を読んで少しでも参考になれば幸いです。

メリークリスマス!

6.参考記事

【1】 AWS Transit Gateway環境におけるNetwork ACLの評価順について調査してみた

【2】 [図解]TGWアタッチメント専用サブネットの必要性

【3】 クロスアカウントな AWS Transit Gateway を、絵で見て(完全に)理解する。