Redirección local por SSH a un proxy HTTP existente: dos direcciones de loopback

Tu proxy aprobado se ejecuta en un host de salto donde solo escucha en loopback, así que nada fuera de esa máquina puede alcanzarlo. No necesitas una VPN ni un proxy nuevo; necesitas un puerto de esa máquina llevado a un puerto tuyo. Una redirección local hace exactamente eso, y solo requiere un comando y un ajuste de la aplicación. La confusión suele venir de mezclar qué dirección de loopback pertenece a qué máquina.

Decide si ya existe un proxy fijo

Esta técnica redirige un servicio que ya se está ejecutando. Si el host remoto solo tiene un demonio SSH y ningún proxy, ninguna cantidad de redirección creará uno, y la conexión se rechazará desde el lado remoto. Confirma que el proxy está vinculado, cuál es su puerto y si escucha en 127.0.0.1 o en una dirección de interfaz concreta, porque esa dirección es la que debe apuntar la redirección.

Confirmarlo primero te ahorra depurar un túnel que nunca estuvo conectado a nada.

Construye la redirección y lee el comando

La forma que quieres vincula un puerto de loopback en tu portátil y lo conecta, desde el lado del servidor, a la dirección del proxy tal como la ve el servidor.

ssh -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:13128:127.0.0.1:3128 [email protected]

-N suprime un comando remoto y -T suprime la asignación de termios, porque quieres un túnel y no un shell. La primera dirección de loopback es donde escucha el portátil; la segunda se resuelve desde el servidor SSH, así que 127.0.0.1 allí significa el proxy de esa máquina. ExitOnForwardFailure hace que el comando falle ruidosamente si el puerto local ya está ocupado, en lugar de iniciar una sesión que no redirige nada. Escribe la dirección de destino tal como la resuelve el servidor, porque un nombre que solo tu portátil puede resolver fallará en el otro extremo.

La política del propio servidor se aplica antes de que algo de esto funcione. AllowTcpForwarding debe permitirlo, y PermitOpen puede restringir a qué destinos y puertos puede llegar una sesión, así que una redirección que el cliente acepta aún puede ser rechazada por el servidor. El rechazo aparece como un error de redirección o de canal en el cliente, y leer ese mensaje es más rápido que editar el comando.

Apunta una aplicación a la redirección

Configura la aplicación para usar un proxy HTTP en http://127.0.0.1:13128, con credenciales si el proxy remoto las exige. Mantén la verificación de certificados propia de la aplicación para destinos HTTPS, ya que el túnel del proxy no la sustituye. Esta es una redirección fija de un servicio, así que hay que decirle a la aplicación que existe un proxy en lugar de dejarla descubrirlo.

Una comprobación rápida antes de configurar nada permanente: curl -x http://127.0.0.1:13128 -I https://example.com, que ejercita el método HTTP CONNECT que el proxy debe admitir.

Mantén la autoridad donde estaba

El proxy remoto sigue decidiendo qué destinos y métodos permite, y un inicio de sesión SSH no debería conceder en silencio un relé web general a cada cuenta. Vincular a 127.0.0.1 en el portátil evita publicar el puerto en tu red local, y no hace que el puerto sea privado frente a otros procesos de la misma máquina. Sustituir esa vinculación por una dirección wildcard para compartir el proxy es como se crea un relé abierto no gestionado.

El transporte SSH protege el salto hasta el servidor. Más allá de ese punto el proxy abre su propia conexión, así que una petición HTTP simple a un destino sigue siendo simple más allá del servidor, aunque el primer tramo estuviera cifrado.

Verifica ambos extremos y luego limpia

La configuración del túnel local y el éxito del servicio remoto son resultados distintos, y el estado de salida del comando solo te habla del primero. Comprueba que el oyente existe con ss -ltn, y luego haz una petición permitida de la aplicación y una petición que el proxy debería rechazar. Si ambos se comportan como se espera, el camino es real; si el túnel está activo y toda petición falla, el proxy está rechazando o no puede llegar al destino.

Cuando termines, detén el proceso SSH que lo posee, elimina el ajuste de proxy de la aplicación y confirma que el puerto local desapareció en lugar de dejar un oyente que sobreviva a la tarea.