OpenVPN：クライアントごとにパスMTUの問題を軽減する方法は？

お客様には数十台の組み込みデバイスがインストールされており、すべてOpenVPNサービスの本拠地となっています。これは一般的には正常に機能しますが、一部のお客様には深刻なパスMTU問題があります。お客様のネットワークを修正する影響は限られているため、それに対処するにはOpenVPNが必要です。一言で言えば、私の質問は次のとおりです。

クライアントごとにいくつかのクライアントの低パスMTUを緩和するにはどうすればよいですか？つまり、すべてのクライアントの最悪のケースに対応するグローバル設定を使用せずに

最悪の場合はかなり悪いことに注意してください。パスMTU 576は、すべてのフラグメントをドロップし、それ自体をフラグメント化せず、DFビットを尊重しません。この問題を世界的に解決したくない理由がわかります。

OpenVPNのマンページの最も顕著な申し出MTU関連オプションの数を、--link-mtu, --tun-mtu, --fragment and --mssfix。しかし、それはまた言う

--link-mtu [...]何をしているのかわからない限り、このパラメーターを設定しないことが最善です。

--tun-mtu [...] MTUのサイズ設定の問題に対処するには、-fragmentおよび/または--mssfixオプションを使用するのが最善です。

私は実験を始めて--fragmentと--mssfixすぐが、少なくとも前者はクライアント側だけでなく、設定しなければならないことを認識しなければならなかったまた、サーバー側の。その後、サーバー側のクライアントごとの設定を調べました--client-config-dirが、

次のオプションは、クライアント固有のコンテキストで有効です：--push、-push-reset、-iroute、-ifconfig-push、および--config。

MTUオプションの言及はありません！

だからここに私のより具体的な質問があります：

なぜ正確にあるlink-mtuとtun-mtu落胆？これらのオプションの潜在的な問題は何ですか？低レベルのIPヘッダー変更に非常に満足していることに注意してください。
link-mtu tun-mtu fragment mssfix動作させるには、サーバー側でミラーリングする必要があるオプションはどれですか？
どのオプションを使用link-mtu tun-mtu fragment mssfixできますclient-config-dirか？
4つのオプションすべてをサーバー側でミラーリングする必要client-config-dirがあり、内部で使用できない場合：クライアントごとに低パスMTUと戦う代替手段はありますか？

ノート：

私の質問の一部は、5年前にここですでに質問されていますが、当時は本当に回答されていないため、それらを複製することを敢えてします。
OpenVPNサーバーは、現在Ubuntu 12.04で2.2.1です。Ubuntu 14.04で2.3.2へのアップグレードを準備しています
OpenVPNクライアントはDebian 7.6で2.2.1です
お客様のパス-MTUを自分で手動で決定できてうれしいです
現在、多くのサーバー側をテストすることはできません。しかし、我々は完全な独立したテストベッドを構築しています、すぐに準備ができているはずです。

役立つアドバイスをありがとう。

ip openvpn mtu ip-fragmentation

— ニルス・トエドマン
ソース

576？親愛なるガウド。ダイアルアップの時代からMTUがこれほど低いことはありません。それは古代のシリアルリンクを経由していますか？

— マイケルハンプトン

2つのOpenVPNサーバーを実行できますか？両方のサーバーを同じパブリックIPアドレスで実行し、ポート転送（またはルーティングポリシー）を使用して、既知の問題のあるネットワーク上にあるかどうかに応じて、クライアントを別のOpenVPNサーバーに誘導することができます（クライアントのリストによって決定されます） IPアドレス）。

— カスペルド14

@MichaelHampton私も疑問に思いました。600kbit / s以上でRTT〜30msで、私にとっては古代のシリアルのようには見えません。他の愚かな設定（たとえば、「断片化が必要」でDFに応答しないなど）があることを考えると、これは別の設定だと思います。私たちは彼らに言ったが、まだ返事をしていない。

— ニルストートマン

@kasperd興味深いアイデア。複数のOpenVPNサーバーインスタンスを実行できます。異なるMTU範囲に対しては、おそらく3または4が必要です。サーバー側のクライアントごとのNATは機能しません（動的なパブリッククライアントIPアドレスを予測できません）が、とにかくMTU設定（正しい？）のためにクライアント構成を変更する必要があるため、単純に異なるポートを直接構成しますクライアントに。-しかし、それは私が避けることを好むメンテナンスの悪夢です！

— ニルストートマン14

@NilsToedtmannどのクライアントが影響を受けるかを検出するためにどの基準を使用しますか？もう1つのアプローチは、クライアントが接続した後にサーバーでスクリプトを実行することです。このスクリプトは、さまざまなパケットサイズでクライアントIPアドレスにpingを試行して、どの機能が有効で、どの機能が有効でないかを判断できます。次にiptables、そのクライアントIPアドレスとの間で送受信されるすべてのSYNパケットのMSSを削減するルールを挿入できます。

— カスペルド14

mssfix 1300設定ファイルにオプションを追加することで、クライアント側の問題を解決しました。

openvpnのmanページから：

--mssfix max
    Announce to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed max bytes.

私のソリューションの最初のアイデアは、personalvpn.orgから来ました。

— Oz123
ソース

だから、mssfix唯一のクライアント側を設定することができますか？まあ、少なくともそれは何かです。それは（私は他のオプションに興味を持った理由であるが、少なくとも推奨UDPパケットのヘルプいえないfragmentニーズあまりにもセットサーバー側すべき）

— ニルスToedtmann

mssfixは、サーバーだけでなくクライアントにも追加できます。ただし、より小さい値がネゴシエーションに使用されます

— アーメド

回答が不足しているため、非常にエレガントではなくシンプルなソリューションを投稿しています。「悪いクライアント」のためにTCPで別のOpenVPNインスタンスを実行します

proto tcp

クライアントのTCP MSSを下げます。例えば

iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o ${OUT_DEV} -j TCPMSS --set-mss ${PATH-MTU-MINUS-40}

このソリューションの利点は、各クライアントが個々のMSSを設定できることです。

これは確かにTCP-over-TCPですが、多くのシナリオで十分に機能するはずです。

私はまだ必要としないソリューションに非常に興味があることに注意してください、proto tcp多かれ少なかれ私の概説された要件を満たす場合、私はそれらを有効な答えとしてマークします。

— ニルス・トエドマン
ソース