私たちは何十もの組み込みデバイスを顧客にインストールしており、そのすべてが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
?client-config-dir
内で使用できない場合:クライアントごとの低パスMTUに対処するための代替手段はありますか?ノート:
有益な助言に感謝します。
オプション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 から来ました
答えがないので、私は今、非常にエレガントではないが単純なソリューションを投稿しています:別のOpenVPNインスタンスをTCP for "bad clients"で実行します
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
を必要としない非常に興味のあるソリューションであることに注意してください。概説された要件をある程度満たす場合は、それらを有効な回答としてマークします。