Un puerto reenviado por SSH no siempre es un proxy SOCKS
Distinga un reenvío local SSH fijo de un oyente SOCKS dinámico antes de configurar una aplicación.
Crea un túnel SSH, introduce 127.0.0.1 y su puerto en la configuración de proxy del navegador y no se carga nada. Puede que el oyente funcione perfectamente. Puede que solo esté esperando el tipo de tráfico equivocado.
| Reenvío | Qué envía la aplicación local | Elección de destino |
|---|---|---|
-L | El protocolo habitual del servicio de destino | Fijado en el comando SSH |
-D | Una negociación SOCKS y luego el tráfico de la aplicación | Solicitado por el cliente SOCKS |
Para un solo servidor web, esto es un reenvío fijo:
ssh -N -L 127.0.0.1:9080:web.example.com:80 [email protected]Visite http://127.0.0.1:9080/ como sitio web. No etiquete el puerto 9080 como SOCKS: reenvía bytes al único servidor web indicado en el comando. Abrir un sitio con otro nombre de host también puede afectar a su alojamiento virtual, sus redirecciones o sus cookies.
Para un oyente SOCKS, la forma cambia:
ssh -N -D 127.0.0.1:1080 [email protected]Configure la aplicación para usar SOCKS en 127.0.0.1:1080. Introducir esa dirección directamente en la barra de direcciones del navegador envía una petición web a un oyente SOCKS, otro desajuste de protocolo.
El manual de OpenSSH documenta ambas formas. Hay una excepción útil: reenviar un proxy HTTP existente con -L produce un puerto local que habla el protocolo de proxy HTTP, porque su destino fijo es a su vez un proxy HTTP. El servicio del extremo remoto determina qué corresponde a un reenvío fijo. Reenviar un proxy existente por SSH conserva el protocolo y la cuenta de ese proxy.