Alcançar um proxy HTTP ou SOCKS existente através de SSH
Alcance um proxy HTTP ou SOCKS loopback remoto através de SSH sem expor o respetivo listener publicamente.
Se relay.example.net já executa SOCKS no seu próprio 127.0.0.1:1080, encaminhe o acesso em vez de expor esse listener publicamente:
ssh -N -L 127.0.0.1:1081:127.0.0.1:1080 [email protected]| Ponto final | Função |
|---|---|
Portátil 127.0.0.1:1081 | O endereço SOCKS a configurar na aplicação do portátil. |
Retransmissor 127.0.0.1:1080 | O proxy existente alcançado do lado do servidor SSH. |
A sintaxe de reencaminhamento local atribui o destino fixo ao lado do servidor. Um proxy HTTP na porta loopback remota 3128 ou um ponto final de intranet como proxy.internal.example:8080 funciona pelo mesmo princípio. Configure o cliente para esse protocolo HTTP existente e a conta; transportá-lo por SSH não cria SOCKS nem um listener HTTPS com TLS.
O serviço existente continua a escolher as versões de protocolo suportadas, a autenticação, os destinos e a saída final. Se outro processo SSH criou esse proxy remoto, ambos os processos têm de permanecer ativos. Uma rota portátil→retransmissor→gateway deixa o site ver a última ligação de saída, não uma identidade atribuída pela porta local 1081.
Mantenha a ligação do portátil explicitamente local. Uma exposição mais ampla altera quem consegue alcançar o serviço, e o início de sessão SSH não acrescenta uma palavra-passe SOCKS ao listener. Em caso de recusa, verifique o listener do portátil, o transporte SSH e o proxy remoto como etapas separadas.