En SSH-vidarebefordrad port är inte alltid en SOCKS-proxy
Skilj på en fast lokal SSH-vidarebefordran och en dynamisk SOCKS-lyssnare innan du konfigurerar ett program.
Du skapar en SSH-tunnel, anger 127.0.0.1 och dess port i webbläsarens proxyinställningar, och ingenting laddas. Lyssnaren kan fungera perfekt. Den väntar kanske bara på fel typ av trafik.
| Vidarebefordran | Vad det lokala programmet skickar | Val av destination |
|---|---|---|
-L | Destinationstjänstens vanliga protokoll | Låst i SSH-kommandot |
-D | En SOCKS-förhandling, sedan programtrafik | Begärs av SOCKS-klienten |
För en enda webbserver är detta en fast vidarebefordran:
ssh -N -L 127.0.0.1:9080:web.example.com:80 [email protected]Besök http://127.0.0.1:9080/ som webbplats. Märk inte port 9080 som SOCKS: den vidarebefordrar byte till den enda webbserver som anges i kommandot. Att öppna en webbplats under ett annat värdnamn kan också påverka dess virtuella hosting, omdirigeringar eller kakor.
För en SOCKS-lyssnare ändras formen:
ssh -N -D 127.0.0.1:1080 [email protected]Konfigurera programmet att använda SOCKS på 127.0.0.1:1080. Att skriva in den adressen direkt i webbläsarens adressfält skickar en webbförfrågan till en SOCKS-lyssnare, ännu en protokollmissmatchning.
OpenSSH-handboken dokumenterar båda formerna. Det finns ett användbart undantag: att vidarebefordra en befintlig HTTP-proxy med -L ger en lokal port som talar HTTP-proxyprotokoll, eftersom dess fasta destination själv är en HTTP-proxy. Tjänsten i andra änden avgör vad som hör till en fast vidarebefordran. Vidarebefordra en befintlig proxy via SSH behåller den proxyns protokoll och konto.