Raggiungere un proxy HTTP o SOCKS esistente tramite SSH
Raggiungi un proxy HTTP o SOCKS loopback remoto tramite SSH senza esporre pubblicamente il suo listener.
Se relay.example.net esegue già SOCKS sul proprio 127.0.0.1:1080, inoltra l'accesso invece di esporre pubblicamente quel listener:
ssh -N -L 127.0.0.1:1081:127.0.0.1:1080 [email protected]| Endpoint | Ruolo |
|---|---|
Portatile 127.0.0.1:1081 | L'indirizzo SOCKS da configurare nell'applicazione del portatile. |
Relè 127.0.0.1:1080 | Il proxy esistente raggiunto dal lato del server SSH. |
La sintassi di inoltro locale assegna la destinazione fissa al lato server. Un proxy HTTP sulla porta loopback remota 3128 o un endpoint intranet come proxy.internal.example:8080 funziona con lo stesso principio. Configura il client per quel protocollo HTTP esistente e l'account; trasportarlo tramite SSH non crea SOCKS né un listener HTTPS abilitato a TLS.
Il servizio esistente sceglie ancora le versioni di protocollo supportate, l'autenticazione, le destinazioni e l'uscita finale. Se un altro processo SSH ha creato quel proxy remoto, entrambi i processi devono restare attivi. Un percorso portatile→relè→gateway lascia che il sito web veda l'ultima connessione in uscita, non un'identità assegnata dalla porta locale 1081.
Mantieni il binding del portatile esplicitamente locale. Un'esposizione più ampia cambia chi può raggiungere il servizio, e l'accesso SSH non aggiunge una password SOCKS al listener. In caso di rifiuto, controlla il listener del portatile, il trasporto SSH e il proxy remoto come fasi separate.