Gi en ekstern Pi en SOCKS-proxy gjennom SSH-klienten din

En ekstern dynamisk videresending setter SOCKS-lytteren på Pi-en og gjør den videre forbindelsen fra den godkjente VPN-veien til laptopen din. Ingen ekstra SSH-server.

Du antar at en SOCKS-proxy må kjøre der nettverkstilgangen allerede finnes. OpenSSH kan plassere lytteren helt andre steder. En ekstern dynamisk videresending åpner SOCKS-porten på en ekstern vert og starter hver forbindelse fra din lokale SSH-klient, som bærer den godkjente VPN-veien til laptopen din. Pi-en får en avgrenset proxy; den arver ikke tunnelen eller privilegiene dine.

Lytteren og siden forbindelsen kommer fra, kan være forskjellige

En vanlig ssh -D 1080 kjører lytteren på din egen maskin og sender forbindelser ut derfra. En ekstern dynamisk videresending snur det: lytteren dukker opp på den eksterne verten, og hver forbindelse den godtar, åpnes fra den lokale siden. OpenSSH-klientens manual dokumenterer -R uten et fast mål som nettopp dette SOCKS4/5-oppsettet.

En støttet kommando fra laptopen ser slik ut, med kontoen, vertene og porten behandlet som plassholdere:

ssh -NT -S none -o ExitOnForwardFailure=yes \
  -o PermitRemoteOpen=app.corp.example:443 \
  -R 1080 [email protected]

Tre detaljer gjør nyttig arbeid der. -S none holder økten unna en delt kontroll-master, ExitOnForwardFailure feiler raskt i stedet for å la deg sitte med en halvåpen økt, og PermitRemoteOpen begrenser hva den eksterne lytteren kan nå. Bruk en autorisert Pi-konto og verifiser vertsnøkkelen før du legger til noe av dette.

Hva den eksterne lytteren egentlig eksponerer

Sjekk videresendingspolicyen til serveren før du stoler på lytteren. Med GatewayPorts no forblir den eksterne videresendingen bundet til loopback, og det er eksponeringen du vil ha. En server som er satt opp til å tvinge frem jokertegn-videresending, publiserer samme port på hvert grensesnitt, noe som gjør en personlig proxy til noe det lokale nettverket kan nå.

Loopback er heller ikke en grense per bruker. En annen prosess på Pi-en kan koble til 127.0.0.1:1080 hvis den kjenner porten, så Pi-ens lokale kontoer og alt som kjører på den er en del av tilgangsdesignet ditt. Det er en grunn til å holde mållisten smal, ikke en grunn til å hoppe over policysjekken.

Hold det tillatte målet spesifikt for programmet du prøver å nå. Å erstatte det med ubegrenset videresending for å få et uvedkommende program til å virke, utvider veien langt forbi problemet du startet med. En målliste registrerer også hva økten var til, noe som hjelper den som reviderer den senere. Skriv den ned ved siden av kontoen du brukte.

Send ett program gjennom proxyen

En proxybevisst klient på Pi-en kan da sende forespørselen. Prefikset socks5h overleverer målnavnet til proxyen, så oppslaget og forbindelsen skjer begge på laptopsiden, og det samsvarer med det navngitte målet i PermitRemoteOpen:

curl --proxy socks5h://127.0.0.1:1080 \
  --noproxy '' https://app.corp.example/

Behold vanlig sertifikatvalidering og programmets egen autentisering. Proxyen endrer hvor TCP-forbindelsen opprettes; den gjør ikke en uautentisert tjeneste trygg, og den gjør ikke et selvsignert endepunkt til et klarert et.

Laptopen trenger fortsatt sin egen rute og resolvertilgang til både SSH-serveren og programmet. Trafikken til SSH-klienten må velges av den godkjente VPN-policyen, og et split-tunnel-unntak kan sende den trafikken en annen vei enn den du testet.

Bevis veien og lukk den

Bekreft at lytteren finnes der du forventer, og at bare det tiltenkte målet svarer:

$ ss -ltnp | grep 1080
LISTEN 0 128 127.0.0.1:1080 0.0.0.0:*
$ curl -sS -o /dev/null -w '%{http_code}\n' \
    --proxy socks5h://127.0.0.1:1080 https://app.corp.example/

ExitOnForwardFailure kan bevise at videresendingen ble opprettet, og kan fortsatt ikke attestere at innloggingen i programmet lykkes lenger ned. Test programmet, ikke bare porten. En lytter som godtar og deretter feiler på hver forespørsel, betyr vanligvis at målnavnet eller ruten til laptopen er feil, ikke at tunnelen feilet.

Dette oppsettet bærer bare TCP. UDP, ICMP og programmer som ignorerer proxyinnstillinger holder seg utenfor, og videresendingen slutter i det øyeblikket SSH-økten slutter. Stopp den økten når du er ferdig, og fjern proxyinnstillingen du la til i programmet.

For permanent tilgang bør du i stedet bruke nettverkseierens støttede registrering eller en administrert gateway. En omvendt proxy er feil verktøy for å omgå en VPNs enhets- eller ressursbegrensninger; brukt innenfor dem er den rett og slett én autorisert programvei med uttrykkelige grenser.

Relaterte artikler