ジャンボフレームはVPN経路に9000バイトのパケットを運ばせない

LANで9000バイトのフレームを有効にして、VPNが速くなることを期待しました。ところが遅くなり、大きな転送をまったく通さなくなりました。ジャンボフレームはローカルリンクの合意であり、トンネルが越える経路を広げるものではありません。

使える予算は、トンネルが加えるカプセル化を含め、経路上の最小の境界で決まります。

ジャンボフレームが実際に変えるもの

MTUはひとつのインターフェースの性質です。サーバーとそのスイッチで上げれば、そのふたつはフラグメンテーションなしでより大きなフレームを交換できます。スイッチの先のルーター、ISP、トンネルの向こう側については何も語りません。それらの機器には独自の限界があり、どれかを超えたパケットは、あなたが設定していない規則に従って破棄または分割されます。

ローカルの合意、グローバルな結果。混乱はそこに尽きます。

カプセル化の税

トンネルはパケットを別のパケットの中に包みます。IPv4上のUDPで使うWireGuardは約60バイトのオーバーヘッドを加え、OpenVPNのUDPモードも同じ範囲で、IPsecはモードとアルゴリズムによって変わります。そのバイトは外側の経路の予算から出るのであって、どこからも涌いてくるわけではありません。

つまり、トンネルのヘッダーが加わった時点で、1500バイトの外側リンクは1500バイトの内側パケットを運べません。

計算は一度やっておく価値があります。1500バイトの経路では、カプセル化されたパケットが収まるように、WireGuardインターフェースは1420前後のMTUを求めます。内側のインターフェースを9000にすると、大きなパケットはトンネルが実行できないフラグメンテーションを必要とするか、破棄されます。

経路上の最小リンクを見つける

経路をたどって最も低いMTUを探します。LANは通常1500か9000、WANは通常1500で、モバイルやPPPのリンクはさらに低いことがあります。そこからトンネルのオーバーヘッドを引きます。結果が内側インターフェースのMTUより小さければ、それが答えです。経路MTU探索はこれを自動で見つけられますが、それが頼るICMPメッセージが通過を許されている場合に限ります。

ICMPがフィルタリングされていると、小さな要求は問題なく通るのに大きな転送が止まる、というのが定番の原因です。

変更を広げずにサイズ依存を確かめる

代表的な転送を使い、元の値に戻せるように保存しておきます。ping -M do -s 1472はDFビットを立てた1500バイトのパケットを試し、通るまでサイズを下げてください。大きなパケットだけが失敗するなら、経路ではなくサイズの問題です。

キャプチャを読むときはホスト側のオフロードに注意してください。セグメンテーションオフロードは、実際にケーブルを流れたものよりはるかに大きなフレームを見せることがあり、動いている経路が壊れて見え、壊れた経路が正常に見えます。

大きなMTUが正しい設計になるとき

管理されたプライベートネットワークなら、経路上のすべての機器が同意し、トンネルのオーバーヘッドを織り込んでいれば、より大きなフレームを端から端まで流すのは正当です。それはリンクごとに文書化された値を持つ協調設計であり、クライアントに打ち込むひとつの大きな数値ではありません。

普通の公衆出口なら1500以下と想定し、トンネルに安全な内側MTUを選ばせてください。RFC 8201はIPv6の場合の経路MTU探索を扱っており、フィードバックがどう働くべきかを知るのに役立つ資料です。