Una porta inoltrata via SSH non è sempre un proxy SOCKS
Distinguere un inoltro locale SSH fisso da un listener SOCKS dinamico prima di configurare un'applicazione.
Create un tunnel SSH, inserite 127.0.0.1 e la sua porta nelle impostazioni proxy del browser e non si carica nulla. Il listener potrebbe funzionare perfettamente. Forse sta solo aspettando il tipo sbagliato di traffico.
| Inoltro | Cosa invia l'applicazione locale | Scelta della destinazione |
|---|---|---|
-L | Il protocollo usuale del servizio di destinazione | Fissato nel comando SSH |
-D | Una negoziazione SOCKS, poi il traffico dell'applicazione | Richiesto dal client SOCKS |
Per un singolo server web, questo è un inoltro fisso:
ssh -N -L 127.0.0.1:9080:web.example.com:80 [email protected]Visitate http://127.0.0.1:9080/ come sito web. Non etichettate la porta 9080 come SOCKS: inoltra byte all'unico server web indicato nel comando. Aprire un sito con un altro nome host può anche influire sul suo hosting virtuale, sui reindirizzamenti o sui cookie.
Per un listener SOCKS, la forma cambia:
ssh -N -D 127.0.0.1:1080 [email protected]Configurate l'applicazione per usare SOCKS su 127.0.0.1:1080. Digitare quell'indirizzo direttamente nella barra degli indirizzi del browser invia una richiesta web a un listener SOCKS, un'altra incompatibilità di protocollo.
Il manuale di OpenSSH documenta entrambe le forme. Esiste un'eccezione utile: inoltrare un proxy HTTP esistente con -L produce una porta locale che parla il protocollo proxy HTTP, perché la sua destinazione fissa è essa stessa un proxy HTTP. È il servizio all'altro capo a determinare cosa appartiene a un inoltro fisso. Inoltrare un proxy esistente tramite SSH conserva il protocollo e l'account di quel proxy.