なぜ「大きな荷物」は届かないのか？ネットワークの「袋詰めルール」を解き明かす
こんにちは！ネットワークの世界へようこそ。
インフラエンジニアとして現場に立っていると、「特定のサイトだけなぜか繋がらない」「大きなファイルをアップロードしようとすると固まる」といった、いわゆる「怪奇現象」に遭遇することがあります。ログを見てもエラーは出ていない……そんな時、犯人は大抵「MTUとMSSの不整合」という、ネットワーク界のちょっとした交通ルール違反に隠れています。
今日は、パケットがネットワークという道路を駆け抜ける姿を想像しながら、この「袋詰めルール」を一緒に紐解いていきましょう。
—
1. 郵便配達で例える「MTU」と「MSS」
ネットワーク上のデータは、バラバラの「パケット」という小包に分けられて目的地に届きます。このとき、避けて通れないのが「一度に運べる荷物のサイズ制限」です。
MTU（Maximum Transmission Unit）＝ 道路の高さ制限
道路にはトンネルがありますよね。どんなに大きな荷物でも、トンネルの高さ制限（MTU）を超えていたら通り抜けることはできません。標準的なイーサネットでは、この制限は 1500 bytes と決まっています。
MSS（Maximum Segment Size）＝ 段ボール箱のサイズ
一方で、中身のデータ（TCPセグメント）を包む「段ボール箱」が MSS です。
「トンネル（MTU）を通れるように、段ボール（MSS）はこれくらいのサイズに詰めようね」という約束事です。
もし、この段ボール（MSS）がトンネル（MTU）に対して大きすぎるとどうなるでしょう？
途中のトンネルで「高さ制限を超えています！」と突き返されてしまい、データが目的地に届かない……これが通信断絶の正体です。
—
2. パスMTUディスカバリー（PMTUD）：賢い配達員の話
「じゃあ、最初から小さい箱で送ればいいじゃないか！」と思うかもしれません。でも、ネットワークは広大で、ルートによってトンネルの高さはバラバラです。
そこで登場するのがパスMTUディスカバリー（PMTUD）です。
これは、パケットに「これ以上のサイズに分割しちゃダメだよ（DFビット：Don’t Fragment）」という付箋を貼って送り出す仕組みです。
もし途中で狭いトンネルにぶつかると、ルーターは「ごめん、ここを通すには大きすぎるよ！」と送信元にメッセージを返します。これを受け取った送信元は「了解、次はもう少し小さくするね」と学習します。これがPMTUDの賢いところです。
—
3. なぜ通信が「死ぬ」のか？
しかし、現実はそう甘くありません。世の中には、セキュリティのために「ルーターからの『大きすぎるよ！』という返事（ICMPパケット）」をブロックしているファイアウォールがたくさんあります。
返事が届かない送信元は、「無事に届いているはずだ！」と思い込み、巨大な荷物を送り続けては拒否される……という終わりのないループに陥ります。これが、一部の通信だけが繋がらない「ブラックホール問題」です。
—
4. 解決策：MSSクランプ（MSS値を強制的に絞る）
このトラブルを現場でスマートに解決する手法が「MSSクランプ」です。
ルーターを通過する通信に対し、「箱のサイズ（MSS）を強制的に小さく書き換えて通行許可を出す」という強引ですが確実な手法です。
例えば、VPNなどのオーバーヘッド（追加データ）が発生する環境では、標準の 1500 よりも小さい値に設定するのが鉄則です。
LinuxルーターやCisco機器での設定例
現場でよく使われる設定のヒントを置いておきますね。
【Linux (iptables) での例】
TCPの接続開始時（SYNパケット）に、MSS 値を 1360 に強制書き換えする設定です。
# TCP SYNパケットのMSS値を1360に固定する（VPN越えなどで有効）
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360【Ciscoルーターでの例】
インターフェース設定の中で値を調整します。
interface GigabitEthernet0/0
! インターフェースを通過するTCPのMSS値を強制的に1360に調整
ip tcp adjust-mss 1360—
最後に：ネットワークは「思いやり」でできている
いかがでしたか？
MTU と MSS の関係は、まさに「送り手」と「道路の環境」との間のコミュニケーションです。
もし現場で「特定の通信だけが遅い、あるいは繋がらない」というトラブルに出会ったら、まずは「どこかでパケットが『大きすぎる』と拒絶されていないか？」を疑ってみてください。
パケットの一つひとつが目的地に向かって旅をしていると想像すると、ネットワークのトラブルシューティングも少しだけドラマチックに見えてきませんか？
それでは、また次回の記事でお会いしましょう！現場からは以上です。
コメント