なぜMTUの不一致がホームサーバーの部分的な接続問題を引き起こすのですか？

MTUの不一致は、小さなパケットは経路を通過できるが大きなパケットは通過できない場合に、ホームサーバーの接続性が部分的に失われる原因となります。DNS応答、TCPハンドシェイク、ping、短いAPIコールは成功し、経路が正常である印象を与えます。しかしTLS、ウェブ応答、アップロード、ファイル転送が1つのリンクで運べるサイズを超えるIPパケットを生成すると接続は停止します。

正しいパスはそのサイズ制限を報告し、送信者がパケットを小さくできます。部分的な失敗は、トンネル、仮想ブリッジ、ルーター、ISPリンクのいずれかがより小さいMTUを持ち、フィードバックが送信者に届かない場合、または異なるレイヤーが実際のカプセル化経路を反映しないサイズを通知する場合に現れます。その結果、到達可能でも信頼できるデータ配信ができません。

簡単な答え：パケットサイズは接続性の一部です

MTUは、インターフェースが1回のリンク層送信で送信できる最大のIPパケットサイズです。エンドポイントは、ホームサーバーのイーサネットポートに表示される1500バイトの設定だけでなく、経路全体で使用可能な最小値を気にします。VPNやオーバーレイのヘッダーはスペースを消費するため、LANに収まるパケットでもカプセル化後には大きすぎる場合があります。

失敗は部分的です。なぜならプロトコルは小さな制御パケットから始まるためです。TCPの3ウェイハンドシェイクは完了し、ブラウザは接続できますが、どちらの側もフルサイズのデータセグメントを送信する前です。大きすぎるパケットが消失し、確認応答や小さな再送が通る場合、セッションは生きているように見えますが、ほとんど進展しません。

MTU、MSS、およびパスMTUディスカバリーは関連していますが異なります

インターフェースMTUは、1つのインターフェース上でのIPパケットの最大サイズを制限します。TCP最大セグメントサイズ（MSS）は、エンドポイントが各セグメントで望むTCPペイロードの量を通知し、IPおよびTCPヘッダーのためのスペースを残します。MSSクランプはルーターで通知されるペイロードを減らすことができますが、これはTCPの交渉に影響し、すべてのUDPやICMPパケットには影響しません。

パスMTUディスカバリー（PMTUD）は、送信者が経路上の最小MTUを知ることを可能にします。IPv4の場合、RFC 1191は、Don’t Fragmentビットが設定されたパケットを転送できないルーターがICMP断片化必要フィードバックを返すプロセスを定義しています。送信者はその後、パスの値を下げて再送信できます。

IPv6ルーターは転送パケットを断片化しません。RFC 8201はIPv6ノードがICMPv6 Packet Too Bigメッセージを使ってより小さい経路MTUを学習すると規定しています。その制御トラフィックをブロックしてもデータ経路は強化されず、エンドポイントが実際の制限に適応するのを妨げます。

ホームサーバー経路で大きなパケットの破棄が始まる場所

トンネルは使用可能なペイロードを縮小する

WireGuard、IPsec、PPPoE、VLANなどのカプセル化は元のパケットの周りにヘッダーを追加します。1500バイトの内部パケットは、これらのヘッダーがあると1500バイトの外部リンクにそのまま収まりません。トンネルインターフェースは通常より低いMTUを通知しますが、手動オーバーライドや中間デバイスが楽観的な値をエンドポイントに残すことがあります。

不一致はリモートアクセスに影響を与え、ローカルサービスは完璧なままであることがあります。Wi-Fi接続の電話は通常のイーサネット経由でサーバーに到達しますが、同じ電話がVPN上ではより小さいトンネル経路を使います。ルーティング、認証、小さなリクエストはまだ機能するため、症状はアプリケーションや証明書の問題に似ることがあります。

ネストされた経路は問題を複雑にします。コンテナパケットは仮想イーサネットペアとブリッジを通過し、VMアダプターに入り、さらにVPNに入ることがあります。制限的なMTUは完全な経路に属し、各可視インターフェースは自分のレイヤーに妥当な値を報告するかもしれません。

ICMPフィードバックがフィルタリングまたは失われている

制限ルーターがサイズオーバーのパケットを破棄し、そのエラーが送信元に届くと、PMTUDは回復可能です。ファイアウォールがICMPまたはICMPv6を無差別に破棄すると、送信者は経路が運べないサイズを使い続けます。Cloudflareはこの現代的な障害をPath MTUブラックホールと説明しています：大きなパケットが静かに失われ、アプリケーションは待ち続けます。

