Ci sono degli svantaggi nel tunneling SSH?

Di recente ho "acquistato" un VPS che voglio usare come proxy per poter utilizzare alcuni siti e cose che non posso raggiungere dalla Germania.

Dato che ero ancora troppo pigro per configurare Squid e OpenVPN (che attualmente ritengo necessario) uso ssh-tunneling.

Ora dopo un paio di settimane mi sono chiesto se ssh-tunneling non andava bene, o - e questa è la mia domanda - se ci sono avvertenze / contras / svantaggi che devo tenere a mente?

ssh proxy ssh-tunneling

— Nils Riedemann
fonte

Per quello che vale, OpenVPN è estremamente facile da configurare usando una chiave statica se si passa da Linux a Linux. È un po 'più complicato se una delle tue macchine è Windows, ma fattibile. bit.ly/ujkD2

— transistor1

Risposte:

Il problema delle prestazioni si presenta quando si esegue il tunneling di TCP su TCP perché due livelli eseguono correzioni adattive (avvio lento, prevenzione della congestione, restrizione rapida, vedere RFC2001 ).

Non consapevoli l'uno dell'altro, sperimenteranno grandi difficoltà se si verifica una perdita sulla connessione esterna.

Questa pagina descrive il fenomeno in dettaglio.

modificare:

Invece di attenersi al problema TCP su TCP, dai un'occhiata a sshuttle che lo impedisce.
Dai un'occhiata alla sezione chiamata " Teoria dell'operazione " per ulteriori dettagli su questa situazione.

— Shadok
fonte

Lo strato interno non sa che sta parlando con l'interfaccia di loopback?

— Casuale 832

Per quanto riguarda la tua domanda, il problema è che TCP non supporta la disabilitazione di quelle "ottimizzazioni", anche se in qualche modo era "consapevole della sua posizione" come flusso interno non può fare nulla. Il problema qui è che il comportamento adattativo esterno interromperà quello interno, che proverà ad adattarsi rallentando la ritrasmissione, ad esempio, sebbene il flusso TCP esterno si stia già adattando per questo.

— Shadok,

Stavo pensando al caso in cui si tratta di una normale connessione TCP tunnel, non di "TCP su IP su PPP su TCP" - in tal caso non esiste in realtà un secondo stack di protocollo TCP - ssh sta semplicemente inoltrando un flusso di byte. E non intendevo "consapevole della sua posizione come flusso interno", intendevo come in questa situazione avrebbe un'interfaccia loopback (la porta locale su cui ssh è in ascolto) come destinazione.

— Casuale 832

OP ha parlato di "alcuni siti", supponevo che stesse facendo HTTP su SocksV5 tramite SSH, il che significa che stava facendo TCP su TCP (SSH stesso è TCP e l'HTTP all'interno del tunnel scorre su altri flussi TCP, che è incapsulato in SSH).

— Shadok,

@Shadok Sono abbastanza sicuro che le tue conclusioni non siano vere. apenwarr si riferiva al tun/taptunneling che si traduce in tcp-over-tcp. SOCKSv5 non presenta gli stessi problemi ma non funziona in modo trasparente con tutte le applicazioni (mentre tun / tap è solo un'altra interfaccia di rete, quindi può essere gestita in modo trasparente).

— jpc,

Una cosa che mi viene in mente fuori di testa è la performance. Ma dipende davvero dal tipo di cose che stai scavando.

— Marcus
fonte

Che tipo di esibizione? Larghezza di banda? Attualmente lo uso per accedere a hulu e ad alcuni video di YouTube che sono bloccati.

— Nils Riedemann,

Overhead della CPU (crittografia) e possibilmente latenza, molto probabilmente.

— XTL

Normalmente ho scoperto che la latenza aumenta, ma il throughput va bene (90%) normalmente con il tunneling SSH. Assicurati di impostare ServerAliveIntervalper impedire le disconnessioni e avvolgilo in uno script per continuare a riavviare il tunnel in caso di errore.

Lo svantaggio principale è che si tratta di un tunnel di porte per TCP, a meno che non si utilizzi SOCKS. SOCKS va bene, ma la latenza sembra aumentare ancora di più con esso e, naturalmente, non tutti i client supportano SOCKS.

Potrebbe essere necessario eseguire GatewayPortssul client o sul server SSH per consentire ad altri di connettersi attraverso il tunnel. Sul server questo richiede l'accesso come root a sshd_config.

Il principale avvertimento sulle prestazioni (come altri notano) è che le connessioni inaffidabili probabilmente non vanno bene con questo approccio, poiché gli algoritmi di TCP non reagiscono bene sotto l'incapsulamento.

Detto questo, SSH sembra "fare la cosa giusta" il più delle volte.

— Stu Charlton
fonte

Il problema con connessioni inaffidabili che si osserva è probabilmente correlato all'aumento della latenza e delle strette di mano che devono essere ripetute quando le connessioni cadono. Il port forwarding SSH non esegue l'incapsulamento tcp-over-tcp.

— jpc,