Uma porta encaminhada por SSH nem sempre é um proxy SOCKS
Distinga um encaminhamento local SSH fixo de um ouvinte SOCKS dinâmico antes de configurar uma aplicação.
Cria um túnel SSH, introduz 127.0.0.1 e a respetiva porta nas definições de proxy do navegador e nada carrega. O ouvinte pode estar a funcionar perfeitamente. Pode estar apenas à espera do tipo errado de tráfego.
| Encaminhamento | O que a aplicação local envia | Escolha do destino |
|---|---|---|
-L | O protocolo habitual do serviço de destino | Fixado no comando SSH |
-D | Uma negociação SOCKS e depois o tráfego da aplicação | Pedido pelo cliente SOCKS |
Para um único servidor web, isto é um encaminhamento fixo:
ssh -N -L 127.0.0.1:9080:web.example.com:80 [email protected]Visite http://127.0.0.1:9080/ como site. Não rotule a porta 9080 como SOCKS: encaminha bytes para o único servidor web indicado no comando. Abrir um site com outro nome de anfitrião também pode afetar o alojamento virtual, os redirecionamentos ou os cookies.
Para um ouvinte SOCKS, a forma muda:
ssh -N -D 127.0.0.1:1080 [email protected]Configure a aplicação para usar SOCKS em 127.0.0.1:1080. Introduzir esse endereço diretamente na barra de endereços do navegador envia um pedido web para um ouvinte SOCKS, outra incompatibilidade de protocolo.
O manual do OpenSSH documenta ambas as formas. Existe uma exceção útil: encaminhar um proxy HTTP existente com -L produz uma porta local que fala o protocolo de proxy HTTP, porque o seu destino fixo é ele próprio um proxy HTTP. É o serviço do extremo remoto que determina o que pertence a um encaminhamento fixo. Encaminhar um proxy existente por SSH preserva o protocolo e a conta desse proxy.