2026-06-02

MTU ブラックホールと断片化 PCAP 分析: PMTUD 障害、MSS 問題、および停止した TCP の発見

MTU ブラックホール、パス MTU 検出の失敗、TCP MSS の不一致、断片化、ICMP ブロックされたメッセージ、VPN トンネル、およびパケットキャプチャでの接続の停止を診断する方法。

MTU の問題は、最も混乱を招くネットワーク障害の原因となります。小さなリクエストでも機能します。 Ping は機能する可能性があります。 DNS が機能する可能性があります。 TCPが接続します。 TLSが開始される可能性があります。その後、大規模な応答が停止し、アップロードがハングし、Web サイトが部分的にロードされ、VPN トラフィックが中断され、ビットレートが高くなると RTSP/HTTP ストリームが失敗します。ユーザーは、接続が単にアップまたはダウンしているだけではないため、「MTU ブラックホール pcap」、「パス MTU 検出の失敗」、「TCP MSS 問題」、「断片化パケットキャプチャ」、「大きなパケットによる VPN の停止」などを検索します。

パケットキャプチャでは、大きなパケットが送信されているか、断片化されているか、ドロップされているか、再送信されているか、または ICMP フィードバックの欠落によってブロックされているかどうかを確認できます。ただし、キャプチャポイント、オフロード、トンネルオーバーヘッドによって表示されるパケットサイズが歪む可能性があるため、トレースは慎重に解釈する必要があります。

MTU 調査では、1 つの TCP 会話、元のタイミング、ICMP メッセージ、再送信、MSS ネゴシエーション、ストール前後の十分なパケットなど、集中的なトレースが必要になることが多いため、PCAP サージェリーがここで役立ちます。

MTU の意味

MTU は、リンク上の最大伝送単位です。イーサネットは通常 1500 バイトを使用します。 VPN、PPPoE、トンネル、オーバーレイ、クラウドネットワーキングではヘッダーが追加されるため、実効パス MTU が減少する可能性があります。

送信者がパスで伝送できるサイズを超えるパケットを送信した場合、次の 2 つのうちのいずれかが発生する必要があります。

パケットは、許可されている場合には断片化されます。
パケットはドロップされるため、送信者はより小さいパス MTU を学習する必要があります。

パス MTU 検出は、ICMP メッセージに基づいて、パケットが大きすぎることを報告します。これらの ICMP メッセージがブロックされると、送信者は消滅したパケットを送信し続ける可能性があります。それが古典的な MTU ブラックホールです。

MTU ブラックホールの症状

一般的な症状は次のとおりです。

TCP 接続は開きますが、大規模な転送が停止します。
ClientHello または ServerHello の後に HTTPS ハンドシェイクが停止します。
ログインページはロードされますが、ファイルのアップロードは失敗します。
VPN は接続しますが、一部のサイトが読み込まれません。
SSH は、大きな出力が表示されるまで機能します。
ペイロードが小さい API 呼び出しは機能しますが、ペイロードが大きい場合は失敗します。
RTSP 制御は機能しますが、メディアまたは大きなインターリーブパケットの動作が低下します。
再送信は同様のパケットサイズで繰り返されます。

重要なパターンはサイズの感度です。小さなパケットは通過します。それより大きなパケットは失敗します。

MSSネゴシエーション

TCP 最大セグメントサイズは、SYN 交換中にネゴシエートされます。

Client -> Server: SYN, MSS 1460
Server -> Client: SYN-ACK, MSS 1460

ICMP fragmentation needed

If the capture shows:

then Path MTU Discovery is working.

If the capture shows:

then an MTU black hole is plausible.

Fragmentation evidence

In a pcap, look for:

TLS handshake stalls and MTU

VPN and tunnel overhead

Capture point and offload

To avoid mistakes:

Checklist for MTU black hole PCAP analysis

Use this process:

Final diagnosis

「MTU ブラックホールと断片化 PCAP 分析: PMTUD 障害、MSS 問題、および停止した TCP の発見」を packet evidence で答える

direct answer は、analyzer label や application message だけでは原因を決められないことです。capture point と flow direction から始め、最後に成功した protocol boundary と最初に失敗した boundary を証明します。別の reviewer が根拠 packet、gap、interval を見つけ、何がその結論を反証するか分かる形にします。

path 上の capture point

client、server、proxy、load balancer、NAT、firewall を記録します。interface、場所、clock、OS、見える方向を明示します。client 側 capture は client に届いた内容を証明しますが、server が送らなかった証明ではありません。server 側もその地点の送信だけを証明します。二地点を比較する前に clock offset を補正し、flow tuple、TCP sequence、transaction ID を合わせます。

