Proxy SOCKS por SSH en Android: por qué solo se conecta la mitad de tus aplicaciones

Inicias sesión por SSH, añades -D 1080 y el comando funciona. Ahora existe un escucha SOCKS en el teléfono, y la mitad de las aplicaciones siguen saliendo por datos móviles. Ese es el resultado normal, no un túnel roto: ssh -D crea un punto de proxy, y las aplicaciones Android solo usan un proxy si algo las obliga. Recorrer la cadena paso a paso muestra dónde vive realmente cada pieza del trabajo.

Empieza donde empieza el tráfico

Elige una aplicación que debería usar el túnel y comprueba si tiene su propio ajuste de proxy. Un navegador con campo SOCKS es el caso fácil: apúntalo a 127.0.0.1:1080, activa el DNS remoto si el ajuste existe, y la petición pasa. Un cliente de chat, una app de mapas o un juego sin ese campo no tienen forma de usar el escucha, y nada de lo que escribas en el comando SSH lo cambia.

Antes de implicar nada más, demuestra que el escucha funciona desde el propio shell del teléfono con un cliente que hable SOCKS directamente:

ssh -N -D 1080 [email protected]
curl --socks5-hostname 127.0.0.1:1080 https://ifconfig.me

La dirección que vuelve debería ser la del servidor SSH, no la del teléfono. Si lo es, la mitad del proxy está hecha y el resto del trabajo va de cobertura. Si no, arregla primero el lado SSH: autenticación por clave, la capacidad del servidor de alcanzar el destino y la salida propia del servidor SSH.

Añade la pieza que Android necesita

Las aplicaciones sin ajuste de proxy necesitan algo que capture sus paquetes y los convierta en conexiones proxy. En un dispositivo sin root, eso es un adaptador de servicio VPN: una app que toma la interfaz virtual y reenvía el tráfico seleccionado al escucha SOCKS local. La cadena pasa a ser app, adaptador, escucha SOCKS, conexión SSH, destino.

Instala el adaptador, concédele el permiso de VPN y elige las apps o rutas que debe capturar. El icono de llave de la barra de estado representa entonces al adaptador, no a una VPN comercial aparte. Android permite una sola conexión de servicio VPN activa por perfil de usuario, así que abrir una segunda app VPN no añade una capa sobre la cadena: compite por el mismo papel.

Este es también el paso donde una prueba exitosa puede engañarte. Si el adaptador está configurado para capturar solo el navegador que ya apuntaste al proxy, todo funciona y nada más queda cubierto. Lee la lista de captura antes de concluir que el dispositivo está tunelizado.

Mantén el transporte SSH fuera de la captura

La propia conexión SSH no debe realimentarse al túnel SOCKS que mantiene. Si el adaptador captura el tráfico de la app SSH, el túnel depende de una conexión que espera al túnel, y el resultado es un bucle que se atasca o falla en cuanto arranca el adaptador.

Las implementaciones integradas protegen su propio socket de transporte. Con apps separadas necesitas una exclusión admitida: deja la app SSH fuera de la captura o excluye el extremo SSH por dirección. Ambas tienen costes. Excluir toda una app de terminal también saca del túnel su actividad de red no relacionada, y una excepción de dirección se rompe cuando cambia la dirección del servidor o cuando el nombre resuelve distinto en la siguiente conexión.

Comprueba la exclusión desde fuera: reconecta el adaptador y luego confirma que la sesión SSH sobrevive y que la petición proxificada sigue informando de la dirección del servidor. Una sesión que funciona hasta que arranca el adaptador y entonces se congela es el bucle.

Sigue DNS y UDP hasta el final de la cadena

El reenvío dinámico de OpenSSH transporta conexiones TCP. No es un transporte UDP-associate ni ICMP, y un adaptador no puede inventar reenvío UDP aceptando paquetes UDP. Todo lo que insiste en UDP, incluidos QUIC y los medios WebRTC, fallará o caerá a TCP según la app.

DNS necesita su propia decisión. Una app que resuelve un nombre localmente envía la consulta por el resolutor normal antes de conectar, así que el túnel transporta la conexión pero no la consulta. Un cliente consciente del proxy con opción de DNS remoto lo evita; una app capturada sin ella no. Comprueba qué resolutor respondió en vez de suponer que el adaptador lo cambió.

Mantén el escucha SOCKS ligado a loopback, verifica la clave de host del servidor SSH en el primer uso y deja la validación HTTPS normal en su sitio para el sitio final. SSH protege el tramo teléfono-servidor; no cifra lo que el servidor hace después.

Revisa las dos vidas y decide

El adaptador y la sesión SSH tienen vidas separadas. Si SSH cae mientras el adaptador sigue capturando, las apps pueden colgarse sin error evidente, porque sus paquetes siguen entrando en una interfaz virtual que ya no tiene salida funcional. Si el adaptador se detiene, las apps o van directas o quedan bloqueadas, según la política VPN del dispositivo.

Prueba ambas direcciones a propósito: mata la sesión SSH con el adaptador en marcha y luego detén el adaptador mientras SSH sigue vivo. Lo que hace el teléfono en cada caso es la política que realmente estás desplegando, digan lo que digan las instrucciones de instalación.

Si el flujo de trabajo necesita cobertura de todo el dispositivo con un modo de fallo predecible, una VPN IP real, o un adaptador mantenido y diseñado para esta cadena, es la respuesta honesta. Una sesión de shell dejada funcionando junto a una app de captura no relacionada no es un túnel de dispositivo mantenido; son dos componentes sin acuerdo sobre qué pasa cuando uno de ellos termina.