Czy są wady tunelowania SSH?

Niedawno „kupiłem” VPS, którego chcę używać jako proxy, aby móc korzystać z niektórych stron i rzeczy, do których nie mogę dotrzeć z Niemiec.

Ponieważ byłem zbyt leniwy, aby skonfigurować Squid i OpenVPN (co obecnie uważam za potrzebne), używam tunelowania ssh.

Teraz po kilku tygodniach zadałem sobie pytanie, czy tunelowanie ssh nie jest po prostu w porządku, czy - i to jest moje pytanie - czy są jakieś zastrzeżenia / wady / wady, o których muszę pamiętać?

ssh proxy ssh-tunneling

— Nils Riedemann
źródło

Jeśli chodzi o wartość, OpenVPN jest niezwykle łatwy do skonfigurowania za pomocą klucza statycznego, jeśli przechodzisz z Linuksa na Linuksa. Jest to trochę trudniejsze, jeśli jedna z twoich maszyn ma system Windows, ale jest wykonalna. bit.ly/ujkD2

— tranzystor1

Odpowiedzi:

Problem z wydajnością powstaje podczas tunelowania TCP przez TCP, ponieważ dwie warstwy wykonują korekty adaptacyjne (powolny start, unikanie zatorów, szybka transmisja, patrz RFC2001 ).

Nie znając się nawzajem, napotkają wielkie trudności, jeśli stracisz połączenie zewnętrzne.

Ta strona szczegółowo opisuje to zjawisko.

edytować:

Zamiast trzymać się problemu TCP przez TCP, spójrz na sshuttle, który mu zapobiega.
Zajrzyj do sekcji o nazwie „ Teoria działania ”, aby uzyskać więcej informacji na temat tej sytuacji.

— Shadok
źródło

Czy wewnętrzna warstwa nie wie, że rozmawia z interfejsem sprzężenia zwrotnego?

— Random832,

W twoim pytaniu problem polega na tym, że TCP nie obsługuje wyłączania tych „optymalizacji”, nawet jeśli w jakiś sposób był „świadomy swojej pozycji” jako wewnętrznego strumienia, nie może nic zrobić. Problem polega na tym, że zewnętrzne zachowanie adaptacyjne zakłóci działanie wewnętrzne, które spróbuje się przystosować, na przykład spowalniając retransmisję, chociaż zewnętrzny strumień TCP już się do tego dostosowuje.

— Shadok,

Myślałem o przypadku, w którym jest to normalne tunelowane połączenie TCP, a nie „TCP przez IP przez PPP przez TCP” - w takim przypadku tak naprawdę nie ma drugiego stosu protokołu TCP - ssh po prostu przesyła strumień bajtów. I nie miałem na myśli „świadomej jego pozycji jako wewnętrznego strumienia”, miałem na myśli, jak w tej sytuacji będzie miał interfejs pętli zwrotnej (lokalny port nasłuchuje) jako miejsce docelowe.

— Random832,

OP mówił o „niektórych witrynach”, zakładałem, że robi HTTP przez SocksV5 przez SSH, co oznacza, że robi TCP przez TCP (sam SSH to TCP, a HTTP wewnątrz tunelu przepływa przez inne strumienie TCP, które są enkapsulowane w SSH).

— Shadok

@Shadok Jestem pewien, że twoje wnioski nie są prawdziwe. apenwarr miał na myśli tun/taptunelowanie, które skutkuje tcp-over-tcp. SOCKSv5 nie cierpi z powodu tych samych problemów, ale nie działa transparentnie ze wszystkimi aplikacjami (podczas gdy tun / tap jest tylko kolejnym interfejsem sieciowym, więc można go obsługiwać w przejrzysty sposób).

— jpc

Jedyną rzeczą, o której mogę myśleć z umysłu, jest wydajność. Ale to naprawdę zależy od tego, jakie rzeczy tunelujesz.

— Marcus
źródło

Jakiego rodzaju wydajność? Pasmo? Obecnie używam go, aby uzyskać dostęp do hulu i niektórych zablokowanych filmów na YouTube.

— Nils Riedemann,

Najprawdopodobniej obciążenie procesora (szyfrowanie) i prawdopodobnie opóźnienie.

— XTL

Zwykle stwierdziłem, że opóźnienie wzrasta, ale przepustowość jest w porządku (90%) normalna w przypadku tunelowania SSH. Pamiętaj, aby ustawić, ServerAliveIntervalaby zapobiec rozłączaniu, i zawiń go w skrypcie, aby ponownie uruchamiał tunel po awarii.

Główną wadą jest to, że jest to tunel portu na TCP, chyba że używasz SOCKS. SOCKS jest w porządku, ale opóźnienie wydaje się z nim jeszcze bardziej zwiększać, i oczywiście nie każdy klient obsługuje SOCKS.

Może być konieczne uruchomienie GatewayPortsna kliencie lub serwerze SSH, aby umożliwić innym łączenie się przez twój tunel. Na serwerze wymaga to dostępu root do sshd_config.

Głównym zastrzeżeniem dotyczącym wydajności (jak zauważają inni) jest to, że niewiarygodne połączenia prawdopodobnie nie radzą sobie dobrze z tym podejściem, ponieważ algorytmy TCP nie reagują dobrze w przypadku enkapsulacji.

To powiedziawszy, SSH wydaje się „robić właściwie” przez większość czasu.

— Stu Charlton
źródło

Problem z niewiarygodnymi połączeniami, które obserwujesz, jest prawdopodobnie związany ze zwiększonym opóźnieniem i uściskami dłoni, które należy powtórzyć po zerwaniu połączeń. Przekazywanie portów SSH nie wykonuje enkapsulacji tcp-over-tcp.

— JPC