Reenvío dinámico SSH como proxy SOCKS sobre su VPN

Una aplicación que solo habla SOCKS no tiene con qué hablar en una VPN corriente, porque el túnel transporta paquetes y la aplicación quiere un extremo de proxy. OpenSSH puede proporcionar ese extremo cuando el propietario del acceso lo permite, ya que el reenvío dinámico convierte una sesión SSH en un proxy local. Después hay dos saltos que hay que mantener separados: el túnel que llega al host SSH y la conexión que ese host abre a continuación. Separarlos explica tanto por qué funciona la disposición como qué no hará nunca.

En qué se convierte el escucha SSH y en qué no

El reenvío dinámico hace que el cliente SSH escuche localmente y hable SOCKS4 o SOCKS5 con todo lo que se conecte. Cada solicitud nombra un destino y el servidor SSH abre la conexión siguiente, por eso la consulta del destino puede ocurrir en el lado remoto. Eso es reenvío TCP a nivel de aplicación, no una VPN para todo el dispositivo. No transporta ninguna asociación UDP, ni ICMP, ni nada para aplicaciones que ignoran por completo los ajustes de proxy. El salto del servidor SSH a la aplicación tampoco está dentro de su túnel, lo que importa cuando el destino acepta tráfico solo de redes conocidas.

Los requisitos previos son reales: una ruta hasta el host SSH, una cuenta autorizada, una clave de host del servidor verificada y permiso para reenviar. Ninguno lo crea el proxy, y el último suele ser el primero que falta. Confirme los cuatro antes de depurar cualquier otra cosa, porque el fallo se ve igual desde el cliente, falte el que falte.

Inícielo en loopback con un puerto explícito

Elija un puerto local sin usar y fíjelo explícitamente a loopback en lugar de dejar la dirección sin especificar. Las tres opciones de abajo existen cada una por un motivo.

ssh -D 127.0.0.1:1080 -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  [email protected]

-N omite el comando remoto y -T omite el pseudoterminal, así que la sesión existe solo para reenviar. ExitOnForwardFailure hace que el cliente salga cuando no se puede crear el escucha, en lugar de ejecutarse sin el reenvío que pidió. ControlPath=none mantiene la sesión fuera de una conexión multiplexada existente que podría añadir sus propios reenvíos. Loopback mantiene el escucha fuera de la LAN, pero en una máquina compartida no es una frontera de autorización, porque otros procesos locales también pueden alcanzarlo. La referencia del cliente OpenSSH documenta todas estas opciones, y el aviso de loopback se deduce de qué es un socket que escucha.

Envíe los nombres a través del proxy, no alrededor de él

Un cliente SOCKS5 puede resolver el destino por sí mismo o pedirle al proxy que lo haga, y esa elección decide qué resolución responde. Con socks5h, curl envía el nombre de host a través del proxy, así que la consulta ocurre en el servidor SSH. Con socks5 simple, el portátil resuelve primero y solo viaja la conexión, lo que anula en silencio el objetivo cuando el nombre es interno. La solicitud de abajo también vacía la lista de sin-proxy, así que un valor heredado de NO_PROXY no puede encaminarla alrededor del proxy.

curl -sS --noproxy '' --proxy socks5h://127.0.0.1:1080 https://app.corp.example/health

La validación del certificado y el inicio de sesión propio de la aplicación siguen aplicándose, porque el proxy no sustituye a ninguno de los dos. Quedan dos consultas: el portátil debe llegar al host SSH por la ruta permitida de VPN y DNS, y el servidor SSH debe resolver por su cuenta el nombre de la aplicación. La segunda se puede probar por separado antes de que ningún tráfico pase por el proxy.

ssh [email protected] getent hosts app.corp.example

Demuestre un destino permitido y luego cierre la sesión

Pruebe un destino que la política permite y uno que debería rechazar, porque un reenvío que funciona solo demuestra que el escucha funciona y nada más. La aplicación ve la dirección de origen que elige el servidor SSH, que no es la dirección del túnel de su portátil. Donde el extremo remoto registra las conexiones por origen, esa diferencia es lo primero que hay que mirar cuando se rechaza una solicitud.

Detenga la sesión a través del proceso que la posee en lugar de matar un shell no relacionado. Luego confirme que el escucha desapareció, porque un puerto que aún responde es una sesión que no ha cerrado de verdad. Retire solo el ajuste de proxy que introdujo este ejercicio y deje el resto de la configuración de la aplicación en paz. Un terminal desatendido con una regla de reenvío no es un servicio, y un proxy permanente necesita un ciclo de vida aprobado, no una ventana olvidada.

ss -ltn | grep 1080

Fallos que esta disposición no puede arreglar

Algunos síntomas apuntan directamente a los límites de arriba, y reconocerlos pronto ahorra una tarde de depuración del proxy. La tabla relaciona lo que ve con lo que suele significar. Cualquier cosa de la última columna es una cuestión de diseño, no un error de configuración.

Las tres primeras filas son las que la gente diagnostica mal, porque cada una produce un intento de conexión en lugar de un error sobre el propio proxy. Un nombre que se resuelve en el portátil no dice nada sobre el resolutor del servidor, y el fallo se lee en cambio como un problema de certificado o de tiempo de espera. Las aplicaciones solo UDP quedan fuera del diseño, no rotas dentro de él, y ninguna opción ssh adicional lo cambia. La fila del navegador es el recordatorio habitual de que los ajustes de proxy son por aplicación. La última fila es la razón por la que existe la comprobación de cierre: un puerto que sigue escuchando significa que ahora lo posee otra cosa.