¿Hay desventajas en el túnel SSH?

12

Recientemente "compré" un VPS que quiero usar como Proxy para poder usar algunos sitios y cosas a las que no puedo acceder desde Alemania.

Como todavía era demasiado vago para configurar Squid y OpenVPN (que actualmente creo que es necesario), uso el ssh-tunneling.

Ahora, después de un par de semanas, me pregunté si la tunelización ssh no estaba bien, o, y esa es mi pregunta, si hay algunas advertencias / contras / inconvenientes que debo tener en cuenta.

ssh proxy ssh-tunneling Nils Riedemann
fuente
1
Para lo que vale, OpenVPN es extremadamente fácil de configurar usando una clave estática si va de Linux a Linux. Es un poco más complicado si una de sus máquinas es Windows, pero factible. bit.ly/ujkD2
transistor1

Respuestas:

11

El problema de rendimiento surge cuando está haciendo un túnel TCP sobre TCP porque tiene dos capas que realizan correcciones adaptativas (inicio lento, evitación de congestión, retransmisión rápida, ver RFC2001 ).

Si no se conocen entre sí, experimentarán grandes dificultades si tiene una pérdida en la conexión externa.

Esta página describe el fenómeno en detalle.

editar:

En lugar de quedarse con el problema TCP sobre TCP, eche un vistazo a sshuttle que lo impide.
Eche un vistazo a la sección llamada " Teoría de la operación " para obtener aún más detalles sobre esta situación.

Shadok
fuente
¿La capa interna no sabe que está hablando con la interfaz de bucle invertido?
Random832
Sobre su pregunta, el problema es que TCP no admite la desactivación de esas "optimizaciones", incluso si de alguna manera fuera "consciente de su posición" como una transmisión interna, no puede hacer nada. El problema aquí es que el comportamiento adaptativo externo interrumpirá el interno, que intentará adaptarse al reducir la retransmisión, por ejemplo, aunque el flujo TCP externo ya se está adaptando para eso.
Shadok
Estaba pensando en el caso en que es una conexión TCP tunelizada normal, no "TCP sobre IP sobre PPP sobre TCP", en ese caso no hay realmente una segunda pila de protocolos TCP: ssh solo reenvía una secuencia de bytes. Y no quise decir "consciente de su posición como un flujo interno", quise decir cómo en esta situación tendría una interfaz de bucle invertido (el puerto local ssh está escuchando) como su destino.
Random832
OP habló sobre "algunos sitios", supuse que estaba haciendo HTTP sobre SocksV5 a través de SSH, lo que significa que está haciendo TCP sobre TCP (SSH en sí mismo es TCP y el HTTP dentro del túnel fluye sobre otras corrientes TCP, que está encapsulado en SSH).
Shadok
1
@ Shadok Estoy bastante seguro de que tus conclusiones no son ciertas. apenwarr se refería al tun/taptúnel que da como resultado tcp-over-tcp. SOCKSv5 no sufre los mismos problemas, pero no funciona de forma transparente con todas las aplicaciones (mientras que tun / tap es solo otra interfaz de red, por lo que se puede manejar de forma transparente).
jpc
3

Una cosa que puedo pensar fuera de mi mente es el rendimiento. Pero eso realmente depende de qué tipo de cosas estás haciendo túneles.

Marcus
fuente
¿Qué tipo de desempeño? ¿Banda ancha? Actualmente lo uso para acceder a Hulu y algunos videos de YouTube que están bloqueados.
Nils Riedemann
Sobrecarga de la CPU (cifrado) y posiblemente latencia, muy probablemente.
XTL
1

Normalmente he descubierto que la latencia aumenta, pero el rendimiento es bueno (90%) de lo normal con el túnel SSH. Asegúrese de configurar ServerAliveIntervalpara evitar desconexiones y envuélvala en un script para continuar reiniciando el túnel en caso de falla.

El principal inconveniente es que es un túnel de puerto por TCP, a menos que use SOCKS. SOCKS está bien, pero la latencia parece aumentar aún más con él y, por supuesto, no todos los clientes admiten SOCKS.

Es posible que deba ejecutar GatewayPortsen el cliente o servidor SSH para permitir que otros se conecten a través de su túnel. En el servidor esto requiere acceso de root a sshd_config.

La principal advertencia de rendimiento (como otros señalan) es que las conexiones poco confiables probablemente no funcionen bien con este enfoque, ya que los algoritmos de TCP no reaccionan bien bajo la encapsulación.

Dicho esto, SSH parece "hacer lo correcto" la mayor parte del tiempo.

Stu Charlton
fuente
1
El problema con las conexiones poco confiables que observa probablemente esté relacionado con el aumento de la latencia y los apretones de manos que deben repetirse cuando las conexiones caen. El reenvío de puertos SSH no realiza la encapsulación tcp-over-tcp.
jpc