Yüksek gecikme süresine sahip bir bağlantı üzerinden OpenVPN güvenilirliğini nasıl artırabilirim?


11

Ping sürelerinin yaklaşık 3 saniye olduğu bir BGAN uydu bağlantısı üzerinden OpenVPN VPN çalıştırıyoruz. Bir tun yapılandırmasında kullanıyoruz ve Linux'ta (CentOS) çalışıyoruz. Öncelikle bağlantı üzerinden gönderilecek e-postadır, ancak posta büyük ekler içerdiğinde VPN duraklıyor gibi görünüyor.

"Ben tünelden ping, ancak herhangi bir gerçek çalışma kilitlemek için neden olmaktadır. Bu bir MTU sorunu var mı?" OpenVPN SSS'deki soru sorunumu tam olarak açıklıyor gibi görünüyor, ancak kullanmak mssfixve fragmenthala durumu iyileştirmek için pek bir şey yapmıyor gibi görünüyor.

Ana testim 2MB dosyasını VPN üzerinden scp ile kopyalamak . Yaklaşık 192 kilobayt kopyalar ve sonra durgun durumu bildirir . Birkaç saniye beklersem, tekrar kopyalamaya başlar ve birkaç kbayttan sonra tekrar durur.

Bu duraklama, OpenVPN yapılandırmamdaki fragmentveya mssfixseçeneklerini ayarlasam da ayarlamasam da oluşur (ayar fragment 1000duraklamayı azaltmış gibi görünse de ortadan kaldırmaz). OpenVPN mtu-test, 1542'yi MTU boyutu olarak bildirdi.

Ben nasıl kullanılacağı ve ne zaman daha fazla tavsiye için internet arama yapmış mssfixve fragmentfakat sadece sayfaları SSS aynı diyerek ve hangi parametrelerin nasıl kullanılacağı ve zaman konusunda ayrıntı vermeyerek bulabilirsiniz.

O zaman sorularım:

  • Ne zaman mssfixve kullanırım fragment?
  • Ben kullanıyor musunuz mssfixve fragmentbirlikte?
  • Eğer mssfixve fragmentçözüm, ne tun-mtu, link-mtuve mtu-discparametreleri?

Ayrıca, bant genişliğini ölçmek için iperf aracını kullanıyorum . VPN olmadan, sürekli olarak 210Kbits / san.

İperf'i VPN ( $ iperf -c remoteserver -t60 -i5) üzerinde kullanırken , 10Kbits / sn'de başlayacak, daha sonra 1.2Mbits / sn raporlayana kadar sürekli olarak yükselecek ve sonra durur gibi görünecek, burada bir dizi tekrarlama için 0kbit / sn bildiriyor (I 1.2Mbits / sn'nin bazı OpenVPN tamponlamalarından kaynaklanıyor olabileceğini düşünün)

iperf bant genişliğini ölçmek için en iyi yolu?

Bu durumla ilgili herhangi bir yardım çok takdir edilecektir.


Openvpn şu anda TCP veya UDP kullanıyor mu?
pjc50

Şu anda UDP
iWerner

Tüm cevaplar için teşekkür ederim, ancak BGAN ünitesinin mesai süresi bittiğinden geçici olarak durmam gerekiyordu. Bugün daha sonra birlikte çalışmayı umuyorum. TCP kullanmak ağ üzerinden gönderilen verileri ikiye katlayacağı için UDP ile kalmayı tercih ettiğimizi belirtmeliyim (ve dolayısıyla müşterimizin zaten çok hassas olduğu maliyet)
iWerner

Yanıtlar:


5

1542 MTU olarak mı? WAN bağlantısı için bunu hiç duymadım. Genellikle, MTU maksimum yük, ip paket boyutu eksi IP (20 bayt) ve ICMP (8 bayt) üstbilgisidir. Bu, geleneksel bir Ethernet LAN için MTU = 1500 anlamına gelir. Ayrıca, çoğu VPN, paket kapsülleme için ek yük getirir. Tipik bir VPN MTU 1400'dür.

Modern ağlarda, giriş ve çıkış yolları farklı olabileceğinden ve otomatik yol yeniden yönlendirmesi nedeniyle değişebileceğinden MTU'nun herhangi bir anda ne olacağı sonucuna varmak zordur. Böyle bir ağ için, VPN bağlantısının her iki tarafında bulunan 576 gibi ana makinelerinizde MTU'yu düşük ayarlamak daha etkili olabilir.

MSS (maksimum segment boyutu) MTU eksi IP + TCP üstbilgileridir (40 bayt). Bu genellikle ağ yığını tarafından müzakere edilir ve MTU yanlış olmadıkça genellikle MTU ile aynı müzakere sorunlarına sahip değildir. (MTU anlaşması genellikle engellenen ICMP veya kara delik yönlendiricileri tarafından bozulur).

Yapacağım ilk şey, gönderen ucunuzda bir ağ paketi yakalaması yapmak ve ekranı çerçeve boyutuna göre sıralamaktır (bu sütunu Wireshark'a eklemeniz gerekebilir). Büyük boyutlu herhangi bir çerçeve göndermediğinizi, ne olmasını beklediğinizi doğrulamanız gerekir. Büyük Gönderme Boşaltma veya Jumbo Çerçeveler gibi seçenekler etkinleştirilirse, modern ağ kartlarının büyük boyutlu çerçeveler göndermesi olağandışı değildir. Bu seçenekler etkinleştirildiğinde 30.000'den fazla bayt karesi gördüm.


Herhangi bir şeyi değiştirmeden önce paket yakalama için +1. büyük bir çerçeve bulamasanız bile, bir yerde parçalanmış 'normal' paketleri görebilirsiniz.
Javier

1
Varsayılan olarak OpenVPN, tun cihazının MTU'sunu 1500'e ayarlar (bu, makinelerimizdeki ethernet cihazlarındaki MTU ile aynıdır). VPN paketlerinin parçalanmasının iyi bir şey mi yoksa kötü bir şey mi olduğundan hala emin değilim. Bu konudaki cevaplar kötü olduğu anlamına gelirken, web'de bulduğum diğer referanslar iyi olduğunu ima ediyor.
iWerner

2
@iwerner: Ping ile mtu boyutunu belirlemeye çalıştınız mı? ICMP bir yerde devre dışı bırakılmadıysa, pencerelerde aşağıdakileri kullanabilirsiniz: ping -f -l 1372 <hedef ip>. Başarılı olana kadar sayıyı azaltmaya devam edin. Linux'ta, ping -s 1372 -M <hedef ip> komutunu yapın. FYI, OpenVPN SSS, mssfix 1200 kullanılmasını önerir, ancak bu temel nedeni ele almaz. Parçalamak için VPN çözümlerini kullanmak her zaman bir performans isabeti potansiyeline sahiptir. Büyük bir VPN kurulumunuz varsa, merkezi yoğunlaştırıcı ucunda parçalanmayı kullanamazsınız, yalnızca uzak ofis ucunu kullanabilirsiniz.
Greg Askew

2

Sadece meraktan, ağ arayüzünün MTU'sunu düşürmeyi denediniz mi? Belki uydu bağlantısı parçalanmayı kötü bir şekilde bozar. Sezgisel bir not olarak, bir değişiklik için TCP üzerinden openvpn'yi denemek isteyebilirsiniz. Performansları azaltması gerektiğini biliyorum, ancak çizgi boyunca parçalanma üzerinde herhangi bir kontrolünüz yoksa size yardımcı olabilir.


Tam tersini önerecektim :) - bu yüksek gecikme süresi TCP-in-TCP sorunlarının ortaya çıktığı ve UDP'nin bundan kaçınacağı durumdur.
pjc50

Openvpn için varsayılan UDP bağlantı noktasını kullandığını varsayıyordum ve bu yüzden tam tersini önerdi .. evet, normalde sana katılırdım. Ama hey, hepimiz biliyoruz ki sysadmin deneme-
yanılmadır

Teşekkürler. Şu anda UDP kullanıyoruz ve TCP denemek hiç aklıma gelmedi. (Daha fazla temsilci olsaydım seni iptal ederdim)
iWerner

@iWerner: teşekkürler :) ayrıca, iface üzerinde MTU'yu kademeli olarak azaltmayı deneyin ve ne zaman durduğunu görün (eğer duruyorsa).
lorenzog

