PPPoE 上の OpenVPN:link-mtu、tun-mtu、mssfix のどれを下げるか
ping は通るのに大きなページが PPPoE や DS-Lite の回線で止まる。経路を測定して link-mtu、tun-mtu、mssfix のどれを選ぶか決める。当て推量はしない。
ping には応答があり、DNS も解決し、完全なサイズのセグメントを必要とするページだけが固まる。独自のカプセル化を追加する回線では、経路が知らぬ間に数十バイトの予算を失っており、きれいな Ethernet 向けに書かれたプロファイルは、回線が運べないパケットを要求し続ける。接続が遅いのではなく、問題になるパケットだけを正確に捨てているのだ。
これを直す方法は三つあり、それぞれ別の層で働く。間違ったものを選ぶと、何も起きないか、トンネルが新たな形で脆くなるので、選択は経路が実際に何を支えているかから始まる。
三つのつまみ、三つの層
link-mtu は外側の予算で、暗号化されたペイロードに OpenVPN ヘッダー、UDP ヘッダー、外側の IP ヘッダーを加えたものだ。マシンから出ていくものを表すので、物理的な経路が制約するのはこの数値になる。
tun-mtu は内側の予算で、トラフィックが見るインターフェースだ。経路が運べる量よりトンネルのオーバーヘッドの分だけ大きく、OpenVPN は通常、あなたに設定させるのではなくこれを導出する。
mssfix はまったく別の仕組みだ。TCP のハンドシェイク中に告知される最大セグメントサイズを書き換え、カプセル化の後でも収まるセグメントを TCP の相手に選ばせる。インターフェースの MTU は変えず、UDP には何の効果もない。
link-mtu を明示的に設定すると、OpenVPN は内側の MTU を導出するために自身のオーバーヘッドを差し引く。そのオーバーヘッドは固定の定数ではなく、暗号と認証に依存するため、フォーラムからコピーした値が別のプロファイルでは間違っていることがある。link-mtu と tun-mtu の両方を設定すると、クライアントに矛盾する二つの指示を与えることになる。
数値を選ぶ前に経路を測る
トンネルの中ではなく物理インターフェースから測り、ping が報告するのはペイロードであってパケットサイズではないことを忘れない。ペイロードを 1500 バイトのフレームと比べる前に IPv4 と ICMP のヘッダー分として 28 バイトを加え、相手が別の数値を報告したときにはその補正を思い出す。
Linux クライアントでは ping -M do -s 1472 が断片化を禁じ、パケットが大きすぎれば失敗する。通るまでペイロードを下げ、そこに 28 を足して経路の MTU を得る。PPPoE は 8 バイトを消費するので、DSL では 1492 が普通だ。DS-Lite や一部のモバイル経路は 40 以上を消費し、答えは公称リンク速度が示すより低いことが多い。
どの ping サイズも成功するのに大きな転送が止まるなら、単純なサイズ制限ではなくブラックホールを疑う。断片化が必要だという ICMP メッセージが経路のどこかでフィルタリングされているので、送信側は縮めることを学べず、大きなセグメントを必要とするフローだけが気づく。
まず TCP を絞り、次にトンネルを縮める
TCP のハンドシェイクだけが mssfix の触れる範囲なので、通常は最初に試すのに最も影響の少ない制御になる。経路の実際の予算より少し下に設定し、両端が一致するようにサーバーからも同じ値を送り、大きなダウンロードを再試験する。止まりが消えれば問題は TCP のセグメントサイズだったのであり、他は何も変える必要はない。
影響を受けているトラフィックが TCP でないときは内側の MTU を下げる。UDP サービス、トンネルの中のトンネル、あるいはフルサイズのデータグラムを送るアプリケーションは、パケットサイズを書き換えるものが何もないため、MSS の絞り込みの後も失敗し続ける。その場合は tun-mtu を下げるか、link-mtu を設定して内側の値をクライアントに導出させるが、両方は決してしない。
古い断片化オプションに手を伸ばしてはいけない。トンネルの中でパケットを分割し、オーバーヘッドを増やしたため正当な理由で非推奨になっており、現代の OpenVPN は代わりに経路を正確に記述することを期待している。
小さな計測がなぜ効き続けるのか
DNS クエリ、ICMP エコー、TCP ハンドシェイクはどれも失敗するサイズよりはるかに小さい。だからトンネルはどの簡単なテストでも健全に見える一方で、TLS ハンドシェイクや HTTP 応答は静かに失敗する。動作する traceroute と、最初の大きな応答で止まるブラウザーという組み合わせこそ、探すべき兆候だ。新しいプロファイルに手を伸ばす前に、フルサイズの計測に手を伸ばす。
失敗したトラフィックで確認する。大きなページを取得し、影響を受けているのがそのサービスならフルサイズの UDP データグラムを送り、別の回線の二台目のクライアントから繰り返す。次にプロファイルに触る人がその数値を恣意的なものとみなさないよう、測定した経路 MTU と選んだ値を記録する。
IPv6 がトンネル上を走るときは、すべての IPv6 リンクが運ばなければならない最小値である 1280 より内側の MTU を下げてはいけない。より小さな MTU は経路についての事実であり、感覚で調整する性能設定ではない。