高遅延リンクでOpenVPNの信頼性を改善するにはどうすればよいですか?


11

ping時間は約3秒のBGAN衛星リンクでOpenVPN VPNを実行しています。tun構成で使用し、Linux(CentOS)で実行しています。リンクを介して送信されるのは主に電子メールですが、メールに大きな添付ファイルが含まれるとすぐに、VPNが停止するようです。

「私はトンネルを通ってpingを実行できますが、実際の作業は、それがロックアップさせます。これは、MTUの問題ですか?」OpenVPN FAQの質問は私の問題を正確に説明しているようですが、使用mssfixしてfragmentも状況を改善するための多くのことはまだ行われていないようです。

私の主なテストは、scpを使用してVPN経由で2MBのファイルをコピーすることです。約192kバイトをコピーし、「ストール」状態を報告します。数秒待機すると、コピーが再開され、さらに数キロバイト後に再び停止します。

このストールは、OpenVPN構成でオプションfragmentまたはmssfixオプションを設定したかどうかにかかわらず発生します(ただし、設定fragment 1000はストールを減らすように見えますが、ストールを排除するわけではありません)。OpenVPN mtu-testはMTUサイズとして1542を報告しました。

私が使用する方法と時期に関する詳細なアドバイスをインターネットで検索したmssfixfragment、私は唯一のページはよくある質問と同じように言って、どのパラメータを使用する方法とがある場合の詳細を与えていない見つけます。

私の質問は次のとおりです。

  • mssfixand fragmentはいつ使用しますか?
  • mssfixfragment組み合わせて使用しますか?
  • 場合mssfixfragmentソリューションです、何ですかtun-mtulink-mtumtu-discのパラメータは?

さらに、私はiperfツールを使用して帯域幅を測定しています。VPNを使用しない場合、210 Kビット/秒のオーダーで常に測定されます。

iperfをVPN経由で使用する場合($ iperf -c remoteserver -t60 -i5)、10Kbits / secで開始し、1.2Mbits / secを報告するまで着実に上昇します。 1.2Mbits / secはOpenVPNのバッファリングなどが原因であると考えられます)

あるiperfのは、帯域幅を測定するための最良の方法?

この状況での助けは大歓迎です。


現在、openvpnはTCPまたはUDPを使用していますか?
pjc50 09年

これは、現在使用しているUDP
iWerner

すべての回答をありがとうございますが、BGANユニットの放送時間が切れたため、一時的に停止する必要がありました。私は今日も後日続けたいと思っています。私たちは、データがネットワーク経由で送信される(と私たちのクライアントがすでに非常に敏感であるため、したがって、コスト、)倍になるTCPを使用して、UDPでの滞在を好むだろうことを言及する必要があります
iWerner

回答:


5

MTUとしての1542?WANリンクについては聞いたことがない。通常、MTUは最大ペイロード、IPパケットサイズからIP(20バイト)およびICMP(8バイト)のヘッダーを引いたものです。つまり、従来のイーサネットLANではMTU = 1500です。さらに、ほとんどのVPNでは、パケットのカプセル化にオーバーヘッドが発生します。典型的なVPN MTUは1400です。

最新のネットワークでは、入力パスと出力パスが異なる場合があり、自動パス再ルーティングにより変更される可能性があるため、MTUがいつになるかを結論付けることは困難です。このようなネットワークでは、576などのVPNリンクの両側にあるホストでMTUを低く設定する方が効果的です。

MSS(最大セグメントサイズ)は、MTUからIP + TCPヘッダー(40バイト)を引いたものです。通常、これはネットワークスタックによってネゴシエートされ、通常、MTUが間違っていない限り、MTUと同じネゴシエーションの問題はありません。(通常、MTUネゴシエーションは、ICMPまたはブラックホールルーターのブロックによって損なわれます)。

最初に行うことは、送信側でネットワークパケットキャプチャを実行し、フレームサイズで表示を並べ替えることです(この列をWiresharkに追加する必要がある場合があります)。サイズが大きすぎるフレームを送信していないことを確認する必要があります。Large Send OffloadやJumbo Framesなどのオプションが有効になっている場合、現代のネットワークカードでは特大のフレームを送信することは珍しくありません。これらのオプションを有効にすると、30,000バイト以上のフレームが表示されます。


何かを変更する前のパケットキャプチャに対して+1。巨大なフレームが見つからない場合でも、「通常の」パケットがどこかに断片化されていることがあります。
ハビエル

