En SSH-videresendt port er ikke altid en SOCKS-proxy
Skeln mellem en fast lokal SSH-videresendelse og en dynamisk SOCKS-lytter, før du konfigurerer et program.
Du opretter en SSH-tunnel, indtaster 127.0.0.1 og dens port i browserens proxyindstillinger, og intet indlæses. Lytteren kan fungere helt fint. Den venter måske bare på den forkerte slags trafik.
| Videresendelse | Hvad det lokale program sender | Valg af destination |
|---|---|---|
-L | Destinationsservicens sædvanlige protokol | Fastlåst i SSH-kommandoen |
-D | En SOCKS-forhandling, derefter programtrafik | Anmodet af SOCKS-klienten |
For én webserver er dette en fast videresendelse:
ssh -N -L 127.0.0.1:9080:web.example.com:80 [email protected]Besøg http://127.0.0.1:9080/ som et websted. Mærk ikke port 9080 som SOCKS: den videresender bytes til den ene webserver, der er nævnt i kommandoen. At åbne et websted under et andet værtsnavn kan også påvirke dets virtuelle hosting, omdirigeringer eller cookies.
For en SOCKS-lytter ændrer formen sig:
ssh -N -D 127.0.0.1:1080 [email protected]Konfigurer programmet til at bruge SOCKS på 127.0.0.1:1080. Indtaster du den adresse direkte i browserens adresselinje, sendes en webanmodning til en SOCKS-lytter, endnu et protokolmismatch.
OpenSSH-manualen dokumenterer begge former. Der er en nyttig undtagelse: at videresende en eksisterende HTTP-proxy med -L giver en lokal port, der taler HTTP-proxyprotokol, fordi dens faste destination selv er en HTTP-proxy. Tjenesten i den fjerne ende afgør, hvad der hører til en fast videresendelse. Videresendelse af en eksisterende proxy via SSH bevarer den proxies protokol og konto.