2

TCP kullandığınızda, TCP'nin pencere boyutunu artırın; bu "havadaki paketlerin sayısı" na yardımcı olacaktır.

Ben bu şeylerle oynamak zorunda kaldım bir süre oldu, ama işte google benim için bulunan bir bağlantı .

Ben sonra seni BGAN yayınladığınız görülüyor sorunuzu yeniden okumak - Ben iyi bak olurdu bu (ya da sadece google: "BGAN sahtekarlığı").

Bant genişliği ölçümüne gelince, makul paket boyutları kullandığınız sürece iperf'in oldukça iyi olduğunu gördüm.


Bu ilginç - TCP hızlandırıcının Redhat için mevcut olduğunu belirtiyor, konuştuğumuz inmarsat insanlar sadece Windows ve OS X için mevcut olduğunu söyledi (ve bu aslında Inmarsat / BGAN web sitesinin söylediği şey)
iWerner

Şimdi sahip olmayabilirler; Belgenin tarihinin 07 olduğunu görüyorum. Eğer yeterince zorlar ve yeterli insanlarla konuşursanız; eski bir kopyası olan birini bulabilirsiniz. Genellikle telefonla aradığınızda, birinci kademe destek alırsınız. Bazı kişilerimi deneyeceğim ama garanti yok.
Eddy

Uydu sağlayıcımızdan kaçtım; Ne hakkında konuştuklarını bilen birini bulmak zor. Denemeye devam edeceğim, bu arada burada denemek için bir şey var: sourceforge.net/projects/pepsal Proje açıklamasından Inmarsat yazılımının ne yaptığını hemen hemen yapıyor: PEPsal entegre, çok katmanlı, şeffaf bir TCP Bağlantıyı iki parçaya ayıran, veri gönderirken Linux TCP geliştirmelerini kullanan ve farklı özelliklere sahip bağlantılarda performansı büyük ölçüde artıran Performans Artırıcı Proxy
Eddy

2

Sanırım yanlış ağaca havlıyor olabilirsiniz. Yanlış MTU sorunları yaşadığımda, trafik 192KB'den önce durdu. Ben daha çok "uçuş paketleri" penceresinde, ya TCP penceresi, ya da belki uydu uplink kendisi bazı tamponlar ile ilgili olduğunu düşünüyorum.

Tüm alıyorsanız kesinlikle bazı uzun paket yakalar (hem 'içini' ve VPN 'dışında') yapmak ve görmek ACK's

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.