ネットワークの「ぶっちゃけトラブル」はICMPの叫び声に耳を澄ませばすべて解決する：到達不能とPMTUDの深層
おい、調子はどうだい？ APIのレスポンスが突如としてタイムアウトしたり、特定のクライアントからだけ「ファイルが途中でフリーズする」なんていう悪夢のような障害に直面した夜はないかい？
モダンなWebアプリケーションの開発やインフラ運用に携わっていると、どうしてもHTTPステータスコードやJSONのペイロード、あるいはアプリケーションログばかりに目がいきがちだ。だが、ちょっと待ってほしい。その下層、つまりOSI参照モデルの第3層（ネットワーク層）で、パケットたちが一体どんな悲鳴を上げているのか、君は耳を傾けたことがあるかい？
今回は、ネットワークのトラブルシューティングにおいて「縁の下の力持ち」でありながら、時に「厄介者の誤解」を受けがちな ICMP（Internet Control Message Protocol）、特にその核心である 「到達不能通知（Destination Unreachable）」 と 「MTUパス探索（PMTUD: Path MTU Discovery）」 について、現場の泥臭い知見を交えながら徹底的に紐解いていこう。
—
1. なぜL3のICMPがL4や上位層のエンジニアにとって重要なのか？
TCP/IPモデルやOSI参照モデルの教科書を開くと、L3は「ルーティングとアドレッシング」、L4は「信頼性のある通信（TCP）や高速性（UDP）」と綺麗に住み分けられている。だが、実際のインターネットや巨大なクラウド環境（AWSのVPCやKubernetesのPodネットワークなど）は、そんなお行儀の良い世界ではない。
TCPは「コネクション型」であり、パケットが相手に届いたかどうかをシーケンス番号とACKで確認する。しかし、パケットが途中のルーターで捨てられたとき、送信元のTCPスタックがそれを知る術は基本的にタイムアウトを待つことだけだ。もし、途中のルーターが「おい、そこから先には進めないぞ」「大きすぎてこの回線じゃ運べないぞ」と即座に教えてくれなかったら？ 私たちのアプリケーションは、無駄な再送を繰り返し、タイムアウトの泥沼に足を取られることになる。
ここで登場するのが ICMP だ。ICMPは「エラー通知のメッセンジャー」である。IPパケット自体には、エラーが発生したときに送信元へ引き返す仕組み（コネクション概念）がない。そのため、ルーターはパケットを破棄した際、そのお詫びと理由を添えて、送信元IPアドレス宛てにICMPパケットを投げ返す。
Web APIの設計やインフラ運用を行う我々にとって、ICMPは単なる「pingコマンドで生存確認するためのプロトコル」ではない。「上流のネットワークで何が起きているのかを正確に検知するための重要なしらせ」 なのだ。
—
2. ICMP Destination Unreachable（到達不能）のメカニズムと解析
ルーターがパケットを転送できずに破棄するとき、その理由に応じて Type と Code が設定された Destination Unreachable メッセージが送信元に送られる。
RFC 792 や後続の仕様で定められているが、特に実務で頻繁に遭遇する重要なコードをいくつかピックアップしておこう。
| Type | Code | 名称 (Description) | 現場でのリアルな意味と原因 |
| :— | :— | :— | :— |
| 3 | 0 | Network Unreachable (ネットワーク到達不能) | ルーティングテーブルに宛先ネットワークへの経路が存在しない。BGPの設定ミスやルーティングループの疑い。 |
| 3 | 1 | Host Unreachable (ホスト到達不能) | 最終宛先のホストまでルーターは到達したが、ARP解決に失敗したか、直結ネットワーク上にホストが存在しない。 |
| 3 | 3 | Port Unreachable (ポート到達不能) | 宛先IPには届いたが、指定されたUDPポートやTCPポートで待ち受けているプロセスがない。（ポートスキャンの基本原理） |
| 3 | 4 | Fragmentation Needed and DF was Set (フラグメンテーション必要だがDFフラグが立っている) | 後述するPMTUDの要。 パケットサイズが大きすぎるが、分割禁止フラグがあるため破棄したという通知。 |
パケットキャプチャ（Wireshark）の視点
もし君が tcpdump や Wireshark でこのパケットを捕らえたなら、ICMPパケットのペイロード（データ部）に注目してほしい。
ICMPのエラーメッセージの中には、「エラーを引き起こした元のIPヘッダーと、そのデータムの最初の8バイト」 がそっくりそのまま含まれている。
つまり、ルーターは単に「エラーだよ」と言っているだけでなく、「お前がさっき送った、この宛先のこのパケットが原因で進めなかったんだよ」という証拠物件を突きつけているのだ。これを利用しない手はない。デバッグ時には、ICMPペイロード内の宛先ポートやシーケンス番号を確認し、どのリクエストが拒絶されたのかを特定する手がかりにする。
—
3. MTUパス探索（PMTUD）の闇とICMPブラックホール問題
さて、ここからが本題だ。インフラエンジニアが最も頭を抱え、WebフロントエンドやAPIの開発者が「なぜか特定の環境だけPOSTリクエストがハングする」という謎の不具合に直面する原因、それが PMTUD（Path MTU Discovery）の失敗 だ。
PMTUDの基本フロー
インターネット上のすべてのルーターが同じ最大転送サイズ（MTU: Maximum Transmission Unit）を持っているわけではない。標準的なイーサネットは1500バイトだが、PPPoE環境やVPNトンネル（IPsecやGRE、VXLANなど）を経由すると、カプセル化のオーバーヘッドによってMTUは1450バイトや1400バイトに縮小する。
1. クライアントは MTU 1500バイトのつもりで、IPヘッダーに DFフラグ（Don’t Fragment: 分割禁止フラグ） を立てた大きなパケットを送信する。
2. 途中の「MTUが小さいルーター（例: 1400バイト）」にぶつかる。
3. ルーターはパケットを分割（フラグメンテーション）しようとするが、DFフラグが立っているため分割できない。
4. ルーターはパケットを破棄し、送信元へ ICMP Type 3 Code 4 (Fragmentation Needed) を返す。この時、そのルーターが持つ「許容する最大MTU値（Next-Hop MTU）」のヒントをメッセージ内に含める。
5. 送信元のOSやTCPスタックはこれを受け取り、送信するセグメントサイズを小さく調整して再送する。
現場で起きる最悪のシナリオ：ICMPブラックホール
しかし、世の中のセキュリティ担当者やネットワーク管理者は、往々にして過剰なセキュリティ対策を施す。
「DDoS攻撃やスキャンを防ぐため」という名目で、ファイアウォールで すべてのICMPパケットをインバウンド遮断（Drop） している現場が後を絶たない。
ここで何が起きるか？
送信元から送られた巨大なパケットは途中の狭いルーターで破棄される。ルーターは親切に ICMP Type 3 Code 4 を送ろうとするが、手前のファイアウォールにブロックされ、送信元には一切届かない。
送信元のTCPスタックは「ICMPが来ない＝パケットは順調に届いているはずだ」と思い込み、同じサイズのパケットを延々と再送し続ける。結果として、通信が完全にスタック（フリーズ）する。これが ICMPブラックホール問題 だ。
—
4. 実務で役立つデバッグ手順とコード例
この手のネットワーク起因の不具合に直面したとき、アプリケーションのコードをいくら修正しても1ミリも解決しない。ここでは、現場で使える具体的な調査・回避策を紹介しよう。
① 端末からの確認と手動MTUテスト (curl / ping)
まずは、自分の環境から宛先サーバーへのパスMTUが正しく機能しているか、あるいはICMPがブロックされていないかを確かめる。
Linux環境であれば、ping コマンドでDFフラグを立てたパケットサイズを指定して飛ばすことができる。
# サイズ1472バイト（IPヘッダー20 + ICMPヘッダー8 = 1500バイト）のパケットをDFフラグ付き(-M do)で送信
ping -M do -s 1472 <宛先のIPアドレス>
# もし途中にMTU 1400の区間があり、ICMPが返ってくる環境なら以下のようなエラーが出る
# ping: local error: message too long, mtu=1400もしこのコマンドを実行して、何も返ってこずにタイムアウトする場合は、途中でICMPが完全にドロップされている（ICMPブラックホールの罠にハマっている） 可能性が極めて高い。
② Python / Requests でのタイムアウト・接続テスト時の注意点
APIクライアントを実装する際、ネットワーク層のトラブルによってコネクションがハングアップするのを防ぐため、必ずタイムアウト値を明示的に設定することが鉄則だ。
import requests
from requests.exceptions import Timeout, RequestException
url = "https://api.example.com/v1/data"
try:
# 接続タイムアウト(3秒)、読み込みタイムアウト(5秒)を厳格に設定する
# PMTUD失敗によるハングアップを検知できるようにするため
response = requests.post(
url,
json={"payload": "large_data_chunk"},
timeout=(3.0, 5.0)
)
response.raise_for_status()
print(f"成功: {response.status_code}")
except Timeout:
print("【警告】ネットワークタイムアウトが発生しました。パケットサイズやPMTUD、ICMPブロックの可能性があります。")
except RequestException as e:
print(f"通信エラー: {e}")③ 根本的な対策：MSSクラピング（MSS Clamping）の設定
アプリケーション側やクライアントの環境をコントロールできない場合（例えば、不特定多数がアクセスするWeb APIサーバーを運用している場合）、サーバー側のルーターやロードバランサー（あるいはLinuxカーネル自体）で対策を行う必要がある。
最も効果的で現実的な解決策が MSSクラピング（MSS Clamping） だ。これは、TCPの三次ハンドシェイク（SYNパケット）が行われる際に、ルーターがパケット内の MSS（Maximum Segment Size） の値を強制的に書き換え、最初から小さなパケットサイズで通信させる手法である。
Linuxルーターやパケット転送サーバー（iptables / nftables）を使っている場合、以下のようにしてMSSを強制的に制限できる。
# iptablesを用いて、ルーティング時にTCPのMSSを1360バイトに強制書き換えする（PPPoEやVPNトンネル対策の定番）
sudo iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360*※上記の設定により、TCPセグメントの最大サイズが制限されるため、そもそも巨大なパケットが生成されず、PMTUDの失敗やICMPブラックホールの影響を華麗にかわすことができる。*
—
5. シニアからの教訓：見えないパケットを見る目を養え
ネットワークの世界では、「目に見えないもの」を想像する力がエンジニアの腕前を決める。
アプリケーション層のログやブラウザの開発者ツール（DevTools）は、あくまでOSIモデルの最上位、いわば「氷山の一角」を見せているに過ぎない。その下では、何千何万というL3パケットが、ルーターとの間で「大きすぎる」「通れない」「到達不能だ」という無数の会話（ICMPメッセージ）を繰り広げているのだ。
もし次に「原因不明の通信途絶」や「特定の環境でのみ起きるタイムアウト」に遭遇したら、すぐにコードを書き換える手を止めてほしい。
tcpdump を立ち上げ、ICMPパケットが途中でドロップしていないか、PMTUDが正しく機能しているかをパケットキャプチャの生データから読み解いてみるんだ。
その泥臭いアプローチこそが、最短で障害を根絶やしにする最強のスキルなのだから。
コメント