snap length、dropped packets、offload、capture filter、ring buffer、開始時間を確認します。host 上の bad checksum は offload artifact の場合があります。大きな segment は GRO/TSO の結果で、wire 上の一 packet ではないかもしれません。限られた file に packet がないだけで network loss と判断しません。

boundary を順に読む

境界	成功証拠	有効な失敗証拠
Link/IP	direction、address、route が一致	ARP/NDP 不在、ICMP、MTU、asymmetry
TCP	SYN、SYN-ACK、ACK、sequence	retransmission、RST、zero window、timeout
TLS	ClientHello、ServerHello、進行	alert、SNI/ALPN/certificate 境界
Application	完全 request と対応 response	status、gap、早期 close
User	response time または failure window	証明済み境界での stall

成功証拠のない最初の境界で止まります。TCP 未確立なら HTTP を先に診断しません。request が proxy に届き upstream にないなら、proxy またはその経路が境界です。upstream に届いて response が timeout 前にない場合、ACK と byte progress で application delay と network loss を分けます。

observation と hypothesis を分ける

observation は指し示せます。「client は特定 sequence まで送り、sender は同じ segment を三回再送し、この地点では進む ACK が見えない」。hypothesis は「path が segment を失った」です。別地点の capture や dropped records が反証する可能性があります。各 hypothesis に支持証拠と反証証拠を書きます。

retransmission や duplicate ACK は責任者を決めません。reordering、loss、capture artifact、receiver delay は似た label を生みます。direction、sequence、ACK、SACK、RTT、window、application timing を結びます。DNS/DHCP は transaction ID と attempts、HTTP は request/response、TLS は handshake direction を対応させます。

編集前に original を保全

original checksum を計算し変更しません。filter、trim、redaction は working copy に行います。input、operation、時刻、前後 packet count、output checksum、理由を記録します。timestamp rewrite や packet 削除後の copy は一部 timing や sequence 判定に使えません。

address と identifier は一貫した alias に置き換えます。判断に必要な port、direction、length は消しません。secret mapping は別に保管します。capture と export の範囲と PCAP Surgery overviewで派生 file を確認します。

公開前 QA

title と answer は同じ flow か。duration は clock と地点を示すか。最初の failure boundary は明確か。alternative explanation はあるか。一変数で再試験できるか。original は残るか。結論の範囲も示します。「この file は指定 interval の client 側挙動を証明するが server 内部処理は証明しない」。

Semrush の検証済み一般語 PCAP analyzer は製品ページだけが owner です。この技術記事に未測定 volume や KD を追加しません。

flow ledger と除外テスト

「MTU ブラックホールと断片化 PCAP 分析: PMTUD 障害、MSS 問題、および停止した TCP の発見」では方向ごとに endpoints alias、最初/最後の packet、送信・確認 bytes、reset、retransmission、request、response を記録します。同じ hostname でも source port、開始時刻、TCP initial sequence が違えば別 session です。NAT や proxy の前後 flow は関係を記録し、同じ sequence や port を期待しません。

label ではなく TCP を計算

receiver の next expected sequence を追います。payload length だけ sequence が進み、SYN と FIN も一番号を使います。高い segment 到着後の一定 Duplicate ACK は loss または reordering を支持します。SACK blocks は到着 ranges を示しますが損失場所は示しません。sender 側の retransmission が receiver 側にないなら中間 path、original が sender capture にないなら capture loss または offload を調べます。

duplicate ACK 後の fast retransmit と沈黙後の RTO を分けます。事前 RTT、advertised window、zero-window probes、burst、transfer size を比較します。overlap、spurious retransmission、flow 途中からの capture は analyzer label を変えるため、label 数をそのまま loss 数にしません。

boundary で時間を測る

request first byte、request complete、response first byte、response complete を使います。TTFB は自動的に server time ではありません。response 前の retransmission は network delay、request ACK 完了後の長い沈黙は application wait を支持します。値、unit、clock、point を書きます。

二地点では両方向の特徴的 packet を合わせ offset を推定し、各 file 内 interval を使います。clock が不確実なら range にします。成功/失敗 window は同程度の duration と load で比較します。

protocol 質問

DNS は ID、name、type、retry resolver。DHCP は同じ client identifier の Discover/Offer/Request/ACK。TLS は方向ごとの最後の handshake message と alert。HTTP は 4xx/5xx の生成者と upstream flow。TCP close は FIN/RST の sender と未 ACK bytes を確認します。

決定テストと引き渡し

競合する二 hypothesis と分離 test を選びます。反対端 capture は network loss と measurement loss、test で offload 無効化は artifact、固定 path の同一 request は intermittency、upstream log と packet boundary は application delay を検査します。実行前に期待結果を書きます。

reviewer が metadata から計算を再現し、同じ境界と制約に到達すれば合格です。original/derived checksum、filter、packet ranges、trim/redaction を渡し、owner、next action、測定可能な close 条件で終えます。