1
デフォルトでは、OpenVPNはtunデバイスのMTUを1500に設定します(これは、マシンのイーサネットデバイスのMTUと同じです)。VPNパケットの断片化が良いことなのか、それとも悪いものなのかはまだわかりません。このスレッドの答えは、それが悪いことを暗示しているようですが、私がウェブ上で見つけた他の参考文献は、それが良いことを暗示しています。
iWerner 2009年

2
@iwerner:pingでmtuサイズを決定しようとしましたか?ICMPが無効になっていない場合、Windowsで次を使用できます:ping -f -l 1372 <destination ip>。成功するまで数を減らしてください。Linuxでは、ping -s 1372 -M do <destination ip>。参考までに、OpenVPN FAQはmssfix 1200の使用を推奨していますが、それは根本原因に対処していません。VPNソリューションを使用して断片化すると、常にパフォーマンスが低下する可能性があります。大規模なVPNをセットアップしている場合、中央のコンセントレーター側ではフラグメンテーションを使用できず、リモートオフィス側のみで使用できます。
グレッグアスキュー

2

好奇心から、ネットワークインターフェイスのMTUを下げようとしましたか?おそらく、衛星リンクがひどく断片化を台無しにします。直観に反する注意として、変更のためにTCP経由でopenvpnを試してみるとよいでしょう。パフォーマンスが低下するはずですが、ラインに沿って断片化を制御できない場合は、役に立つかもしれません。


私は反対を提案するつもりでした:)-この高レイテンシのケースは、TCP-in-TCPの問題が現れ、UDPがそれを回避するケースです。
pjc50 09年

私は彼がopenvpnにデフォルトのUDPポートを使用していると思っていたので、反対を提案しました。はい、通常は同意します。しかし、ちょっと、sysadminが試行錯誤であり、通常は「反対側にあるものを見てみる」ということを知っています:)
ロレンツォグ2009年

ありがとう。現時点ではUDPを使用していますが、TCPを試したことはありませんでした。(私はあなたをupvotedただろうより多くの担当者を持っていた場合)
iWerner

@iWerner:ありがとう:)また、ifaceでMTUを徐々に減らして、いつ停止するかを確認してください(停止する場合)。
ロレンツォグ2009年

2

TCPを使用する場合は、TCPのウィンドウサイズを増やします。これは「空中のパケット数」に役立ちます。

私はこのようなもので遊ぶ必要があったのでしばらくしていますが、ここに私のために見つかったグーグルリンクがあります。

私はあなたがBGANを実行している見るあなたの質問を再読み込みした後-私はよく見なければならないと思い、これを(または単にのためにグーグル:「BGANスプーフィング」)。

帯域幅の測定に関しては、適切なパケットサイズを使用している限り、iperfはかなり適切であることがわかりました。


これは面白いです-それは、TCPアクセラレータは、RedHatのために利用可能であることを言及し、私たちが話したインマルサットの人々は、それはWindowsとOS Xのためにのみ利用可能でした(これはインマルサット/ BGANのウェブサイトが言う確かである)ことを言ったしながら
iWerner

彼らは今それを持っていないかもしれません。文書の日付は07であることがわかります。古いコピーを持っている人を見つけるかもしれません。通常、電話をかけると、Tier 1サポートが提供されます。連絡先をいくつか試しますが、保証はしません。
エディ

私は衛星プロバイダーから逃げました。彼らが話していることを知っている人を見つけるのは難しい。試してみますが、とりあえず試してみてください:sourceforge.net/projects/pepsalプロジェクトの説明から、Inmarsatソフトウェアが行っていることとほぼ同じことが行われています。PEPsalは、統合されたマルチレイヤーの透過TCPです。接続を2つの部分に分割し、データを送信するときにLinux TCPの機能強化を使用し、異なる特性を持つリンクのパフォーマンスを大幅に改善するパフォーマンス強化プロキシ
Eddy

2

間違った木にbarえているのではないかと思います。間違ったMTU問題が発生したときはいつでも、トラフィックは192KBの前に途切れてしまいました。これは、TCPウィンドウ、または衛星アップリンク自体の一部の「飛行中のパケット」ウィンドウの一部に関連していると思います。

確かにいくつかの長いパケットキャプチャ(VPNの「内部」と「外部」の両方)を実行し、すべてのACK

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.