【入門編】オーバーレイネットワーク（VXLAN）におけるUDPポート4789番を用いたカプセル化とパケット構造 – クラウドインフラと仮想化ネットワーク実践ガイド

こんにちは！クラウドインフラの世界へようこそ。第一線でSREとしてインフラの奔流に向き合っている私ですが、日々のシステム運用を見ていると、ネットワークの仕組みというのは本当に奥深いものだなと改めて感じさせられます。

AWSやGCPといったメガクラウドの裏側、そしてKubernetesが織りなすコンテナネットワークの海を渡るとき、私たちは常に目に見えない「見えないトンネル」をぐんぐん進んでいます。そのトンネルの正体こそが、今回フォーカスする「オーバーレイネットワーク（VXLAN）」です。

「なんだか名前からして難しそう……」と思ったそこのあなた、どうぞご安心ください！今回は、パケットたちがどのようにして海を渡り、私たちの手元まで届いているのかを、身近な例えを交えながら一緒に一歩ずつ紐解いていきましょう！

—

1. そもそも「オーバーレイネットワーク」ってなに？（現実世界でお引越しに例えてみよう）

現代のクラウドやコンテナの世界では、何千、何万もの仮想サーバーやコンテナが縦横無尽に通信しています。ここで想像してみてください。会社の中だけで通用する「内線電話（レイ2のMACアドレス）」を、全く別の拠点にあるサーバーへそのまま届けるにはどうしたらいいでしょうか？

実は、インターネットやクラウドの基盤（L3ネットワーク）は、世界共通の「郵便番号と住所（IPアドレス）」を頼りに手紙を運ぶ仕組みになっています。内線番号だけが書かれた手紙をそのまま放り投げても、宛先迷子になってしまいますよね。

そこで登場するのが、「封筒の中に封筒をもう一重入れる」というアテクシたちの秘技、カプセル化（トンネリング）です！

郵便配達の仕組みに例えてみよう

1. 中身の手紙（元々のパケット）:
「営業部の佐藤さんへ」という宛先（MACアドレス）が書かれた元々の手紙です。
2. 外側の封筒（VXLANの仕組み）:
この内側の手紙をそのまま、頑丈な新しい封筒に入れます。そして、その外側の封筒には、現実世界の正確な住所である「クラウドの物理IPアドレス」を大きく書き込みます。
3. 郵便配達員（VXLANルーター / トンネル終端）:
配達員は外側の住所（IPアドレス）だけを見て、目的地（別の物理サーバー）のポストへ猛ダッシュで届けます。
4. 開封の儀:
届け先のポストに着いたら、外側の封筒をビリビリと破り捨て、中から元の「佐藤さん宛ての手紙」を取り出して、無事に宛先へ渡します。

この「現実世界のIPネットワーク（下敷き）」という道路の上に、全く別の仮想的なネットワーク（上敷き）を重ねて構築する技術を、私たちはオーバーレイネットワークと呼んでいるんです。

—

2. パケットたちの「暗号」：UDP 4789番とVNIの正体

このカプセル化の魔法を実現する代表的なプロトコルが VXLAN（Virtual eXtensible LAN） です。
「どうやって外側の封筒であることを見分けるの？」という疑問が湧いてきますよね。ここで鍵を握るのが、お馴染みの UDPポート「4789番」 と VNI（VXLAN Network Identifier） です。

郵便の「仕分けスタンプ」としてのUDP 4789番

ネットワークの世界には、Webを見るときに使う 80番 や 443番、安全な遠隔操作に使う 22番 など、おなじみの「ドアの番号（ポート番号）」がありますよね。
VXLANでは、標準規格として UDPポートの 4789番 が割り当てられています。

受信側の物理サーバーにパケットが届いたとき、OSのネットワークスタックはこう考えます。
> 「おっ、宛先ポートが 4789 だぞ！これはただのWebアクセスやDNSの問い合わせじゃないな。カプセル化されたVXLANのパケットだ！中身を取り出して、中の仮想ネットワークにバトンタッチしよう！」

この 4789番 は、いわば「このパケットはカプセル封筒ですよ」と一目で分かる専用の仕分けスタンプなのです。

VNI（VXLAN Network Identifier）ってなに？

一つの物理的なネットワーク道路（下敷き）の上には、複数のテナントや部署（開発環境、本番環境など）が相乗りすることがあります。
ここで、「誰の荷物なのか」を区別しないと、隣の部署の荷物が自分のところに届いてしまう大惨事になりますよね。

そこで外側の封筒の中、UDPヘッダーのすぐ近くに、VNI（VXLAN Network Identifier） という「24ビットの識別番号（ID）」がポンと書き込まれます。

VNIが 100 なら、開発環境チームの荷物！
VNIが 200 なら、本番環境チームの荷物！

