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

AWS Transit Gatewayの裏側を覗く：UDP 4789（VXLAN）が生み出すオーバーレイネットワークの泥臭い真実

こんにちは、SREチームのシニアエンジニアです。

クラウドのインフラ設計をしていると、VPCピアリングの数が増えすぎてルーティングテーブルがスパゲッティ状態になり、頭を抱えた経験はないだろうか。「あっちのVPCからこっちのVPCへ繋ぎたいだけなのに、なんでこんなにルート管理が必要なんだ…」と深夜のオフィスで絶望したあなたを救うのが、AWS Transit Gateway（以下、TGW）だ。

TGWは、複数のVPCやオンプレミス環境をハブ＆スポーク型で美しく接続してくれる非常に頼もしい存在だ。しかし、このTGWの「美しさ」の裏側では、AWSの巨大な物理ネットワーク上で、パケットが激しく姿を変えて駆け巡っている。

今回は、TGWの中核を支える技術でありながら、普段は黒衣に徹している UDPポート4789番（VXLAN）によるパケットのカプセル化メカニズム について、実務の現場で役立つ知識を交えながら徹底的に解説しよう。

—

1. なぜTGWにVXLAN（UDP 4789）が必要なのか？

実務でVPC設計をしていると、「VPC AからVPC Bへパケットを投げる」という行為を非常にシンプルに捉えがちだ。しかし、AWSのマルチテナントかつ巨大な物理基盤において、ユーザーが定義したプライベートIPアドレス（10.0.0.0/16 など）が、そのまま物理ルーターの間を飛び交っているわけがない。

もしそのまま流したら、世界中のAWSユーザーのIPアドレスが重複して大惨事になるのは目に見えている。

そこで登場するのが、オーバーレイネットワーク（Overlay Network） という概念だ。

カプセル化という「魔法」の正体

TGWは、あるVPCから送られてきた通常のイーサネットフレーム（L2/L3パケット）を丸ごと別のパケットで包み込む。これが カプセル化（Encapsulation） だ。

1. ユーザーの送信元VPCから送出されたパケットを、TGWがキャプチャする。
2. そのパケットの外側に、新たなIPヘッダーとUDPヘッダーを付与する。
3. この時に使われるのが、IANA（Internet Assigned Numbers Authority）でVXLAN用に正式に標準化された UDPポート4789番 だ。
4. AWSの物理基盤（アンダーレイネットワーク）は、このUDPパケットを通常のルーティングで宛先TGWまで高速に運ぶ。
5. 宛先側のTGWに到達したら、外側のヘッダーを剥ぎ取る（非カプセル化 / Decapsulation）。
6. 中から取り出された元のパケットが、宛先のVPCへと届けられる。

この一連の仕組みにより、ユーザーはAWSの物理的なトポロジを意識することなく、安全かつ柔軟にVPC間通信を行えるのだ。

—

2. パケットが駆け抜ける通信フロー（シーケンス）

では、VPC AのEC2インスタンスから、TGWを介してVPC BのEC2インスタンスへHTTPリクエスト（APIコールなど）を投げる際の、パケットの具体的な変遷を見てみよう。

[VPC A: EC2 (10.1.0.10)] 
       │
       ▼ (通常のL3パケット送信)
[VPC A: ネットワーキング (TGWアタッチメント)]
       │
       ▼ 【カプセル化】 外側にUDP 4789ヘッダーを付与
[AWS 物理基盤 (アンダーレイ)] ── (高速転送) ──> [AWS 物理基盤 (アンダーレイ)]
                                                       │
                                                       ▼ 【非カプセル化】 UDP 4789を剥がす
                                              [VPC B: ネットワーキング (TGWアタッチメント)]
                                                       │
                                                       ▼ 
                                              [VPC B: EC2 (10.2.0.20)]

このフローの中で、パケットのヘッダーは以下のように劇的な変化を遂げている。

この仕組みを知っていれば、「なぜTGWを跨ぐ通信でMTUの考慮が必要なのか」「なぜセキュリティグループやNACLでUDP 4789を意識する必要があるのか（基本はAWSがマネージドで隠蔽しているが）」という疑問の答えが自ずと見えてくるはずだ。

—

3. 現場で役立つ！MTUとフラグメンテーションの罠

