パケットの「断末魔」を聞き逃すな：MTU不整合とDFフラグが引き起こす悪夢
ネットワークエンジニアとして数え切れないほどの夜を徹してきましたが、最も厄介な敵は、決まって「見えない壁」です。疎通はしているのに、特定のデータサイズを超えた瞬間にパケットが蒸発する。そんな現象に直面したとき、多くのエンジニアは焦ってパケットキャプチャを仕掛けますが、まずは手元の ping を使いこなすことが最短ルートです。
今日は、MTU（Maximum Transmission Unit）という物理的な制約と、IPヘッダーに潜む DF（Don’t Fragment）フラグが織りなす「パケット消失のメカニズム」について、現場の知見を交えて深掘りします。
—
1. なぜ「巨大なパケット」は届かないのか
ネットワークの道中には、イーサネットの標準である1500バイトという「関所」があります。VPNトンネルやクラウド上のオーバーレイネットワークを経由すると、ヘッダーの分だけ実効的なペイロードサイズが削られ、1500バイトのパケットは門前払いされます。
ここで登場するのが DF フラグです。これを確認用パケットにセットすることで、「分割するな、断れ」という強い意志をルーターに伝え、経路上の最大MTUを暴き出すことができます。
pingによる実効MTUの特定（Linux編）
Linux環境では、ping コマンドに -M do オプションを付けることで DF フラグを強制的に立てられます。また、-s でペイロードサイズを指定します。
# 1472バイト指定 + 28バイト(IPヘッダー20 + ICMPヘッダー8) = 1500バイト
# -M do は DFフラグをセットし、断片化を禁止するオプション
ping -M do -s 1472 192.168.1.1もし、途中のルーターのMTUが1400であれば、このコマンドは Frag needed and DF set というエラーを吐き出します。これがネットワークエンジニアにとっての「黄金のシグナル」です。ルーターが「お前の荷物は大きすぎる」と正直に白状した瞬間だからです。
—
2. 実務で遭遇する「サイレント・パケットロス」の正体
Web APIを叩いたとき、GET リクエストは通るのに、ペイロードを含む POST や、大きなレスポンスが返ってくる通信だけがハングアップする。そんな状況は、Path MTU Discovery (PMTUD) が途中のファイアウォールでブロックされているケースがほとんどです。
PythonによるMTUを意識した通信テスト
アプリケーション層でも、MTUを意識した設計は不可欠です。以下は、Socketを使用して自身のMTU制約を考慮しつつ、コネクションを検証する際の概念的なアプローチです。
import socket
def check_socket_path():
# ソケットを作成
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
# 実際にはOSのMTU設定に依存しますが、TCPのMSS(Maximum Segment Size)を
# 意識した通信を行うためのフラグ設定例
# IP_MTU_DISCOVER を使用して、接続先へのMTUを自動検出させる設定
s.setsockopt(socket.IPPROTO_IP, socket.IP_MTU_DISCOVER, 1)
try:
s.connect(("api.example.com", 443))
print("通信経路のMTU制約内で接続が確立されました")
except socket.error as e:
# ここで「Message too long」等のエラーが拾えれば、MTU不整合の証拠
print(f"接続失敗: {e}")
finally:
s.close()—
3. なぜ断片化（Fragmentation）を避けるべきなのか
「断片化すれば送れるのでは？」という声が聞こえてきそうですが、それは現代のインフラでは「悪手」です。
- CPU負荷: ルーターがパケットを分割する処理は極めて重く、パフォーマンスが劇的に低下します。
- 再構築エラー: 途中のノードで断片の一つでも欠落すれば、IPスタックは受信した他の断片をすべて破棄します。
- セキュリティ: 断片化を悪用したIDS/IPS回避攻撃（Tiny Fragment Attack）の標的になりやすいため、多くのセキュリティ機器は断片化されたパケットをドロップします。
現場での教訓として、「断片化はトラブルの温床。MTUの不整合は、断片化で解決するのではなく、経路のMTUを合わせるか、MSSクランプで解決せよ」と若手には伝えています。
—
4. シニアエンジニアからの実務的アドバイス
トラブルシューティングの現場では、以下のステップをルーチン化してください。
1. ping による境界調査: -s の値を1472から徐々に下げていき、どこで通るようになるかを確認する。
2. MSSクランプの設定: ルーターやロードバランサーで、TCPの MSS を1400程度に強制的に書き換える（ip tcp adjust-mss 等）。これが、MTU問題を物理作業なしで解決する最強の「魔法」です。
3. Path MTU Discoveryの確認: クライアントOSの sysctl 設定で net.ipv4.ip_no_pmtu_disc が誤って無効化されていないか確認する。
ネットワークは「目に見えない」からこそ、パケットが運ぶ断片的な情報を論理的に組み立てる想像力が不可欠です。ping の戻り値一つ一つに、ネットワーク機器が発する「悲鳴」を聞く余裕を持てれば、あなたも立派なインフラエンジニアです。
次回の障害対応では、ぜひ DF フラグと共にパケットの深淵を覗いてみてください。答えは必ず、そのパケットのヘッダーの中にあります。
コメント