SSH-lokalfremføring til en eksisterende HTTP-proxy: to loopback-adresser

Den godkjente proxyen din kjører på en språnghost der den bare lytter på loopback, så ingenting utenfor den maskinen kan nå den. Du trenger ikke VPN eller en ny proxy; du trenger én port fra den maskinen ført over til én port hos deg. En lokalfremføring gjør akkurat det, og den krever én kommando pluss én innstilling i applikasjonen. Forvirringen kommer vanligvis av at man blander sammen hvilken loopback-adresse som hører til hvilken maskin.

Avgjør om det allerede finnes en fast proxy

Denne teknikken videresender en tjeneste som allerede kjører. Hvis fjernverten bare har en SSH-demon og ingen proxy, lager ingen mengde videresending en, og tilkoblingen vil bli avvist fra fjernsiden. Bekreft at proxyen er bundet, hvilken port den bruker, og om den lytter på 127.0.0.1 eller på en bestemt grensesnittadresse, for det er den adressen fremføringen må rette seg mot.

Bekrefter du dette først, sparer du deg for å feilsøke en tunnel som aldri var koblet til noe.

Bygg fremføringen og les kommandoen

Formen du vil ha, binder en loopback-port på laptopen din og kobler den, fra serversiden, til proxyens adresse slik serveren ser den.

ssh -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:13128:127.0.0.1:3128 [email protected]

-N undertrykker en fjernkommando, og -T undertrykker termios-tildeling, fordi du vil ha en tunnel og ikke et skall. Den første loopback-adressen er der laptopen lytter; den andre løses opp av SSH-serveren, så 127.0.0.1 der betyr proxyen på den maskinen. ExitOnForwardFailure får kommandoen til å feile høyt hvis den lokale porten allerede er opptatt, i stedet for å starte en økt som ikke fremfører noe. Skriv mål-adressen slik serveren løser den opp, for et navn som bare laptopen din kan løse opp, vil feile på den andre siden.

Serverens egen policy gjelder før noe av dette virker. AllowTcpForwarding må tillate det, og PermitOpen kan begrense hvilke mål og porter en økt kan nå, så en fremføring klienten godtar, kan fortsatt avvises av serveren. Avvisningen vises som en fremførings- eller kanalfeil på klienten, og det er raskere å lese den meldingen enn å redigere kommandoen.

Pek én applikasjon mot fremføringen

Konfigurer applikasjonen til å bruke en HTTP-proxy på http://127.0.0.1:13128, med påloggingsdetaljer hvis fjernproxyen krever det. Behold applikasjonens egen sertifikatverifisering for HTTPS-mål, siden proxytunnelen ikke erstatter den. Dette er en fast fremføring av én tjeneste, så applikasjonen må få beskjed om at det finnes en proxy i stedet for å måtte oppdage en selv.

En rask sjekk før du konfigurerer noe permanent: curl -x http://127.0.0.1:13128 -I https://example.com, som prøver HTTP CONNECT-metoden proxyen må støtte.

Hold autoriteten der den var

Fjernproxyen bestemmer fortsatt hvilke mål og metoder den tillater, og en SSH-innlogging bør ikke stille gi hver konto et generelt nettrelé. Binding til 127.0.0.1 på laptopen unngår å publisere porten på ditt lokale nett, og det gjør ikke porten privat for andre prosesser på samme maskin. Å erstatte den bindingen med en jokertegnadresse for å dele proxyen, er hvordan et uadministrert åpent relé oppstår.

SSH-transporten beskytter spranget til serveren. Forbi det punktet åpner proxyen sin egen tilkobling, så en vanlig HTTP-forespørsel til et mål forblir vanlig forbi serveren, selv om det første segmentet var kryptert.

Verifiser begge ender, og rydd så opp

Oppsett av lokal tunnel og suksess for fjertjenesten er forskjellige resultater, og kommandoens avslutningsstatus forteller deg bare om det første. Sjekk at lytteren finnes med ss -ltn, og lag deretter en tillatt applikasjonsforespørsel og en forespørsel som proxyen bør avvise. Hvis begge oppfører seg som forventet, er veien ekte; hvis tunnelen er oppe og hver forespørsel feiler, avviser proxyen eller når ikke målet.

Når du er ferdig, stopp SSH-prosessen som eier den, fjern proxyinnstillingen fra applikasjonen, og bekreft at den lokale porten er borte i stedet for å etterlate en lytter som overlever oppgaven.