非対称ルーティングは、ファイアウォールが意図的にメッセージをブロックしなくても同じ結果を生むことがあります。データパケットは一つの経路を通り、ICMPエラーは別の経路を通ることがあり、ポリシールーティング、NAT、またはプロバイダのフィルターが戻りメッセージを元の送信者と関連付けるのを妨げることがあります。したがって、パケットキャプチャはデータ方向とフィードバック方向の両方を検査する必要があります。

繰り返されるTCP再送は手がかりであり証拠ではありません。輻輳や無線損失も再送を引き起こします。失敗が再現可能なペイロードサイズ付近で始まり、小さなプローブが成功し、インターフェースMTUや通知されたMSSを減らすとすぐに進行が回復する場合、MTUの問題の可能性が高まります。

仮想ネットワークは誤ったサイズを通知する

コンテナブリッジやVMスイッチは基盤より大きなMTUを継承またはデフォルト設定することがあります。コンテナは仮想インターフェースに有効なパケットを作成しますが、ホストがVPN、クラウドオーバーレイ、PPPoEアップリンクを通すと大きすぎる場合があります。オフロード機能によりキャプチャがワイヤパケットより大きく見えることがあるため、キャプチャ場所が重要です。

ドキュメント化されたDockerの事例はまさにこの子問題に従いました：小さなLDAPリクエストは成功しましたが、応答は消えました。なぜならVPNのMTUが1400でDockerは1500を使用していたからです。ホストネットワーキングは仮想レイヤーの不一致を取り除いたためアプリを修正したように見えましたが、アプリケーション自体は変わっていません。

巨大なTCPセグメントを示す1つのキャプチャからワイヤの挙動を推測しないでください。一般的なセグメンテーションオフロードはOSに大きなバッファを提示し、後で分割します。受信側でキャプチャし、診断のために一時的にオフロードを無効にするか、制御されたパケットサイズのテストとインターフェースカウンターを関連付けて、デバイスが不可能なフレームを送信したと結論付ける前に確認してください。

アップストリームとトンネル設定が実際の制限を形作る

ホームサーバーが不一致を作り出した場所とは限りません。PPPoE、ISPの移行メカニズム、リモートアクセス用トンネル、上流ルーターが最も狭いリンクを導入している可能性があります。物理NICだけを変更するのではなく、クライアントからサービスまでの正確な経路を追跡し、すべてのカプセル化境界を記録してください。

PMTUDに必要な制御メッセージを許可してください。IPv4では関連する宛先到達不能の断片化必要メッセージ、IPv6ではPacket Too Bigが含まれます。すべてのICMPをブロックするのではなく、メッセージタイプと状態ごとに厳密なファイアウォールポリシーを適用してください。サーバーはネットワークが報告を拒否する経路制約を学習できません。

断片化を通常の修正策として依存しないでください。RFC 8900はIP断片化が運用上の脆弱性をもたらすことを説明しています。MTUを合わせ、PMTUDを維持し、トランスポート層のプローブを安全に行うことは、すべてのミドルボックスが断片を転送・再構築すると仮定するよりも堅牢です。

ルーターの一方を変更できない場合、トンネルや転送境界でMSSクランプが実用的なTCPの回避策になることがあります。普遍的な数値をコピーするのではなく、実際の経路から設定してください。これはサイズオーバーのUDPデータグラムを修復せず、不必要に低い値はパケットとヘッダーのオーバーヘッドを増やすため、キャプチャやアプリケーションテストで改善を確認してください。

サーバー、VM、コンテナの設定は一致させる必要があります。

物理NIC、ボンド、VLAN、ブリッジ、VMアダプター、コンテナネットワーク、トンネルのMTUを調査してください。カプセル化を正しく考慮するレイヤーでは数値が完全に一致する必要はありませんが、内側のレイヤーが次のレイヤーで運べない、または大きすぎると報告されるパケットを生成してはいけません。

Dockerの場合、ネットワーク作成時またはデーモン設定で適切なMTUを設定し、必要に応じて影響を受けたネットワークやコンテナを再作成してください。Civoのトラブルシューティング例では、基盤を無視するDockerのMTUが予期しない接続問題を引き起こすことが示されています。設定を編集しただけでは実行中のネットワークが変更されたとは限らないため、その後にライブインターフェースを確認してください。

パフォーマンスチューニングは修復から分けて行ってください。ZimaSpaceの長距離リンクのTCPウィンドウサイズに関する説明は、どれだけのデータが飛行中に保持できるかに関するもので、MTUはパケットサイズを制御します。バッファを増やしても、大きすぎるパケットが小さいリンクを通過できるようにはなりません。

壊れた段階を特定するチェック

一貫して通過する最大パケットを見つける

プラットフォームに適したpingオプションを使い、ペイロードサイズを設定し、可能な場合は断片化を禁止します。結果をインターフェースMTUと比較する際はIPおよびICMPヘッダーのバイト数を加えることを忘れないでください。失敗が見られる同じクライアント経路から複数のサイズをテストします。繰り返し可能なしきい値は、成功したデフォルトpingよりも有益です。

