【テクニカル・上級編】ポート4789番(VXLAN)を利用したAWS Transit Gatewayのパケットカプセル化 – クラウド＆コンテナネットワーク実践ガイド

AWS Transit Gatewayの深淵：UDP 4789番とVXLANが織りなす「見えないネットワーク」の解剖学

クラウドアーキテクチャの設計図面を引く際、私たちは往々にして「論理的な接続性」という抽象的なレイヤーで思考を停止させがちです。しかし、VPCを跨ぎ、数千のコンテナが入り乱れるAWS Transit Gateway（TGW）の裏側では、一体何が起きているのでしょうか。

今日は、TGWの心臓部とも言える「VXLAN（Virtual Extensible LAN）」によるカプセル化、そしてその挙動を理解することで初めて到達できる、極限のパフォーマンスチューニングの世界へご案内します。

1. なぜ「UDP 4789」なのか：カプセル化の物理的リアリティ

TGWが異なるVPC間、あるいはオンプレミスとの間でパケットを転送する際、生のIPパケットをそのままルーティングしているわけではありません。内部では、元のパケットをVXLANヘッダーで包み込み、UDPのペイロードとして運ぶ「カプセル化」が行われています。

ここで登場するのが UDP/4789 です。

パケットの「二重構造」がもたらすオーバーヘッド

通常のIPパケットにVXLANヘッダー（8バイト）と外側のUDPヘッダー（8バイト）、さらに外側のIPヘッダー（20バイト）が付与されるため、最小でも50バイト前後のオーバーヘッドが発生します。

オリジナルのパケット: [Ether][IP][TCP/UDP][Data]
TGW転送時のパケット: [Outer Eth][Outer IP][Outer UDP (4789)][VXLAN Header][Inner Eth][Inner IP][Inner TCP/UDP][Data]

この構造が意味するのは、MTU（最大転送単位）問題の再燃です。TGWを経由するパスでは、標準の 1500 bytes を超えるパケットはフラグメンテーション、あるいは破棄の対象となります。これを防ぐためには、インスタンス側のインターフェースで MSS Clamping を適切に行い、オーバーヘッド分を考慮した 1450 bytes 程度への調整が不可欠です。

2. パフォーマンスのボトルネックを剥ぎ取る：TCPバッファとRTT

TGWを経由すると、当然ながらホップ数が増加し、物理的な距離（あるいは論理的なパスの遅延）が加算されます。高トラフィック環境でスループットを最大化するには、LinuxのTCPスタックを「攻め」の設定に変える必要があります。

特に、BDP（Bandwidth Delay Product）を考慮したTCPウィンドウサイズの最適化は必須です。

# /etc/sysctl.conf に記述すべき、高遅延・高帯域環境向けのチューニング例

# TCP受信ウィンドウの最小・デフォルト・最大値を設定
# 10Gbps帯域かつ低遅延の前提で、メモリを惜しまず割り当てる
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# 送受信の最大バッファサイズ
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

# TCPウィンドウ拡大オプションを有効化（必須）
net.ipv4.tcp_window_scaling = 1

# BBR輻輳制御アルゴリズムの有効化（TGW経由のパケットロスに強い）
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

BBR を選択する理由は明確です。TGWという「ブラックボックス」内部で発生する軽微なパケットロスに対し、従来の Cubic はウィンドウサイズを急激に絞りますが、BBR は帯域の「実効値」を測定し続けるため、高いスループットを維持できます。

3. セキュリティの死角：VXLANの「見えない脅威」

TGWのVXLAN通信は、AWSのインフラ層で制御されており、ユーザーが直接パケットの内容を改ざんすることはできません。しかし、我々SREが警戒すべきは、「内部ネットワークの信頼」という幻想です。

VXLANはレイヤー2をレイヤー3上でエミュレートします。もし、セキュリティグループの設計を疎かにし、VPC間で「広すぎる許可」を与えてしまうと、VXLANトンネルを介してマルウェアが横方向に拡散するリスクがあります。

対策：マイクロセグメンテーションの強制

TGWのルートテーブルだけで制御するのではなく、各VPCのセキュリティグループにおいて、「最小特権の原則」を適用してください。

0.0.0.0/0 を許可するルールは論外です。
相互接続が必要なマイクロサービス間では、特定の Security Group ID を指定した参照ルールを作成し、物理的なパスを意識させない論理的な境界を構築してください。

4. 総括：クラウドネットワークを「制御」するということ

TGWの UDP/4789 は、単なるポート番号ではありません。それは、クラウドという巨大なインフラの上に構築された「あなた専用の論理網」への入り口です。

私たちがやるべきことは、単にコンソールをポチポチと操作することではなく、パケットがどのようにカプセル化され、どの程度の遅延を抱え、どのようにOSのバッファで処理されているかを想像することです。

インフラアーキテクトとして、この「見えないオーバーレイ」を可視化し、適切なチューニングを施すこと。それこそが、堅牢で高パフォーマンスなシステムの屋台骨を支える、唯一無二の技術力なのです。

次回の記事では、VPC Traffic Mirroring を活用して、このVXLANパケットをキャプチャし、実際に中身を解剖する手順について深掘りしたいと思います。現場からは以上です。