【実務・中級編】 GTP-Uヘッダーの主要フィールド解析とTEID(Tunnel Endpoint Identifier) – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

5G/LTEの心臓部を覗く：GTP-UとTEIDが支える「トンネル」の正体

現場でネットワークトラブルに直面したとき、パケットキャプチャを眺めて「IPアドレスは正しいのに、なぜか通信が届かない」と頭を抱えたことはありませんか？ 4G/LTEや5Gの世界では、我々が普段扱うHTTPリクエストやAPIコールは、そのほとんどが「GTP-U（GPRS Tunnelling Protocol User Plane）」という特殊なカプセルの中に隠されています。

今回は、モバイル通信の屋台骨であるGTP-Uヘッダー、特にその魂とも言えるTEID（Tunnel Endpoint Identifier）に焦点を当て、エンジニアが実務で必ずぶつかる「トンネルの迷宮」を解き明かします。

—

GTP-Uとは何か？：モバイル通信の「封筒」

モバイルネットワークにおいて、スマホ（UE）から送られたパケットは、基地局（gNB/eNB）を通過した後、GTP-Uというプロトコルでカプセル化されます。これは、端末ごとの通信セッションを識別するために、キャリアのコアネットワーク内を仮想的な「トンネル」として通すためです。

GTP-Uヘッダーの構造とTEIDの役割

GTP-Uのヘッダーは、実は非常にシンプルです。しかし、この数バイトの中に、現代モバイル通信のすべてが詰まっています。

Flags: バージョンや拡張ヘッダーの有無を示す。
Message Type: ユーザーデータなら0xFFがセットされる。
TEID: ここが最重要です。 32bitの識別子で、特定のトンネルを特定します。UPF（User Plane Function）などのゲートウェイは、このTEIDを見て「どのセッションの通信か？」「次はどこへ転送すべきか？」を瞬時に判断します。

もし、このTEIDが不一致だとどうなるか？答えは簡単、パケットは行き場を失い、コアネットワークの闇に消えます。まさに「通信が通らない」という怪現象の正体です。

—

実践：WiresharkとPythonでTEIDを追跡する

インフラ運用で最も重要なのは「今、どのトンネルを通っているか」を可視化することです。例えば、scapyを使用して、特定のTEIDを持つパケットを解析するスクリプトを書いてみましょう。

from scapy.all import sniff
from scapy.contrib.gtp import GTP_U_Header

# GTP-Uパケットをキャプチャし、TEIDを抽出するシンプルなデバッガー
def process_packet(packet):
    if packet.haslayer(GTP_U_Header):
        teid = packet[GTP_U_Header].teid
        print(f"[+] 検出されたトンネル: TEID=0x{teid:08x}")
        
        # 特定のTEIDだけを監視するようなフィルタリングも可能
        if teid == 0x12345678:
            print(">>> ターゲットのトンネル通信を補足しました！")

# インターフェースを指定してキャプチャ開始
print("GTP-U解析を開始します...")
sniff(iface="eth0", filter="udp port 2152", prn=process_packet)

この2152番ポートというのは、GTP-Uが使用する標準ポートです。もし皆さんがクラウドネイティブな5Gコア（5GC）を構築しているなら、このポートがセキュリティグループやiptablesでブロックされていないか、まずはここを疑ってください。

—

Web API開発者が知っておくべき「GTP-Uの制約」

「自分はアプリ屋だから関係ない」と思っていませんか？実は、モバイル通信越しにAPIを叩く際、MTU（最大転送単位）の問題が発生することがあります。

GTP-Uヘッダーが付加される分、通常のイーサネットフレームよりもオーバーヘッドが発生します。もしAPIのレスポンスが大きく、パケットが断片化（フラグメンテーション）されると、モバイル網のノードでパケットロスを引き起こすリスクがあります。

curlでMTU問題を切り分けるTips

APIの動作検証をする際、curlでパケットサイズを調整してテストする習慣をつけると、トラブルシュートの精度が格段に上がります。

# 大きなペイロードを伴うPOSTリクエストのテスト
# --limit-rateなどで帯域を絞りつつ、パケットサイズを意識した検証を行う
curl -X POST https://api.example.com/v1/data \
     -H "Content-Type: application/json" \
     -d @large_payload.json \
     --verbose \
     --trace-ascii debug_dump.txt

debug_dump.txtに書き出された通信ログと、前述のscapyスクリプトを突き合わせれば、「どのサイズのパケットでTEIDの切り替えやドロップが発生しているか」が手に取るように分かります。

—

シニアエンジニアからのアドバイス

モバイルネットワークのトラブルシューティングにおいて最も重要なのは、「ヘッダーの中身を信じるな、現場のパケットを信じろ」ということです。

設定ファイル上のTEIDと、実際に網を流れているTEIDが、設定変更の同期ズレによって食い違うことは珍しくありません。特に5GのUPF設定をコード（IaC）で管理している場合、デプロイ後のセッション同期状況を、TEIDという「指紋」を頼りに追跡するスキルは、皆さんの市場価値を確実に高めてくれます。

ネットワークは生き物です。教科書の仕様を読み込むだけではなく、今日紹介したような泥臭いパケットの解析を通じて、その挙動を肌で感じてみてください。何か詰まったら、いつでもまた聞きに来てください。現場の苦労は、僕が一番よく知っていますから。