Un port reenviado por SSH non sempre é un proxy SOCKS
Distinga un reenvío local SSH fixo dun oínte SOCKS dinámico antes de configurar unha aplicación.
Crea un túnel SSH, introduce 127.0.0.1 e o seu porto na configuración de proxy do navegador e non se carga nada. Pode que o oínte funcione perfectamente. Pode que só estea esperando o tipo de tráfico equivocado.
| Reenvío | Que envía a aplicación local | Elección de destino |
|---|---|---|
-L | O protocolo habitual do servizo de destino | Fixado na orde SSH |
-D | Unha negociación SOCKS e despois o tráfico da aplicación | Solicitado polo cliente SOCKS |
Para un só servidor web, isto é un reenvío fixo:
ssh -N -L 127.0.0.1:9080:web.example.com:80 [email protected]Visita http://127.0.0.1:9080/ como sitio web. Non etiquetes o porto 9080 como SOCKS: reenvía bytes ao único servidor web indicado na orde. Abrir un sitio cun nome de host diferente tamén pode afectar o seu aloxamento virtual, as súas redireccións ou as súas cookies.
Para un oínte SOCKS, a forma cambia:
ssh -N -D 127.0.0.1:1080 [email protected]Configura a aplicación para usar SOCKS en 127.0.0.1:1080. Introducir ese enderezo directamente na barra de enderezos do navegador envía unha solicitude web a un oínte SOCKS, outro desaxuste de protocolo.
O manual de OpenSSH documenta ambas as formas. Hai unha excepción útil: reenviar un proxy HTTP existente con -L produce un porto local que fala o protocolo de proxy HTTP, porque o seu destino fixo é el mesmo un proxy HTTP. O servizo do extremo remoto determina que corresponde a un reenvío fixo. Reenviar un proxy existente por SSH conserva o protocolo e a conta dese proxy.