SSH tünellemesinde dezavantajlar var mı?

Kısa süre önce Almanya'dan ulaşamayacağım bazı siteleri ve şeyleri kullanabilmek için Proxy olarak kullanmak istediğim bir VPS aldım.

Squid ve OpenVPN'i kurmak için henüz tembel olduğumdan (şu anda gerekli olduğunu düşünüyorum) ssh-tünelleme kullanıyorum.

Birkaç hafta sonra kendime ssh-tünellemenin iyi olup olmadığını sordum ya da - ve bu benim sorum - aklımda olması gereken herhangi bir uyarı / kontra / dezavantaj varsa?

ssh proxy ssh-tunneling

— Nils Riedemann
kaynak

Ne kadar değerli olursa olsun, Linux'tan Linux'a gidiyorsanız, OpenVPN'i statik bir anahtar kullanarak kurmak son derece kolaydır. Makinelerinizden biri Windows, ancak yapılabilir olduğunda biraz daha zor. bit.ly/ujkD2

— transistör1

Yanıtlar:

Adaptif düzeltmeler yapan iki katmanınız (yavaş başlatma, tıkanıklıktan kaçınma, hızlı yeniden aktarım bkz RFC2001 ) olduğundan TCP'yi TCP üzerinden tünellediğinizde performans sorunu ortaya çıkar .

Dış bağlantıda kaybınız varsa, birbirlerinin farkında değiller, büyük zorluklar yaşayacaklardır.

Bu sayfa , fenomeni ayrıntılı olarak açıklamaktadır.

Düzenle:

TCP üzerinden TCP sorunu ile uğraşmak yerine bunu engelleyen sshuttle'a bir göz atın . Bu durum hakkında daha fazla bilgi için " Operasyon Teorisi
" başlıklı kısma bir göz atın .

— Shadok
kaynak

İç katman, geri döngü arayüzüyle konuştuğunu bilmiyor mu?

— Random832

Sorunuzla ilgili sorun, TCP'nin bu "optimizasyonları" devre dışı bırakmayı desteklememesi, bir şekilde bir iç akış olarak "konumunun farkında" olsa bile hiçbir şey yapamaz. Buradaki sorun, dış uyarlanabilir davranışın, örneğin dış TCP akışı zaten buna adapte olmasına rağmen, yeniden iletimi yavaşlatarak adapte olmaya çalışacak olan içsel davranışı bozacaktır.

— Shadok

Ben normal bir tünel TCP bağlantısı, "TCP üzerinden PPP üzerinden IP üzerinden TCP" değil bu durumda düşünüyordum - bu durumda aslında ikinci bir TCP protokol yığını yok - ssh sadece bir bayt akışı iletiyor. Ve "iç akış olarak konumunun farkında" demek istemedim, bu durumda hedef olarak nasıl bir geri döngü arayüzüne (yerel port ssh dinliyor) sahip olduğunu kastetmiştim.

— Random832

OP "bazı siteler" hakkında konuştu, SSH üzerinden SocksV5 üzerinden HTTP yaptığını varsaydım, yani TCP üzerinden TCP yapıyor (SSH'nin kendisi TCP ve tünelin içindeki HTTP SSH'de kapsüllenmiş olan başka bir TCP akışı üzerinden akıyor).

— Mart'ta Shadok

@Shadok Sonuçlarınızın doğru olmadığından eminim. apenwarr, tun/taptcp-over-tcp ile sonuçlanan tünele atıfta bulunuyordu . SOCKSv5 aynı sorunlardan muzdarip değildir, ancak tüm uygulamalarla şeffaf olarak çalışmaz (tun / tap sadece başka bir ağ arayüzüdür, bu nedenle şeffaf bir şekilde işlenebilir).

— jpc

Aklımdan aklıma gelen tek şey performans. Ama bu gerçekten ne tür şeylere tünel yaptığınıza bağlı.

— Marcus
kaynak

Ne tür bir performans? Bant genişliği? Şu anda hulu ve engellenen bazı youtube videolarına erişmek için kullanıyorum.

— Nils Riedemann

CPU ek yükü (şifreleme) ve muhtemelen gecikme süresi, büyük olasılıkla.

— XTL

Normalde gecikmenin arttığını buldum ancak SSH tünellemesinde verim normal (% 90) normal. ServerAliveIntervalBağlantı kesilmelerini önlemek için ayarladığınızdan emin olun ve hata durumunda tüneli yeniden başlatmaya devam etmek için komut dosyasına sarın.

Ana dezavantajı, SOCKS kullanmıyorsanız TCP başına bir port tüneli olmasıdır. SOCKS iyidir, ancak gecikme onunla daha da artmaktadır ve elbette her müşteri SOCKS'i desteklememektedir.

GatewayPortsBaşkalarının tünelinizden bağlanmasına izin vermek için istemci veya SSH sunucusunda çalıştırmanız gerekebilir . Sunucuda bu, sshd_config dosyasına kök erişimi gerektirir.

Ana performans uyarısı (diğerlerinin belirttiği gibi), TCP'nin algoritmaları kapsülleme altında iyi tepki vermediğinden, güvenilir olmayan bağlantıların muhtemelen bu yaklaşımla iyi sonuç vermemesidir.

Bununla birlikte, SSH çoğu zaman "doğru olanı yapıyor" gibi görünüyor.

— Stu Charlton
kaynak

Gözlemlediğiniz güvenilir olmayan bağlantılarla ilgili sorun, muhtemelen bağlantılar düştüğünde tekrarlanması gereken artan gecikme ve el sıkışmalarıyla ilgilidir. SSH bağlantı noktası iletme, tcp-tcp üzeri kapsülleme yapmaz.

— jpc