En SSH-videresendt port er ikke alltid en SOCKS-proxy
Skill mellom en fast lokal SSH-videresending og en dynamisk SOCKS-lytter før du konfigurerer et program.
Du oppretter en SSH-tunnel, legger inn 127.0.0.1 og porten i nettleserens proxyinnstillinger, og ingenting lastes. Lytteren kan fungere helt fint. Den venter kanskje bare på feil type trafikk.
| Videresending | Hva det lokale programmet sender | Valg av destinasjon |
|---|---|---|
-L | Destinasjonstjenestens vanlige protokoll | Låst i SSH-kommandoen |
-D | En SOCKS-forhandling, deretter programtrafikk | Forespurt av SOCKS-klienten |
For én webserver er dette en fast videresending:
ssh -N -L 127.0.0.1:9080:web.example.com:80 [email protected]Besøk http://127.0.0.1:9080/ som et nettsted. Ikke merk port 9080 som SOCKS: den videresender byte til den ene webserveren som er navngitt i kommandoen. Å åpne et nettsted under et annet vertsnavn kan også påvirke dets virtuelle hosting, omdirigeringer eller informasjonskapsler.
For en SOCKS-lytter endrer formen seg:
ssh -N -D 127.0.0.1:1080 [email protected]Konfigurer programmet til å bruke SOCKS på 127.0.0.1:1080. Skriver du inn den adressen direkte i nettleserens adressefelt, sendes en webforespørsel til en SOCKS-lytter, nok et protokollavvik.
OpenSSH-håndboken dokumenterer begge formene. Det finnes et nyttig unntak: å videresende en eksisterende HTTP-proxy med -L gir en lokal port som snakker HTTP-proxyprotokoll, fordi dens faste destinasjon selv er en HTTP-proxy. Tjenesten i den andre enden avgjør hva som hører til en fast videresending. Videresende en eksisterende proxy via SSH beholder protokollen og kontoen til den proxyen.