Nå ein eksisterande HTTP- eller SOCKS-proxy via SSH
Nå ein ekstern loopback HTTP- eller SOCKS-proxy via SSH utan å eksponera lyttaren offentleg.
Viss relay.example.net alt køyrer SOCKS på sin eigen 127.0.0.1:1080, videresend tilgangen i staden for å eksponera den lyttaren offentleg:
ssh -N -L 127.0.0.1:1081:127.0.0.1:1080 [email protected]| Endepunkt | Rolle |
|---|---|
Berbar 127.0.0.1:1081 | SOCKS-adressa som skal konfigurerast i applikasjonen på den berbare. |
Relay 127.0.0.1:1080 | Den eksisterande proxya som nåast frå SSH-tenarsida. |
Syntaksen for lokal videresending tildeler den faste destinasjonen til tenarsida. Ein HTTP-proxy på den eksterne loopback-porten 3128 eller eit intranett-endepunkt som proxy.internal.example:8080 verkar etter same prinsipp. Konfigurer klienten for den eksisterande HTTP-protokollen og kontoen; å føra han gjennom SSH skapar ikkje SOCKS eller ein TLS-aktivert HTTPS-lyttar.
Den eksisterande tenesta vel framleis støtta protokollversjonar, autentisering, destinasjonar og den endelege utgangen. Viss ein annan SSH-prosess oppretta den eksterne proxya, må båe prosessane halda seg i live. Ei rute berbar→relay→gateway lèt nettstaden sjå den siste utgåande sambindinga, ikkje ein identitet tildelt av lokal port 1081.
Hald bindinga til den berbare eksplisitt lokal. Breiare eksponering endrar kven som kan nå tenesta, og SSH-innlogging legg ikkje til eit SOCKS-passord på lyttaren. Ved avvising, sjekk lyttaren til den berbare, SSH-transporten og den eksterne proxya som separate trinn.