このように、何百万通りもの仮想ネットワークを、ひとつの巨大なIPネットワーク上で綺麗に色分けして安全に相乗りさせることができるのです。

—

3. 実務で見る！Kubernetesやクラウドでの設定イメージ

ここまで聞くと、「なんだか裏側で複雑なことが起きているのは分かったけれど、実務ではどう設定するの？」気になりますよね。
例えば、Linuxのカーネル機能（iproute2）を使って、手動でVXLANのトンネルを直に掘る場合のコマンド設定を見てみましょう。実務の現場では、KubernetesのCiliumやCalico、あるいはAWSのVPC内部などで自動的に裏でこれが組み立てられています。

LinuxカーネルでVXLANトンネルを召喚する設定例

以下のコマンド群は、手元のLinuxマシンで仮想的なVXLANインターフェース（vxlan0）を爆誕させ、外側のネットワークと結びつける手順です。

#!/bin/bash
# 【ステップ1】VXLANデバイスを新規作成する
# vni 100    : 仮想ネットワーク識別子を「100番」に指定します
# dev eth0   : 外側の通信（現実世界の道路）に使う物理インターフェースを指定します
# dstport 4789: 例のUDPポート「4789番」を明示的に指定します
sudo ip link add name vxlan0 type vxlan \
    id 100 \
    dev eth0 \
    dstport 4789 \
    remote 192.168.10.20

# 【ステップ2】作成したVXLANインターフェースにIPアドレスを付与する
# この仮想空間内でのIPアドレスを設定します
sudo ip addr add 10.0.0.1/24 dev vxlan0

# 【ステップ3】仮想インターフェースのスイッチをONにする（起動）
sudo ip link set dev vxlan0 up

echo "VXLANトンネルの構築が完了しました！UDP 4789番でパケットが飛び交います。"

このように、コマンド一発、あるいはクラウドのコントロールパネル上のポチポチ操作（またはKubernetesのマニフェスト記述）の裏側で、カーネルはこの 4789番 と VNI を駆使して、見えないパケットの梱包作業を毎秒何百万回もこなしているのです。

—

4. トラブルシューティングの現場から：なぜVXLANを知っておく必要があるのか？

「理論は分かったけど、SREとしてこれがどう現場で役立つの？」と思われるかもしれませんが、ここからが本番です。
クラウドやKubernetesで「Pod間通信が突然タイムアウトする」「パケットが途中で消える」という不可解な障害に直面したとき、ネットワークエンジニアの武器になるのはまさにこの基礎知識です。

よくある現場の罠：MTU（パケットの最大サイズ）問題

VXLANでパケットをカプセル化すると、通常のIPパケットの外側に、さらにVXLANヘッダーやUDPヘッダー、IPヘッダーが丸ごと追加（オーバーヘッド）されます。大体 50バイト 前後の「追加の封筒の重さ」が乗っかるわけです。

もし、インターネット上の標準的な最大サイズ（MTU = 1500バイト）いっぱいいっぱいのデータを詰め込んで送信すると、カプセル化された瞬間にサイズが 1550バイト に膨れ上がってしまいます。
途中のルーターが「うわっ、デカすぎてうちの道路（MTU）に入りきらないよ！」とパケットを捨ててしまい（断片化拒否）、通信がパッタリと途絶える……というのが、クラウドインフラで非常によくある「あるあるトラブル」です。

トラブルシューティングの一手

そんなときは、パケットキャプチャツール（tcpdump など）を起動して、犯人を特定します。

# 外側の物理インターフェース（eth0）で、UDP 4789番のパケットが流れているかを監視する
sudo tcpdump -i eth0 -nnvv 'udp port 4789'

コンソール画面に、次々とカプセル化されたパケットが流れていくのを確認できます。もしここでパケットが途切れていたり、巨大なパケットが破棄されている兆候があれば、仮想ネットワーク側のMTU値（例: 1450 や 1350 など、少し小さめに調整する設定）を見直すことで、嘘のようにトラブルが解決していきます。

—

まとめ

いかがでしたでしょうか？
一見すると難解な「オーバーレイネットワーク」や「VXLANのUDP 4789番」、「VNI」という専門用語も、「手紙を別の封筒に入れて、専用のスタンプを押し、宛先を色分けして運ぶ仕組み」という現実世界のルールに置き換えてみると、ぐっと身近に感じられたのではないでしょうか。

クラウドのインフラやKubernetesの底力は、こうした泥臭いパケットの工夫と、先人たちの知恵の積み重ねで成り立っています。
「あ、今この瞬間も、自分のパケットがUDP 4789番の封筒に包まれて海を渡っているんだな」――そんな風に頭の片隅でイメージできるようになると、インフラストラクチャを触る仕事がもっともっと楽しく、エキサイティングになりますよ！

それでは、また次の技術の海でお会いしましょう。SREライフを一緒に楽しんでいきましょう！