OpenVPN üzerinden SSH oturumu birkaç satır sonra kesiliyor / kilitleniyor

Debian 6 (ARM) çalıştıran çok sayıda aynı fansız bilgisayar var. Bunların çoğu comcast ve work ok ile bağlıdır. 'WiMax' modemlerine bağlı olan ve iletişim sorunları olan bazıları var.

Özellikle: Eğer bunlardan birine ssh ve 'ps -ax' gibi bir komut denerseniz yaklaşık 3 satır geri alırsınız ve sonra oturum kilitlenir. Oturmasına izin verirsem, sonunda bir 'akran tarafından kapatılan oturum' ile kapanır.

Ne denedim:

ssh -vvv → hata mesajı yok
ssh <user@host> 'command'→ bu bazen komutun tam çıktısını döndürür. Bazen hiç bağlanmaz.

Denemek için başka şeyler hakkında öneriler?

Bazı komutları başarıyla yürütebildiğimi fark ettim: örneğin, bir düzine kez veya daha fazla dönüşe çarpmak tamam. cd ~ve sonra lfolduğu gibi çalışır df -h. dfBirçok kez başarılı bir şekilde çalıştırabilirim, ancak daha fazla çıktı ile bir şey denediğimde (örneğin ls /etc) kilitlenir.

OpenVPN kullanarak bu iki ana bilgisayar arasında iletişim kurmaya çalıştığım bir fark yaratıyor mu?

networking ip openvpn

— ethrbunny
kaynak

Yol MTU'nuzun yapılandırılmış MTU arayüzünüzden daha düşük olmadığından emin olun. SSH parçalanmaz, bu nedenle DF biti ayarlandığında paketler düşer. Daha ayrıntılı bir açıklama için bunu okuyun .

— Aaron Copley

Görünür bir etki olmadan tüm arayüzlerde MTU'nun 1400'e ayarlanması denendi. Test edilen ping -c 1 -s $((5000-28)) -M do machine-ip1500 ile döndü - makine ile aynı

— ethrbunny

tracepath -n <ip>bunu onaylar: 1500'e izin verilir.

— ethrbunny

Cehaletimi affedin, ama -Tbu durumda nasıl yardımcı olur?

— Aaron Copley

<İkinci paragrafı okur> Bu bir MTU sorunudur. <Daha fazla bilgi> Evet, MTU sorunu. Açıklama için bu konuya bakın . Diğer iş parçacığının tartışılmadığı bir nokta var: sorunu çözmek için VPN yapılandırmanızda değiştirmeniz gereken şey olduğu için kopya olarak kapatmak için oy vermiyorum.

— Gilles 'SO- kötü olmayı bırak'

Yanıtlar:

Bir MTU sorununun belirtileri var : bazı TCP bağlantıları donuyor, belirli bir komut veya URL için az çok tekrarlanabilir, ancak kolayca ayırt edilebilen bir genel kalıp yok. Bir belirti belirtisi, etkileşimli ssh oturumlarının büyük çıktı ile komutları çalıştırmadığınız sürece iyi çalışmasıdır. Açıklama için bkz . Linux'ta belirli https sitelerine PPPoE üzerinden erişilemiyor .

OpenVPN'in MTU ile ilgili birkaç seçeneği vardır - kılavuzda “mtu” arayın. Hangi seçeneği değiştirmeniz gerektiğinden emin olmak için yeterli tecrübem yok. (Wimax modem yapılandırmasında bir şeyi değiştirebilmeniz bile mümkündür.) En olası değişiklik şudur mssfix: Sorunu çözene kadar değeri düşürmeyi deneyin. Varsayılan değer 1450'dir; 1400 gibi bir şey sorununuzu çözebilir. Deneyin openvpn --fragment 1200 -mssfix; eğer yardımcı olursa, kırılmaya başlayana kadar değeri artırın.

— Gilles 'SO- şeytan olmayı bırak'
kaynak

mssfix 1200Sunucuda ayarlayıp yeniden başlayarak başlıyorum . Çok uzak çok iyi. Bu işe yararsa, 1300 veya 1400'e kadar yapacağım ve ne olacağını göreceğim. Tüm uzak yapılandırmaları değiştirmek için çok fazla istemci olsa da, sunucu tarafı yapmak zorunda kalacak.

— ethrbunny

Ben biliyordum o MTU oldu!

— Aaron Copley

Gilles'in cevabı tamamen doğrudur, ancak bunun başka bir olası nedeni daha vardır.

OpenVPN'in 2.3.0 sürümünde, büyük miktarda veri gönderirken istemcilerin bağlantısını kesecek bir hata oluştu: https://community.openvpn.net/openvpn/ticket/263

Bu sorun yalnızca TCP kullanılırken ortaya çıktı. UDP tamamen etkilenmedi.

— Patrick
kaynak

Aynı sorunu yaşadık ve bu gerçekten bir MTU sorunuydu. Ancak bizim için sorun openVPN konfigürasyonunda değil tun0 arayüzündeydi.

Nasıl çözdük: önce gelen maksimum paket boyutunu bulun

ping <host> -s 1500 -M do

ve bir değer geçene kadar 1500 değerini azaltmak (bizim için 1350).

Doğru değer bulunduğunda, tun0 arayüzünü

sudo ip link set dev tun0 mtu 1350

burada Sebastian tarafından önerildiği gibi . Bundan sonra VPN sorunsuz gidiyordu.

— Eino Gourdin
kaynak