ゲートウェイルートテーブルのターゲットにトランジットゲートウェイを指定してみる(エラーになる)

Transit Gateway と VPC Ingress Routing をいい感じに組み合わせられないか?と思って試行して、組み合わせられないことがわかったいう記事です。

コンバンハ、千葉(幸)です。

以前にこんな取り組みをしました。

ゲートウェイルートテーブルにおいて、ターゲットには ENIのみ が指定できます。ユースケースを考えるとEC2インスタンスにアタッチされているENI以外を指定することは考えられないのですが、それを承知の上で各種ENIをターゲットにしてみるという試みです。エラーが出たり出なかったりという結果でした。

前回の試みで試していないENIの種類はいくらでもあるのですが、その中の一つにTransit Gatewayが生成するENIがあります。ちょっと毛色が違うしもしかしたら行けるのではないか?と懲りずに試してみるのが今回のテーマです。

目次

やりたいこと

Transit Gatewayでアタッチメントを作成し、VPC(およびサブネット)に関連付ける際に、対象のサブネットにはENIが生成されます。そこを指定してゲートウェイルートテーブルにルートを追加できた場合、VPC Ingress Routingを噛ませていろいろこねくり回したルーティングができるのではないかと考えました。

できると何が嬉しいのか?

特に思いつきません。

試した結果

結果を踏まえてどう思うか?

下手に登録できるとややこしいことになるので、むしろ良かったと思っています。

試したことに後悔はありません。

結果に至るまでの工程

Transit Gatewayが生成したENIは以下です。セキュリティグループはアタッチできず、送信元/送信先チェックはFALSEになっています。

特に理由はないのですが、Route53 リゾルバのインバウンドエンドポイントによって作成されたENIもあったため、こちらも試してみます。セキュリティグループがアタッチできて、送信元/送信先チェックはTRUEです。

送信元/送信先チェックにおさらいしておくと、以下のようなパラメータです。ゲートウェイルートテーブル絡みで考えると、VPC Ingress Routingで本来の宛先IPとは異なる対象にルーティングすることになるため、ENIのこのパラメータがFALSEでないとそこでトラフィックは破棄されます。

[Source/Destination Check] 属性により、送信元/送信先チェックがインスタンスで有効になっているかどうかが制御されます。この属性を無効にすると、インスタンスで自身にアドレス指定されていないネットワークトラフィックを処理することが可能になります。たとえば、ネットワークアドレス変換、ルーティング、ファイアウォールなどのサービスを実行するインスタンスではこの値を disabled に設定する必要があります。デフォルト値は enabled です。
送信元または送信先チェックの変更

インターネットゲートウェイにエッジアソシエーションされたゲートウェイルートテーブルに両者のENIを登録してみます。

Transit Gatewayの方はエラーになりました。

Route table contains routes targeting unsupported network interface eni-05xxxxxxxxxxxxxxx

Route53 リゾルバの方は登録できました。何よりですね。

ターゲットへの指定可否サマリ

前回の試行の結果も踏まえてこうなりました。

# 用途 セキュリティグループ 送信元/送信先チェック ターゲット指定可否
1 CLB用 あり TRUE できた
2 ALB用 あり TRUE できた
3 NLB用 なし FALSE できなかった
4 RDS用 あり TRUE できた
5 NAT Gateway用 なし FALSE できなかった
6 未アタッチ あり FALSE(手動で変更) できた(TRUEに変えてもできた)
7 インタフェース型VPCエンドポイント あり TRUE できなかった
8 Transit Gateway用 なし FALSE できなかった
9 Route53リゾルバエンドポイント あり TRUE できた

送信元/送信先チェックがなまじFALSEのものはターゲットに登録できるとややこしいので登録の段階で弾く、という傾向かなと想像しました。繰り返しになりますが、EC2インスタンス以外のENIを指定しても意味はありません。

終わりに

皆さんもお気に入りのENIを見つけて、ターゲットに登録してみてくださいね!