【テクニカル・上級編】 pingによるMTUパス探索とDon’t Fragment(DF)フラグの制御 – トラブルシューティング＆ネットワーク運用監視実践ガイド

ブラックホールの正体を見極めろ：DFビットとMTU探索が明かすネットワークの深淵

ネットワークエンジニアの現場において、最もタチが悪く、かつ美しいトラブルの一つが「PMTUD（Path MTU Discovery）の失敗」だ。

ある日突然、SSHは通るのにgit cloneが途中で固まる。あるいは、小さなHTTPリクエストは正常なのに、大きなPOSTデータやTLSハンドシェイクの後半がタイムアウトする。この現象に遭遇したとき、多くの若手はまずファイアウォールのログを疑うが、百戦錬磨の我々は直感的に悟る。「ああ、またどこかのルーターが、大きすぎるパケットを『断片化禁止（DF）』フラグのせいで黙殺しているな」と。

今日は、教科書的な説明は抜きにして、パケットレベルで何が起きているのか、そしてなぜ我々がpingのDFビット操作に命を懸けるのかを紐解いていく。

なぜ「断片化」は現代のネットワークで悪手なのか

まず大前提として、IPレベルでの断片化（Fragmentation）は、現代の高性能なデータセンターにおいては「避けられるべき災厄」だ。

中継ルーターがCPUでパケットを分割するコスト、そして受信側ホストがバラバラになった断片を再構築する際のメモリ負荷。これらはスループットを劇的に低下させる。何より、多くのステートフルファイアウォールやIDS/IPSは、断片化されたパケットの整合性を検査できず、セキュリティ上の脆弱性を生む。

だからこそ、我々はあえてパケットにDF（Don’t Fragment）ビットを立てる。これにより、「分割するくらいなら、ルーターで破棄してICMPの『Destination Unreachable（Type 3, Code 4：フラグメンテーションが必要だがDFがセットされている）』を返せ」と強制するわけだ。

CLIで紐解く：MTUパス探索の現場的作法

物理経路の最大MTUを特定する際、pingコマンドを単なる疎通確認ツールとして使うのは素人だ。我々は以下のように、DFビットを立て、サイズを可変させながら「境界」を突き止める。

# Linux環境でのMTU探索
# -M do: DFフラグをセットし、断片化を禁止する
# -s 1472: ペイロードサイズ（1472 + IPヘッダー20 + ICMPヘッダー8 = 1500バイト）
ping -M do -s 1472 192.168.1.1

# もし「Frag needed and DF set」が返ってきたら、サイズを少しずつ下げていく
# 1464バイトまで下げて通れば、途中にPPPoEやトンネリング（VXLAN等）が挟まっている証拠だ

ここで重要なのは、単に「通るか通らないか」を見るのではない。pingが返すエラーメッセージ、そしてパケットが通過する際のRTT（Round Trip Time）の変化を注視することだ。もしMTU境界付近でRTTが跳ね上がるなら、それはスイッチングチップのバッファリングや、ソフトウェア処理への切り替わりを示唆している。

TLSハンドシェイクとTCPバッファの相関関係

PMTUDの失敗がなぜ「TLSハンドシェイク」で顕著に出るのか。答えは簡単だ。ハンドシェイクの後半、サーバーは大量の証明書チェインをClientHelloへの応答として送り出す。これがMTUを超えると、パケットは分断される。

もし経路上のどこかでICMPの戻りが遮断（いわゆる「ICMPブラックホール」）されていると、クライアントはパケットが破棄されたことに気づけず、永遠にタイムアウトを待ち続ける。

これを防ぐには、システム全体で以下のチューニングを検討すべきだ。

1. TCP MSS Clampingの強制

ルーターやロードバランサー側で、MSS（Maximum Segment Size）を強制的に小さく設定し、OSレベルでのネゴシエーションを確実にパスさせる。

# iptablesでのMSSクランプ例（パケットのMSSを1360に強制）
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360

2. TCPバッファの最適化

MTUとMSSのバランスが取れていない状態でTCPウィンドウサイズを大きく広げると、パケットロス発生時の再送コストが跳ね上がる。net.ipv4.tcp_rmem等の値を調整する際は、必ず想定されるMTUサイズを考慮してほしい。

セキュリティと極限のパフォーマンス

MTUを意識することは、セキュリティにも直結する。MTU制限を回避するために悪意を持って断片化されたパケットを送りつける手法は、古くからある攻撃ベクトルだ。

また、パケットサイズを意図的に小さく保つことは、TLSのレコードサイズを最適化し、HTTP/2やHTTP/3（QUIC）のストリーム多重化効率を向上させることにも繋がる。特にQUICはUDPベースであり、PMTUDの挙動をアプリケーション層で制御するため、インフラ側でMTUの境界を正確に把握しておくことは、現代のネットワーク設計における生命線と言っても過言ではない。

最後に：ネットワークを「視る」ということ

トラブルシューティングにおいて、ツールはあくまで道具に過ぎない。重要なのは、パケットが物理的な光ファイバーの中を駆け抜け、カーネルのスタックを通り、アプリケーション層へ届くまでの「質感」をイメージできるかどうかだ。

pingでDFビットを立てるその一打は、単なる確認ではない。ネットワークの心臓部に触れ、その限界を定義する儀式なのだ。

障害は、常に我々の想定の外側に潜んでいる。だからこそ、教科書を閉じ、CLIを叩き、パケットの流れを自らの頭の中でシミュレーションしてほしい。それが、真のネットワーク・スペシャリストへの唯一の道だ。