AWS Transit Gateway作業禄

概要

異なるAWSアカウント間のVPCを接続するための一つの手段としてTransit Gatewayを使った作業の手順を記載。
それぞれのアカウントで作業が必要なので、手順としての確立を行う。

詳しい手順は下記を参考にして後に作業するときのためエッセンスだけ記載しています。
https://dev.classmethod.jp/articles/transit-gateway-vpc/

ここで間違えてはいけないのは、これはひとつのVPC同士を接続する術であって、subnet同士をつないでいるわけではないこと。
結果としてそうなっているように見えるけど、そもそもVPCとSubnetの関係はルートテーブル、境界となる点、セキュリティグループで仕切られた人為的なものであることを知っておく必要がある。

手順

前提として、アカウントAとBの持つ特定のVPCを統合する、先手はアカウントBから。

① アカウントBでTransit Gatewayを作成する

特に言うことなし。

② アカウントBでAWS RAM(Resource Access Manager) で共有リクエストをアカウントAに対し発行

ここでアカウント間の承認作業が入る。

③ アカウントAで②を承認

アカウントBのTransit GatewayがアカウントAで見えるようになる。

④ アカウントAでTransit Gateway Attachmentにて結びつき(associated)を要求

VPCとsubnetを紐づけてつなぐよ？というリクエストをアカウントBに対して出す。
そりゃ勝手になんでもボコスカ紐づけて出されたら困るよね。

⑤ アカウントBでアカウントAからの④を承認

さらにアカウントBでTGW Route Tableにおいて伝播が作成されていることを確認するか作成する（うろ覚え）
ごめんなさい免責事項にも書いているけれど記憶がない。

⑥ アカウントAで対象となるsubnetのルートテーブルを操作

ルートエントリにアカウントBのsubnetのCIDRを指定し行き先をTransit Gatewayに向ける。
でなければパケットは飛んでくるけど戻り先がないという事態になる。
アカウントB側では承認かなにかの過程で自動的にsubnetのルートテーブルが作成されていたように思える。

トラブルシューティング

動作確認からのトラブルシューティングがあったので記載する。

BからAのEC2へsshをつなごうとしてつながらないため、双方のsubnetのEC2にてtcpdumpを走らせてパケットの飛び方を確認

アカウントA側での観察

SSHを受ける側

[root@ec2-a ~]# sudo /usr/sbin/tcpdump port 22
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:58:32.554904 IP ec2-B.ap-northeast-1.compute.internal.58832 > ec2-a.ap-northeast-1.compute.internal.ssh: Flags [S], seq 730932552, win 59220, options [mss 8460,nop,nop,TS val 713078031 ecr 0,nop,wscale 7], length 0
09:58:32.554950 IP ec2-a.ap-northeast-1.compute.internal.ssh > ec2-b.ap-northeast-1.compute.internal.58832: Flags [S.], seq 1076782999, ack 730932553, win 59136, options [mss 8460,nop,nop,TS val 2249751064 ecr 713078031,nop,wscale 7], length 0
09:58:32.555287 IP ec2-b.ap-northeast-1.compute.internal.58832 > ec2-a.ap-northeast-1.compute.internal.ssh: Flags [R.], seq 1, ack 1, win 59136, length 0

1. BからAへTCP Syncが飛ぶ
2. AでTCP Syncを打ち返す
3. BからTCP RSTが返ってくる

アカウントB側での観察

SSH接続を仕掛ける側。

10:02:25.106207 IP ec2-b.ap-northeast-1.compute.internal.54242 > ec2-a.ap-northeast-1.compute.internal.ssh: Flags [S], seq 106444503, win 59220, options [mss 8460,nop,nop,TS val 713310583 ecr 0,nop,wscale 7], length 0
10:02:26.122732 IP ec2-b.ap-northeast-1.compute.internal.54242 > ec2-a.ap-northeast-1.compute.internal.ssh: Flags [S], seq 106444503, win 59220, options [mss 8460,nop,nop,TS val 713311599 ecr 0,nop,wscale 7], length 0
10:02:28.142731 IP ec2-b.ap-northeast-1.compute.internal.54242 > ec2-a.ap-northeast-1.compute.internal.ssh: Flags [S], seq 106444503, win 59220, options [mss 8460,nop,nop,TS val 713313619 ecr 0,nop,wscale 7], length 0

1. BからAへTCP Syncが飛ぶ
2. Aから応答なし

これはー戻りのパケットのルートが無いかブロックされているかですね・・
というわけで⑥の作業を実施。

tcpdumpは四半世紀以上前からやってる古風な確認方法だけどいまだに有効なんだなと思ったけれど、最近のサーバレスやコンテナだとパケットの飛ぶ飛ばないの確認ができないから原理把握とログおよび直感になってしまうけど、原理を理解していることが重要だと思います。

免責事項と完走した感想

作業やったあとに思い出しながら書いているので一部間違っているかも、特に⑥あたりのTGWルートテーブルは登録されたんだか作成したんだか覚えていないけれど伝播を作成したのは覚えている。

承認周りがはさまるからCDKとかCDKTFで書きづらそうだなこれ・・

Transit Gatewayは先人たちがいっぱい記事を書いているのでそちらも参照くださいだけど、クラメソさんの説明が一番わかりやすかったです。