MTU/MSSの深淵：パケットの断片化が引き起こす「見えない死」と最適化の極意
ネットワークエンジニアの諸君、今日もパケットの断片化（Fragmentation）に泣かされているだろうか。
クラウドネイティブな環境やVPN越しにTLSハンドシェイクを繰り返す現代のインフラにおいて、MTU（Maximum Transmission Unit）とMSS（Maximum Segment Size）の不整合は、単なる通信速度の低下ではない。それは、システムが「繋がっているはずなのに、なぜか特定の通信だけがタイムアウトする」という、最も精神を削るトラブルの源泉だ。
今日は、教科書的な定義をなぞることはしない。カーネルのバッファからパケットの挙動、そしてセキュリティ的な観点まで、深淵に足を踏み入れてみよう。
—
1. MTUとMSSの「隠れた関係」を再定義する
まず、基礎をおさらいしておく必要がある。MTUは物理層からネットワーク層（L3）が一度に運べる最大サイズ、MSSはトランスポート層（L4）でペイロードとして運べる最大サイズだ。
関係性はシンプルに見える。
MSS = MTU - (IPヘッダー 20byte) - (TCPヘッダー 20byte)
しかし、現実はもっと狡猾だ。VPN（IPsec/GRE/VXLAN）を使用する場合、カプセル化によるオーバーヘッドが加わる。もし、経路上のどこかでMTUが1500から1400へ絞られ、かつパケットにDF（Don’t Fragment）フラグが立っていたらどうなるか。答えは明白だ。ルーターはそのパケットを破棄し、ICMPタイプ3コード4（Fragmentation Needed）を送信元へ投げ返す。
ここが運命の分かれ道だ。このICMPがファイアウォールやセキュリティポリシーで遮断されている場合、いわゆる「ブラックホールルーター問題」が発生する。TCPのハンドシェイクは小さなパケットだから成功するのに、TLSの証明書交換やデータ転送が始まった瞬間に通信がピタリと止まる。これが、現場のエンジニアを絶望させる「サイレントドロップ」の正体だ。
—
2. PMTUDが機能しない場所での「外科手術」
Path MTU Discovery (PMTUD) が機能しない環境（例：強固なセキュリティポリシー下の境界防御）では、手動でMSSをクランプ（固定）するのが唯一の解だ。
LinuxサーバーでTCPのMSSを強制的に制限する場合、iptablesやnftablesを活用するのが最も確実だ。例えば、VPN越しにMTU 1400のネットワークを通す場合、オーバーヘッドを考慮して以下のように設定する。
# 既存のパケットフィルタリングルールにMSSクランプを追加
# TCP SYNパケットのMSS値を1360 (1400 - 20 - 20) に強制書き換え
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360
# 特定のインターフェース経由の通信のみに適用する場合
iptables -t mangle -A FORWARD -o eth0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtuこの設定は、SYNパケット内のオプション値を書き換えるという荒業だが、アプリケーション層に一切の変更を強いることなく、断片化を物理的に回避できる。
—
3. パフォーマンスの境界線：TCPバッファとウィンドウサイズ
MSSを小さくしすぎると、パケット数が増大し、CPU負荷（割り込み処理）とヘッダーオーバーヘッドの両面で効率が悪化する。ここで重要になるのが、TCP Window Size と BDP（Bandwidth Delay Product）の計算だ。
RTT（Round Trip Time）が長い環境では、TCPのウィンドウサイズを動的に調整することで、スループットを最大化できる。Linuxカーネルのチューニングパラメータを確認しよう。
# sysctlでの最適化例
# 送信・受信バッファの最大値を拡張し、高帯域・高遅延環境に備える
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# TCPウィンドウの自動スケーリングを有効化
net.ipv4.tcp_window_scaling = 1これらは、パケットロスがわずかに発生するような不安定なネットワークにおいて、通信を維持するための生命線となる。
—
4. セキュリティスペシャリストとしての「締めくくり」
最後にセキュリティの視点だ。断片化パケットを悪用した攻撃（例：Fragment Overlap Attack）は過去の遺物と思われがちだが、IDS/IPSを回避するために意図的にフラグメントされたパケットを送り込む手法は今も存在する。
ゼロトラストを標榜するのであれば、「境界でのパケット再構築」は必須だ。ファイアウォールやロードバランサーのレベルで、フラグメントされたパケットを一度メモリ上で再構成し、正常なTCPストリームとして検査してから後続へ流す。このプロセスを怠れば、いかに強固なアプリケーション層の防御もバイパスされ得る。
ネットワークの最適化とセキュリティは、車の両輪だ。
MTUという物理的な制約を理解し、MSSを適切に制御し、カーネルレベルでバッファを最適化する。この泥臭いチューニングの積み重ねこそが、最高品質のインフラを作り上げる唯一の道であると断言しよう。
さあ、次は君たちの番だ。まずは tcpdump を回し、インターフェースの MTU 設定と実際のペイロードサイズを見比べてみることから始めてほしい。データは嘘をつかない。
コメント