現場の黒魔術：Path MTU Discoveryと「死のパケット」を巡る戦い
深夜のNOCで、ある不可解な事象に頭を抱えた経験はないだろうか。「特定のサイトだけがロードされない」「SSH接続は確立するのに、コマンドを打った瞬間にフリーズする」。パケットキャプチャを覗けば、SYNパケットは往復しているのに、TLSハンドシェイクの途中で沈黙するあの現象だ。
原因は十中八九、MTUの不一致だ。今日は、教科書には載っていない、現場の泥臭いPath MTU Discovery（PMTUD）の制御と、それがなぜ「モダンな高負荷環境」で死活問題になるのかを深掘りする。
—
1. なぜ「フラグメンテーション」は悪なのか
IPヘッダーには DF (Don’t Fragment) フラグが存在する。これを立てたパケットは、経路上のルーターが「MTUを超過している」と判断した瞬間、断片化されることなく破棄され、送信元に ICMP Destination Unreachable (Fragmentation Needed) が返送される。
これが正常に機能していれば良い。だが、現代のネットワークにおいて、このICMPがフィルタリングされているケースは珍しくない。結果、パケットは「ブラックホール」に飲み込まれ、TCPハンドシェイク後の大きなデータフレームが消滅する。これが、接続が半分だけ成功して、通信が成立しない理由だ。
2. 現場の武器：pingによる実効MTUの探査
エンジニアが真っ先に叩くべきは、論理的な推論ではなく、CLIから放つ「弾」だ。ping コマンドでDFフラグを立て、サイズを徐々に大きくして送り込む。この作業を「手動バイナリサーチ」と呼ぶ。
Linux環境であれば、以下のコマンドが基本となる。
# -M do: DFフラグをセット
# -s: ペイロードサイズを指定 (ICMPヘッダー8バイト + IPヘッダー20バイトを差し引く必要がある)
# 1472 + 28 = 1500 (イーサネットの標準MTU)
ping -M do -s 1472 192.168.1.1もし Frag needed and DF set が返ってくるなら、その経路にはそれ以下のMTUを持つボトルネックが存在する。ここからサイズを 1460, 1450, 1440 と下げ、成功する最大値を探る。VPNトンネル（IPsec/GRE/VXLAN）を跨ぐ構成では、オーバーヘッド分だけ確実にMTUは削られることを忘れてはならない。
3. TLSハンドシェイクとTCPバッファの「見えざる壁」
PMTUDの失敗は、単にWebページが見られないという話に留まらない。TLS 1.3のハンドシェイクにおいて、証明書チェインが巨大化すると、パケットサイズは1500バイトを優に超える。
ここでPMTUDが機能していないと、最初の ClientHello は通っても、サーバーからの Certificate メッセージが到達せず、接続がタイムアウトする。現代のインフラアーキテクトが考慮すべきは、以下のカーネルパラメータによる「防御的チューニング」だ。
# TCP MSS (Maximum Segment Size) をMTUベースで強制的に固定する
# サーバー側でパケットサイズを抑え込み、未知の経路トラブルを回避する
sysctl -w net.ipv4.tcp_mtu_probing=1
# 1: 必要な時だけプロービングを行う
# 2: 常にプロービングを行う（高負荷環境で推奨）tcp_mtu_probing を有効にすると、カーネルは自律的に最適なMSSを推定し始める。これはパケットロスが発生した際に、MTUを下げて再送を試みるという、まさに現場の知恵が詰まった挙動だ。
4. セキュリティとパフォーマンスのトレードオフ
MTUの最適化は、単なる接続性の確保ではない。RTT（Round Trip Time）削減の観点からは、可能な限り1パケットに詰め込むのが正義だが、大きすぎれば断片化のリスクが増大する。
特に、MSS Clamping をルーター側で強制的に適用する場合、注意が必要だ。
# iptablesによるMSSクランプの例
# TCPパケットのSYN/SYN-ACKのMSSオプションを強制的に書き換える
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360この数値は、VXLANなどを用いるデータセンター環境では 1450 程度に設定することが多いが、厳密には「使用するカプセル化プロトコル」と「インフラの帯域」を照らし合わせて算出する必要がある。適当な数値を設定すると、パフォーマンスが著しく低下する。
結論：ネットワークは「生き物」である
教科書的なMTU 1500という数字は、あくまで平時の理想だ。クラウド環境、複雑なオーバーレイネットワーク、そして世界中のISPが混在するインターネットにおいて、パケットは常に「断片化されるか、破棄されるか」の瀬戸際にいる。
トラブルシューティングの現場で最も重要なのは、ping や traceroute を単に実行することではない。「パケットがどのヘッダーを背負い、どのゲートウェイで拒絶されているのか」を脳内で可視化することだ。
君たちが設計するインフラが、どんな過酷なネットワーク環境下でもパケットを運びきれるよう、この「MTUの深淵」を常に意識しておいてほしい。ネットワークは、いつだって技術者の想像力に試練を与えてくるのだから。
コメント