VPN の疑わしい MTU 問題を値を当てずに検証する

インターネット MTU 値の一覧を、どれかが速く感じるまで試すのは検証ではなく、停止規則のない探索です。うまくいく方法は、制御されたサイズ条件を一つだけ変え、結果を同じ経路と比べます。再現できる無害な失敗から始め、実験を取り消せる動作中の設定を残してください。以下のすべてはその規律を前提にし、それがなければ弁護できない数値だけが残ります。

数値を変える前に経路を固定する

設定に触る前に、デバイス、アクセス回線、トンネルプロトコル、エンドポイント、宛先、アドレスファミリを書き留めます。この六つの事実が経路であり、別の経路に向けたプローブは別の問題を測ります。これらは結果を再現可能にもし、それが検証と午後いっぱいのいじくり回しを分けます。メモは端末の横に置き、頭の中に置かないでください。

実行を許可されている最も狭い検証から始めます。サーバ側の変更はそのエンドポイントの全利用者に届くので、調査の最後に属し、最初ではありません。

自分が制御できるサイズでプローブする

Linux ではプローブは ping -M do -s 1400 host の形で、Windows では ping -f -l 1400 host の形です。設定しているのはペイロードであり、パケットサイズではないのは IP と ICMP のヘッダが上に加わるからです。

目の前のシステムのドキュメントを読み、フォーラムの投稿からフラグをコピーしないでください。自分が制御できる宛先を選び、応答がないことが謎ではなく信号になるようにします。正確なコマンドと正確なサイズを、経路と同じメモに記録します。サイズのない結果は逸話です。一度の実行で二つ変えると、どちらが結果を生んだか分かりません。

失敗したプローブは MTU の上限の証拠ではない

捨てられたプローブはサイズの上限ではなく ICMP フィルタリングを意味することがある、そしてその誤りが、決して問題ではなかった値を調整させるのです。何かを変える前に、プローブを実際のアプリケーションと、サイズに関するエラーメッセージや範囲を絞ったキャプチャと比べてください。成功した小さな ping も、上限のはるか下に収まっている可能性があるので何も証明しません。設定が動く前に、独立した観測が二つ必要です。

プローブが成功しているのにアプリケーションが失敗するなら、その経路で単純なサイズ上限ではない証拠があります。候補となる変更の枝が丸ごと消えるので、それを書き留めてください。

クライアントがすでに対応しているパラメータを一つだけ調整する

クライアントがこのプロトコルについて記録している設定を変え、エンドポイントと宛先はそのままにします（そうしないと二つ同時に変えたことになります）。TCP の MSS クランプはすべての UDP 負荷を覆うわけではなく、だからこそ動き始めたブラウザがトンネルプロトコルをそのまま壊れた状態にし得ます。IPv4 と IPv6 はここでは別の経路で、どんなルーティングが働くより前にヘッダが異なるからです。

両方を公開しているなら両方のファミリを試してください。一方の結果は他方について何も語りません。今夜この経路で機能した値は一つのデータであり、VPN 全体の MTU ではありません。一度の成功した転送だけで全体設定に昇格させず、値はそれが来た経路の横に書き留めてください。

取り消し、確認、記録

比較が仮説を支えないなら、元の値に戻します。ネットワークマネージャがどこか別の場所に永続的な上書きを保存していないか確認してください。実験が方針になるのはそういう経路です。再接続して、検証していたものだけでなく普通のアプリケーションも動かし、そのうえで症状、実際に効いている経路、旧値と新値、結果の再現性を記録します。

誰かが変更を広げる前に、その記録を変更申請と一緒に保管してください。経路 MTU 探索の仕組みは RFC 1191 で、より小さな値が一方の経路を救い、他方には何もしない理由を説明しており、数値の一覧はそのモデルの代わりにはなりません。経路、サイズ、観測、そして復元した値を言えるようになったとき、検証は終わります。