LAN、VPN経由、コンテナやVM内部からテストを繰り返します。しきい値が境界のどこかで変わる場合、その層が最も疑わしいです。一部のネットワークはエコートラフィックをレート制限またはブロックするため、TCPアプリケーションのリクエストや専用のパスMTUツールで結果を確認してください。

インターフェース、ルート、およびカプセル化を検査する

影響を受ける宛先の選択された経路と出口インターフェースを記録します。パケットが通過するすべての仮想および物理インターフェースのMTU値、トンネルおよびコンテナネットワークの設定を検査します。ポリシールーティングや分割トンネルが有効な場合、デフォルトルートが使われているとは限りません。

外側のIPバージョンとトランスポートを含む実際のトンネルスタックのヘッダーオーバーヘッドを計算します。安全な内部MTUは外側の経路でこれらのヘッダー分の余裕を残す必要があります。トンネルが経路を変える場合は、サポートされる基盤ネットワーク全体で機能する値を選ぶか、動作する検出機構を維持してください。

両側でデータとICMPフィードバックをキャプチャする

送信者の近くと狭帯域リンクの後でキャプチャします。確認応答なしで繰り返される大きなパケット、ICMPの断片化必要メッセージ、またはICMPv6のパケットサイズ超過メッセージを探します。エラーが下流で発生し送信者に届かない場合は、戻り経路とファイアウォールポリシーに注目してください。

TCPの場合、SYNおよびSYN-ACKパケットのMSSオプションを検査し、観測されたデータセグメントと比較します。MSSを小さくすると送信者が大きすぎるTCPパケットを作成するのを防げますが、UDPが壊れたままかどうかはわかりません。修復を検証するためにキャプチャを使用し、ロードされたファイアウォールルールを成功とみなさないでください。

MTUを調整するかMSSを固定し、再テストしてください

より小さい下層を知るインターフェースでMTUを修正することを優先してください。MTUが作成時に固定されている仮想ネットワークは再作成します。それが不可能な場合は、転送またはトンネルの境界でTCP MSSをクランプし、必要なICMPフィードバックを許可します。結果が明確に分かるように、一度に1つの変更を行ってください。

pingだけでなく元のワークフローを再テストしてください。TLSネゴシエーションを完了し、1パケット以上の応答を読み込み、ファイルのアップロードとダウンロードを行い、再送を観察できるほど接続を維持します。部分的な接続性は、それを露呈したアプリケーションが双方向で信頼性のあるデータ転送を行うまで解決されません。

部分的な接続性が深刻な問題になるとき

バックアップ、復元、リモート管理、同期、認証に影響する場合は問題を緊急扱いしてください。これらのワークフローは初期チェックを通過し、意味のあるデータ転送が始まってから失敗することがあり、不完全なコピーやタイムアウトが発生し、運用者がストレージや認証情報の障害と誤解することがあります。

IPv6がIPv4と異なる動作をする場合、VPN専用経路が失敗する場合、またはコンテナトラフィックがホストトラフィックと異なる場合にも優先してください。これらの違いは、どの経路やカプセル化が使用可能なパケットサイズを変えているかを明らかにします。境界がより決定的であればあるほど、ネットワーク経路を修復せずにアプリケーションを再試行し続けることはあまり有効ではありません。

よくある質問

なぜホームサーバーにはpingできるのにウェブサイトが読み込めないのですか？

デフォルトのpingパケットは小さく、DNS交換やTCPハンドシェイクも同様です。TLSやHTTPが経路制限を超えるパケットを送信するときにのみウェブサイトが停止することがあります。より大きな断片化しないプローブをテストし、失敗したウェブ接続をキャプチャして、1つのping応答だけで全パケットサイズが機能すると判断しないでください。

すべてのインターフェースはMTUを1500にすべきですか？

いいえ。イーサネットは通常1500を使用しますが、トンネルや他のカプセル化は外部ヘッダーのための余裕が必要です。重要なのは、各レイヤーが次のレイヤーが運べるサイズを広告するか、経路上の最小MTUに適応できる動作フィードバックを受け取ることです。

MSSクランプはMTUの固定と同じですか？

いいえ。MSSクランプは接続設定時に広告されるTCPペイロードサイズを変更し、TCPパケットを既知の制限以下に保つことができます。インターフェースのMTUは変更せず、UDPや他のIPトラフィックを直接制限するものではありません。

MTUの整合性と機能的なPMTUDは経路自体に対処します。クランプは、転送装置やトンネルが制約を伝達できない場合に有用ですが、適切な境界で測定・配置し、影響を受けるすべてのプロトコルでテストを行う必要があります。