sshuttle frente a una VPN completa: qué cubre realmente su método

sshuttle se elige porque SSH ya funciona y la criptografía resulta familiar, y ese razonamiento omite la única pregunta que decide si encaja. Qué paquetes salen de la máquina, qué cuenta los transporta al otro lado y cuánto privilegio local exige la herramienta. Esas tres respuestas cambian según el método de reenvío, así que una configuración que funciona para una aplicación puede fallar en silencio para la siguiente. El recorrido de abajo empieza por el protocolo que la aplicación necesita de verdad.

Empiece por el protocolo que necesita la aplicación

El soporte de protocolos en sshuttle 2.0 depende del método que elija. Los métodos NAT y nft de Linux manejan TCP y DNS, y TPROXY añade UDP general. Cada plataforma y cada método traen sus propios límites, y macOS intercepta mediante un mecanismo completamente distinto. Anote la versión instalada, el método elegido y los protocolos que necesita la aplicación antes de elegir nada.

Por tanto, una petición TCP que funcione demuestra muy poco sobre una aplicación UDP o sobre cada consulta DNS. sshuttle también trata TCP como flujos en lugar de tunelizar paquetes IP enteros, así que una conclusión de rendimiento tomada de una VPN convencional no se traslada. Compare el mecanismo que ejecuta realmente con la carga que realmente tiene.

Qué necesita el cliente localmente

La disposición documentada del cliente requiere root o sudo, porque instala reglas locales de interceptación en vez de crear una interfaz de túnel. Ese único hecho cambia la historia de seguridad: un proceso con ese privilegio puede redirigir el tráfico de toda la máquina, no solo el de una aplicación. Trate el privilegio como parte del diseño y no como un detalle de instalación.

Confirme qué reglas instaló la herramienta y que desaparecen al salir. Una sesión que se caiga y deje reglas de interceptación puede enviar el tráfico a un agujero negro mucho después de que el operador crea que la conexión se ha ido, y el síntoma parece una avería de red y no una regla sobrante.

sudo sshuttle --method nft --dns 172.19.4.0/24
nft list ruleset | grep -i sshuttle
ip route

El primer comando es la forma de una invocación típica, con el prefijo que realmente necesita. El segundo muestra qué instaló la herramienta, y el tercero confirma que no apareció ninguna interfaz de túnel, que es el resultado esperado para este diseño.

Qué ejecuta el lado remoto

El lado remoto es una cuenta SSH autorizada más un entorno de ayudante de Python compatible. Un inicio de sesión que funciona en un shell restringido no concede automáticamente permiso para ejecutar ese ayudante, y una cuenta que puede ejecutar el ayudante no llega automáticamente a cada servicio de destino. Ambos hechos pertenecen a la solicitud de acceso y no a las notas de resolución de problemas.

Proteja la verificación de la identidad del host y la autenticación de la cuenta. Aceptar una clave de host desconocida para que funcione la primera conexión elimina la comprobación de que el lado remoto es la máquina que usted pretendía, y eso aquí importa más que en un reenvío de un solo propósito.

Limite la cuenta remota a los servicios que necesita el flujo de trabajo y negocie ese alcance con quienes operan el host. Forman parte de la relación de confianza, y ningún ajuste del lado del cliente cambia eso.

Dónde está la frontera de confianza

Reenviar una conexión de API privada por SSH no autoriza cada operación de API. El TLS de la aplicación y el inicio de sesión en la aplicación siguen aplicándose, y la herramienta no puede hacer seguro un servicio sin autenticación. Un salto adicional desde el host remoto tampoco es automáticamente el mismo segmento protegido que el canal SSH, porque esa segunda conexión sigue la política que tenga el host remoto.

Escriba la frontera en una frase: el tráfico hacia estos prefijos sale por esta cuenta en aquel host. Si la frase necesita un párrafo de excepciones, el diseño hace más de lo que afirma su documentación y merece una segunda mirada antes de llegar a producción.

Demuéstrelo por protocolo y luego elija la herramienta

Pruebe cada protocolo necesario con una petición inocua, incluido el camino del resolutor y las familias de direcciones que usa la aplicación. Incluya una desconexión en la prueba, para que el comportamiento de fallo permitido de la aplicación sea un resultado conocido y no una sorpresa durante un incidente. Una sesión que reenviaba correctamente mientras estaba activa no dice nada sobre qué ocurre cuando cae.

Para un puñado de servicios nombrados explícitamente, un reenvío local corriente es más fácil de poseer y de auditar. Para el tráfico de aplicaciones que encaja con su método, sshuttle ofrece un término medio legítimo. Cuando el requisito es conectividad IP amplia, el diseño de VPN es la respuesta honesta, y la elección sigue la cobertura y la responsabilidad operativa y no una clasificación de algoritmos de cifrado.