pingの裏側を知る：MTUとフラグメンテーションが引き起こす「見えない壁」を突破する技術
ネットワークエンジニアとして現場に立っていると、決まって遭遇するのが「特定の通信だけがなぜか通らない」という摩訶不思議なトラブルだ。小規模なパケットは問題ないのに、APIのリクエストを投げた途端にタイムアウトする。あるいは、特定の環境間だけ接続が極端に遅い。
これらは大抵、MTU（Maximum Transmission Unit）の不一致と、それに起因するフラグメンテーション（断片化）が原因だ。今回は、ただの疎通確認ツールだと思われがちな ping コマンドを、現場のデバッグで「武器」に変えるための、ペイロードサイズ操作の深淵について語ろう。
—
なぜデフォルトのpingでは「本当の敵」は見えないのか
OSによって異なるが、ping のデフォルトペイロードサイズは多くの場合32バイトや56バイト程度だ。これにIPヘッダー（20バイト）とICMPヘッダー（8バイト）が加わっても、総パケットサイズは100バイトにも満たない。
しかし、実際のWeb API通信やデータベースのレプリケーションは、MTUの上限（標準的なイーサネットなら1500バイト）ギリギリまでデータを詰め込んで送る。もし経路上のどこかで、VPNトンネリングやPPPoE接続によってMTUが小さくなっていたらどうなるか？
パケットは「フラグメンテーション（分割）」されるか、あるいは DF（Don't Fragment）フラグ が立っていれば「破棄」される。この「破棄」が、ネットワークの境界で黙々と発生している時、君たちは原因を突き止めるために数時間を溶かすことになる。
実践：pingでパケットサイズを制御する
ping の -s（Linux）や -l（Windows）オプションは、ただの「大きさの調整」ではない。ネットワークの「許容範囲」を測るためのプローブだ。
Linuxでの実行例
まずは、明示的にサイズを指定して送ってみよう。
# 1472バイトのペイロードを送る（IPヘッダー20 + ICMPヘッダー8 = 1500バイト）
# -M do は「フラグメンテーションを禁止（DFフラグを立てる）」の意
ping -s 1472 -M do 192.168.1.1もしこれで Frag needed and DF set というエラーが返ってきたら、その経路にはMTU 1500を通せない「狭い門」が存在する。これがトラブルシューティングのスタート地点だ。
Windowsでの実行例
Windowsの場合は -l オプションを使用する。
# 1472バイトのペイロードを送信
ping -f -l 1472 192.168.1.1
# -f は DFフラグを立てるオプションMTUパス探索をコードで再現する
インフラの現場では、GUIツールに頼らず、Python等で自動化したスクリプトを走らせることが多い。特定のAPIエンドポイントに対して、どのサイズまでなら到達できるかを自動で探索するスニペットを置いておく。
import subprocess
def check_mtu(target_ip, start_size=1400, end_size=1500):
# 1バイトずつサイズを増やして疎通を確認する
for size in range(start_size, end_size + 1):
# Linux環境を想定。-M doでDFフラグを立て、タイムアウトを短く設定
cmd = ["ping", "-c", "1", "-W", "1", "-s", str(size), "-M", "do", target_ip]
result = subprocess.run(cmd, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
if result.returncode != 0:
print(f"MTU上限検知: {size + 28} バイトでパケットがドロップしました")
return size + 28
print("MTUは1500バイトまで正常です")
return 1500
# APIサーバーに対して実行
check_mtu("10.0.0.5")開発者が知っておくべき「その先」の挙動
Web API設計に携わるエンジニア諸君に警告しておきたい。ping が通るからといって、アプリケーション通信（TCP）が通るとは限らない。
1. ICMPの遮断: セキュリティポリシーにより、ICMP自体がファイアウォールでブロックされているケースが非常に多い。この場合、ping は全く役に立たない。
2. TCP MSS Clamping: TCP通信では、3ウェイハンドシェイク時に MSS（Maximum Segment Size） を交換し、双方のMTUを調整する仕組みがある。しかし、途中のルーターがこのパケットを書き換えられない（あるいは無視する）場合、MTU不一致が顕在化する。
もし ping でMTUの問題が疑われるなら、curl で詳細なヘッダーを確認することも併用しよう。
# HTTPのやり取りでフラグメントの問題を調べるならこれ
curl -Iv http://example.com/api/v1/resource最後に：シニアエンジニアからの助言
トラブルシューティングにおいて最も重要なのは、「なぜ？」を突き詰める姿勢だ。ping のサイズを変えてパケットが通らなくなったとき、それは単なるエラーではなく、「ネットワークが君に、許容量の限界を教えてくれている瞬間」なのだ。
教科書通りのコマンドを叩くのは誰でもできる。重要なのは、そのコマンドが吐き出す結果の裏側で、パケットがどのルーターで止められ、どのフラグが原因で破棄されたのかを想像できるかどうかだ。
ネットワークの世界は奥が深い。だが、パケットの気持ちになって考えれば、必ず答えは見つかる。頑張ってくれ。
コメント