SREとしてインフラを構築していて、最も遭遇しやすいトラブルの一つが 「MTU（Maximum Transmission Unit）問題」 だ。

TGWを介した通信では、カプセル化によってパケットのサイズが大きくなる。
通常のイーサネットの標準MTUは 1500バイト だが、VXLANヘッダーや外側IPヘッダーが付与されることで、オーバーヘッド（通常50バイト程度）が発生する。

もしVPC内のEC2から 1500バイト ぴったりのパケットを送り出すと、TGWでカプセル化された瞬間に物理ネットワークの制限（通常はジャンボフレーム等が使われるため耐えられることが多いが、VPNやDirect Connectを絡めると話が変わる）を超過し、パケットロスや断続的な通信断を引き起こす。

対策：Path MTU Discovery (PMTUD) と MSSクラッピング

実務では、以下のいずれかの対策を講じるのが定石だ。

1. VPCのDHCPオプションセットでMTUを適切に設定する（Direct ConnectやVPNを併用する場合は特に重要）。
2. ロードバランサーやアプリケーション層、あるいはルーター側でMSS（Maximum Segment Size）の調整を行う。

例えば、Linuxのネットワークインターフェースで強制的にMSSを調整するiptablesのルールを入れる場合のサンプルコードを見てみよう。インフラのトラブルシューティング時に、踏み台サーバーなどで一時的にパケットの振る舞いを確認する際にも役立つ。

# 【インフラ運用Tips】
# TGWやVPN経由でパケットが途切れる（TCPのハンドシェイクは成功するがデータ転送で固まる）場合、
# MSSクランプをかけることでパケットの断片化問題を強制的に回避できます。

sudo iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

# 設定内容の確認
sudo iptables -L FORWARD -v -n

—

4. デバッグと疎通確認の実践（パケットキャプチャの視点）

「本当に意図した通りにTGWを経由しているのか？」「パケットはちゃんとカプセル化されているのか？」
そんな疑問を持ったとき、教科書を読むだけでは解決しない。現場のエンジニアは、実際にトラフィックを観測して事実を掴む。

もし独自にカスタムルーター（VyOSやLinuxベースの仮想アプライアンス）をTGWにアタッチして検証環境を作っている場合、tcpdump を使って 4789 番ポート宛てのトラフィックをキャプチャすることで、VXLANの挙動を生々しく確認できる。

以下のコマンドは、特定のインターフェースでUDP 4789番のVXLANパケットをキャプチャし、中身のヘッダー情報を覗き見るための実用的なコマンドだ。

# 【デバッグコマンド】
# eth0インターフェースを通過するUDPポート4789（VXLAN）のパケットをキャプチャし、
# 16進数とASCIIで詳細に表示する
sudo tcpdump -i eth0 -nnvvv -X 'udp port 4789'

# 出力の見方のポイント：
# 1. 外側のIPアドレスがAWSのTGW基盤のIPになっているか
#. 2. 宛先ポートが .4789 になっているか
# 3. ペイロード部分に内側のプライベートIP(例: 10.x.x.x)が含まれているかを確認する

このような低レイヤーの観測手法を持っておくことで、AWSサポートに問い合わせる際も「どのレイヤーでパケットがドロップしているか」を論理的に切り分けて伝えることができ、障害復旧までのリードタイムを劇的に短縮できる。

—

まとめ

今回は、AWS Transit Gatewayの裏側を支える UDPポート4789番（VXLAN）によるパケットのカプセル化メカニズム について解説した。

TGWは、オーバーレイネットワーク技術（VXLAN）を使って、ユーザーのプライベートIPパケットを丸ごと包み込んでルーティングしている。
その際に使われるのが、標準プロトコルである UDPポート4789番 である。
カプセル化に伴うオーバーヘッド（MTU問題）は、クラウドネットワーク設計において常に意識すべき重要なポイントである。

クラウドがどれだけ進化し、マネージドサービスとして抽象化されようとも、その下で動いているのは紛れもないネットワークの基本原則だ。「動くから良し」とするのではなく、パケットがどのように形を変えて流れているのかを頭の中に描き出せること。それこそが、トラブルに強い真のインフラエンジニア・SREの武器となる。

日々のアーキテクチャ設計やトラブルシューティングの現場において、今回の解説が少しでもあなたの助けになれば幸いだ。