Llegar a un proxy HTTP o SOCKS existente mediante SSH
Llegue a un proxy HTTP o SOCKS remoto de loopback mediante SSH sin exponer públicamente su escucha.
Si relay.example.net ya ejecuta SOCKS en su propio 127.0.0.1:1080, reenvíe el acceso en lugar de exponer públicamente ese escucha:
ssh -N -L 127.0.0.1:1081:127.0.0.1:1080 [email protected]| Extremo | Función |
|---|---|
Portátil 127.0.0.1:1081 | La dirección SOCKS que se configura en la aplicación del portátil. |
Relé 127.0.0.1:1080 | El proxy existente al que se llega desde el lado del servidor SSH. |
La sintaxis de reenvío local asigna el destino fijo al lado del servidor. Un proxy HTTP en el puerto de loopback remoto 3128 o un extremo de intranet como proxy.internal.example:8080 funciona con el mismo principio. Configure el cliente para ese protocolo HTTP existente y la cuenta; transportarlo por SSH no crea SOCKS ni un escucha HTTPS con TLS.
El servicio existente sigue eligiendo las versiones de protocolo admitidas, la autenticación, los destinos y la salida final. Si otro proceso SSH creó ese proxy remoto, ambos procesos deben permanecer vivos. Una ruta portátil→relé→puerta de enlace deja que el sitio web vea la última conexión saliente, no una identidad asignada por el puerto local 1081.
Mantenga el enlace del portátil explícitamente local. Una exposición más amplia cambia quién puede llegar al servicio, y el inicio de sesión SSH no añade una contraseña SOCKS al escucha. Ante un rechazo, compruebe el escucha del portátil, el transporte SSH y el proxy remoto como etapas separadas.