VPN経由のパスMTU探索：サイズ設定とICMPの空白

トンネルは経路が運べるパケットを縮め、探索はフィードバックが届いて初めて機能します。推測するのではなく、経路を測定し、試し、検証してください。

トンネルはハンドシェイクを完了し、小さなリクエストは戻ってくるのに、最初の大きな転送で止まります。このパターンは、スループットよりもはるかに早くパスMTUを示しています。経路上のすべてのリンクがパケットサイズを制限し、カプセル化はその許容量の一部を外側のヘッダーに費やすため、内側のパケットは生の経路が示唆するより小さくなければなりません。障害は静かなもので、だからこそ診断に手間がかかります。

パスMTUが実際に測るもの

パスMTUは二つのホスト間の経路にある最小のリンクMTUであり、ローカルインターフェースに表示されるMTUではありません。ローカルの値は推定の出発点であり、経路がどこで終わるべきかを決めます。同じトンネルが一方のアクセスネットワークでは機能し、別のネットワークでは止まるのはこのためです。変わったのは経路であり、設定ではありません。一度測ってどこでも仮定するのが、この問題を生き長らえさせる誤りです。

トンネルの場合、重要になる数値は内側のMTUで、外側の経路の許容量からカプセル化が消費する分を引いたものです。WireGuardは外側のIPヘッダーとUDPヘッダーを追加します。他のトランスポートは独自のものを追加します。内側のサイズを高く設定しすぎると、フルサイズの各パケットには、決して起こらないかもしれないフラグメンテーションが必要になります。

トンネルが使えるパケットを小さくする理由

トンネルインターフェースが物理リンクのMTUを保つと、大きなパケットはすべて、下流の誰かがフラグメント化を引き受けることに依存します。IPv4は原則としてそれを許しますが、フラグメント化しないよう指示されたルーターは代わりにエラーを返します。IPv6のルーターは転送中に決してフラグメント化しないため、同じ設定でもアドレスファミリーによって動作が異なります。いずれにせよ、何かが報告を返すまで送信側は何も学べません。

実際の結果は、ハンドシェイクには収まるがペイロードには収まらないサイズです。TLS ClientHelloやDNSクエリは、縮んだ経路をそのまま通過できるほど小さいのに対し、一括転送はそうではありません。そのため症状は特定のホストではなく、特定の操作の周りに集まります。

フィードバックが届いて初めて探索が機能する

IPv4の探索はdon't-fragmentビットに依存します。パケットを転送できないルーターは次ホップのMTUを添えたICMP fragmentation-neededを返し、送信側は推定値を下げます。IPv6は代わりにPacket Too Bigメッセージを使います。ルーターが転送中にフラグメント化しないからです。どちらの仕組みも、メッセージがトンネルを通り、戻り経路上のあらゆるファイアウォールを越えて送信側に戻る道を見つけることを前提としています。その前提が崩れると、送信側は経路が運べないサイズを再試行し続けます。

echo requestとecho replyを許可しているファイアウォールが、それらのエラー種別まで許可しているとは限りません。ICMPは一族であり、ここで重要なのはエコーの組ではなくエラーです。トンネルの両端とその間の経路で制御トラフィックのポリシーを確認し、あらゆる場所で全てのICMP種別を許可するのではなく、プラットフォームがサポートする指針に従ってください。

同じフィルタリングがトンネルの内側にあることもあります。内側の経路がエラーを落とす一方で外側の経路がそれを運ぶと、送信側はカプセル化されたトラフィックが実際には見ない制限に適応してしまうことがあります。

数値を推測するのではなく経路を試す

宛先、アクセスネットワーク、トンネルを固定したまま、パケットサイズだけを変えます。MTUのヒント付きで失敗するdon't-fragmentの試行は次ホップの制限を教えてくれます。サイズが通るまで繰り返し、サイズとアドレスファミリーの両方を記録します。

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

収まるpingは、実際のアプリケーションのフルサイズセグメントが収まることを証明しません。だから実際に失敗した転送でテストを繰り返してください。最も大きな成功した試行と、設定したトンネルMTUを比較し、二つの数値をメモで分けておきます。それらがほぼヘッダー一つ分違うなら、障害ではなくカプセル化のオーバーヘッドを見つけたことになります。

RFC 4821に記述されたPLPMTUDは上方に試行し、届けられたエラーを信頼する代わりにトランスポートの確認応答を使います。ICMPをフィルタリングする経路で役立ちますが、サポートはスタックとアプリケーションによって異なります。TCPフローは自力で回復することがある一方、固定のデータグラムサイズを持つUDPアプリケーションは失敗し続けます。

値を選び、理由を記録する

経路がわかれば、トンネルMTUを下げることは診断であり正当な修正でもあります。どの経路とどのフィードバック機構が関与したかを知ることの代わりにはなりません。モバイルリンク向けに調整した値は、光ファイバー接続では不必要に小さくなるからです。選んだサイズ、それを正当化した試行、ロールバック手順を記録してください。

IPv4の仕組みはRFC 1191に、IPv6のパケット化の指針はRFC 8201に記述されています。両方を挙げておけば、次のエンジニアが前提を導き直さずに済みます。選んだサイズでも転送が止まるなら、数値を下げるのをやめて次の層を見てください。あらゆるサイズで失敗する経路はMTUの問題ではありません。

関連記事