Giv en fjern Pi en SOCKS-proxy gennem din SSH-klient

En fjern dynamisk videresendelse sætter SOCKS-lytteren på Pi'en og laver den videre forbindelse fra din laptops godkendte VPN-vej. Ingen ekstra SSH-server.

Du antager, at en SOCKS-proxy skal køre dér, hvor netværksadgangen allerede findes. OpenSSH kan placere lytteren helt andre steder. En fjern dynamisk videresendelse åbner SOCKS-porten på en fjern vært og starter hver forbindelse fra din lokale SSH-klient, som bærer din laptops godkendte VPN-vej. Pi'en får en afgrænset proxy; den arver ikke din tunnel eller dine privilegier.

Lytteren og den side, forbindelsen udgår fra, kan være forskellige

En almindelig ssh -D 1080 kører lytteren på din egen maskine og sender forbindelser ud derfra. En fjern dynamisk videresendelse vender det om: lytteren dukker op på den fjerne vært, og hver forbindelse, den accepterer, åbnes fra den lokale side. OpenSSH-klientens manual beskriver -R uden en fast destination som netop dette SOCKS4/5-arrangement.

En understøttet kommando fra laptop'en ser sådan ud, hvor konto, værter og port behandles som pladsholdere:

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

Tre detaljer gør nytte der. -S none holder sessionen væk fra en delt kontrol-master, ExitOnForwardFailure fejler hurtigt i stedet for at efterlade dig med en halvt åben session, og PermitRemoteOpen begrænser, hvad den fjerne lytter kan nå. Brug en autoriseret Pi-konto, og verificér værtens nøgle, før du tilføjer noget af det.

Hvad den fjerne lytter egentlig udstiller

Kontrollér serverens videresendelsespolitik, før du stoler på lytteren. Med GatewayPorts no forbliver den fjerne videresendelse bundet til loopback, og det er den eksponering, du vil have. En server, der er sat til at gennemtvinge wildcard-videresendelse, offentliggør den samme port på hver grænseflade, hvilket gør en personlig proxy til noget, det lokale netværk kan nå.

Loopback er heller ikke en grænse pr. bruger. En anden proces på Pi'en kan oprette forbindelse til 127.0.0.1:1080, hvis den kender porten, så Pi'ens lokale konti og alt, hvad der kører på den, er en del af dit adgangsdesign. Det er grund til at holde destinationslisten snæver, ikke grund til at springe politik-kontrollen over.

Hold den tilladte destination specifik for det program, du forsøger at nå. At erstatte den med ubegrænset videresendelse for at få et uvedkommende program til at virke udvider vejen langt ud over det problem, du startede med. En destinationsliste registrerer også, hvad sessionen var til, hvilket hjælper dem, der reviderer den senere. Skriv den ned ved siden af den konto, du brugte.

Send ét program gennem proxyen

En proxybevidst klient på Pi'en kan derefter sende anmodningen. Præfikset socks5h giver destinationsnavnet til proxyen, så opslaget og forbindelsen sker begge på laptop'ens side, og det svarer til den navngivne destination i PermitRemoteOpen:

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

Behold normal certifikatvalidering og programmets egen godkendelse. Proxyen ændrer, hvor TCP-forbindelsen oprettes; den gør ikke en uautentificeret tjeneste sikker, og den gør ikke et selvsigneret endepunkt til et betroet et.

Laptop'en har stadig brug for sin egen rute og resolveradgang til både SSH-serveren og programmet. Dens SSH-klients trafik skal udvælges af den godkendte VPN-politik, og en split-tunnel-undtagelse kan sende den trafik ad en anden vej end den, du testede.

Bevis vejen og luk den

Bekræft, at lytteren findes, hvor du forventer det, og at kun den tilsigtede destination 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 videresendelsen blev etableret, og kan stadig ikke godtgøre, at programmets login lykkes længere nede. Test programmet, ikke kun porten. En lytter, der accepterer og derefter afviser hver anmodning, betyder normalt, at destinationsnavnet eller laptop'ens rute er forkert, ikke at tunnelen fejlede.

Dette arrangement bærer kun TCP. UDP, ICMP og programmer, der ignorerer proxyindstillinger, forbliver uden for det, og videresendelsen slutter i det øjeblik, SSH-sessionen slutter. Stop den session, når du er færdig, og fjern den proxyindstilling, du tilføjede til programmet.

Til permanent adgang bør du i stedet bruge netværksejerens understøttede tilmelding eller en administreret gateway. En omvendt proxy er det forkerte værktøj til at omgå en VPN's enheds- eller ressourcebegrænsninger; brugt inden for dem er den blot én autoriseret programvej med udtrykkelige grænser.

Relaterede artikler