Linux の経路ごとの MTU：サイズを決める三つの制御、一つの経路

Linux クライアントの三つの設定は、どれも「パケットを小さくする」と読めますが、働く層が違います。インターフェース MTU はデバイスが送るすべてのパケットを上限で抑えます。経路 MTU はその経路を使うパケットを抑え、VPN の一つの宛先には多くの場合こちらが本当に欲しいものです。TCP MSS クランプは両端が交渉する内容を変え、UDP には何もしません。

同じつまみに見える三つの制御

選ぶ前に並べてみてください、間違った行を選ぶことが、うまくいかない助言の大半を説明します：

マシン全体の Ethernet MTU を下げるのは、この修正の乱暴な版です。動きますが、ホスト上の他のすべてのアプリにも不利で、経路が問題なかったものも巻き込みます。経路ごとの値なら、同じ意図を副作用なしに表せます。

この比較が成り立つのは、ホスト自身が生成する通信だけです。別のクライアントのパケットを転送する場合は、そのクライアント自身の経路とトンネルの外側の予算が関わり、このホストの経路メトリックはその境界を越えません。

予算は検索で勝つ経路に結びつける

IPv4 の経路レコードの例は次のとおりです：

ip -4 route get 10.60.0.20
ip -4 route add 10.60.0.0/16 dev tun-office src 10.90.0.2 mtu 1380

このレコードは貼り付ける値ではなく、意図の記述として読んでください。プレフィックス、デバイス、優先ソースは実際の構成に合わせる必要があり、 その数値はブログ記事ではなく、カプセル化された経路についての証拠から取る必要があります。経路 MTU が制限するのは内側の IP パケットであり、1380 バイトの TCP ペイロードや 1380 バイトの暗号化された外側パケットとは同じではありません。

何かを足す前に、検索が実際どこで解決されるかを見てください。ポリシールールのあるホストは、ある宛先を main 以外のテーブルで経路選択できることがあり、そして main にしか存在しないメトリックは、その要求には見えません。 ip -4 route show table all と ip route get の答えを比べてください。ルールが使うときはマークや名前空間の文脈も含めて、二つが食い違うならメトリックが必要なのは答えたテーブルであり、見た目が整ったほうではありません。

mtu は mtu lock ではありません

既定ではカーネルは ICMP のフィードバックから経路 MTU を更新できますが、経路 MTU 探索はそのための仕組みです。 lock を足すとそれが止まります。これは別の判断であり、同じ数値を守るより強い方法ではなく、IPv4 では「分割しない」ビットの扱いも文書どおりに変わります。

経路を測定し、何が届いても値を固定したいならロックは妥当です。ネットワークが正当なサイズのフィードバックを送るときは悪い既定で、カーネルが調整できなくなり、障害は別の症状に移ります。

経路のどこかで ICMP がフィルタされているなら、経路設定では直りません。修正はフィルタ側の話で、小さい MTU は次の経路変更まで本当の障害を隠す回避策です。

トンネルソフトは独自のサイズ調整つまみを追加します

OpenVPNの mssfix は、文書化された UDP トンネルの場合に TCP セグメントのサイズを調整します。TCP の会話に働くので、OS の経路 MTU の別表記ではなく、交渉を無視する UDP サービスには役立ちません。

経路 MTU、インターフェース MTU の変更、MSS クランプを同じ変更枠に重ねないでください。問題が消えてもどれが効いたか分からず、残したものは誰も覚えていない理由で何年も通信を制限します。

元に戻せるようにしてから、証明する

経路の本当の所有者が、再接続後も変更が残るかを決めます。経路を動的に入れる VPN クライアントは通常あなたのメトリックなしで作り直すので、手作業の ip route add は一日後に失敗した修正のように見えます。値は管理側の設定に入れ、一時的な実験が要るなら先に元の経路を記録してください。

止まった操作を行う新しい接続で試し、意図したプライベート経路が今も勝ち、無関係な宛先が変わっていないことを確認し、トンネルを再接続して経路を読み直してください。再接続で消える値は修正ではありません。

証拠が変更を支えないなら、管理側から上書きを外し、経路を削除するのではなく元の経路属性を戻してください。そして何をどの経路で測ったかを記録し、次に人が本当の改善と放置された実験を区別できるようにします。