Jepini një Pi të largët një proxy SOCKS përmes klientit tuaj SSH

Ju supozoni se një proxy SOCKS duhet të ekzekutohet atje ku aksesi në rrjet ekziston tashmë. OpenSSH mund ta vendosë dëgjuesin diku krejt tjetër. Një përcjellje dinamike e largët hap portën SOCKS në një host të largët dhe e nis çdo lidhje nga klienti juaj lokal SSH, i cili mbart rrugën e VPN-së të miratuar të laptopit tuaj. Pi merr një proxy të kufizuar; ai nuk trashëgon tunelin ose privilegjet tuaja.

Dëgjuesi dhe ana nga e cila nis lidhja mund të ndryshojnë

Një ssh -D 1080 i zakonshëm e ekzekuton dëgjuesin në makinën tuaj dhe i dërgon lidhjet prej andej. Një përcjellje dinamike e largët e kthen mbrapsht: dëgjuesi shfaqet në hostin e largët dhe çdo lidhje që pranon hapet nga ana lokale. manuali i klientit OpenSSH dokumenton -R pa një destinacion fiks pikërisht si kjo skemë SOCKS4/5.

Një komandë e mbështetur nga laptopi duket kështu, me llogarinë, hostet dhe portën të trajtuara si vendmbajtëse:

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

Tre detaje bëjnë atje punë të dobishme. -S none e mban sesionin larg një masteri kontrolli të përbashkët, ExitOnForwardFailure dështon shpejt në vend që t'ju lërë me një sesion gjysmë të hapur, dhe PermitRemoteOpen kufizon deri ku mund të arrijë dëgjuesi i largët. Përdorni një llogari Pi të autorizuar dhe verifikoni çelësin e hostit përpara se të shtoni ndonjë nga këto.

Çfarë ekspozon vërtet dëgjuesi i largët

Kontrolloni politikën e përcjelljes së serverit përpara se të mbështeteni te dëgjuesi. Me GatewayPorts no përcjellja e largët mbetet e lidhur me loopback, dhe ky është ekspozimi që dëshironi. Një server i konfiguruar të imponojë përcjellje me karakter zëvendësues publikon të njëjtën portë në çdo ndërfaqe, gjë që e shndërron një proxy personal në diçka që rrjeti lokal mund ta arrijë.

Loopback gjithashtu nuk është kufi për çdo përdorues. Një proces tjetër në Pi mund të lidhet me 127.0.0.1:1080 nëse e di portën, kështu që llogaritë lokale të Pi-së dhe gjithçka që ekzekutohet në të janë pjesë e dizajnit tuaj të aksesit. Ky është një arsye për ta mbajtur listën e destinacioneve të ngushtë, jo një arsye për të kapërcyer kontrollin e politikës.

Mbajeni destinacionin e lejuar specifik për aplikacionin që po përpiqeni të arrini. Zëvendësimi i tij me përcjellje të pakufizuar që një program i palidhur të funksionojë e zgjeron rrugën shumë përtej problemit me të cilin filluat. Lista e destinacioneve regjistron gjithashtu për çfarë ishte sesioni, gjë që ndihmon këdo që do ta auditojë më vonë. Shkruajeni pranë llogarisë që përdorët.

Kaloni një aplikacion përmes proxy-t

Një klient në Pi që e kupton proxy-n mund ta dërgojë kërkesën. Parashtesa socks5h ia dorëzon emrin e destinacionit proxy-t, kështu që kërkimi dhe lidhja ndodhin të dyja në anën e laptopit, dhe përputhet me destinacionin e emërtuar në PermitRemoteOpen:

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

Ruani vlefshmërinë normale të certifikatës dhe vërtetimin e vetë aplikacionit. Proxy ndryshon ku krijohet lidhja TCP; nuk e bën të sigurt një shërbim pa vërtetim dhe nuk e shndërron një pikë fundore të vetë-nënshkruar në një të besueshme.

Laptopi ende ka nevojë për rrugën e vet dhe akses te zgjidhësi si te serveri SSH ashtu edhe te aplikacioni. Trafiku i klientit të tij SSH duhet të zgjidhet nga politika e VPN-së e miratuar, dhe një përjashtim split-tunnel mund ta dërgojë atë trafik në një rrugë tjetër nga ajo që testuat.

Provoni rrugën dhe mbylleni

Konfirmoni se dëgjuesi ekziston aty ku e prisni dhe se përgjigjet vetëm destinacioni i synuar:

$ 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 mund të provojë se përcjellja u vendos, dhe gjithsesi nuk mund të vërtetojë se hyrja në aplikacion ka sukses më poshtë. Testoni aplikacionin, jo vetëm portën. Një dëgjues që pranon dhe pastaj dështon çdo kërkesë zakonisht do të thotë që emri i destinacionit ose rruga e laptopit janë të gabuara, jo që tuneli dështoi.

Kjo skemë mbart vetëm TCP. UDP, ICMP dhe programet që injorojnë cilësimet e proxy-t mbeten jashtë saj, dhe përcjellja përfundon në momentin kur përfundon sesioni SSH. Ndaloni atë sesion kur të mbaroni dhe hiqni cilësimin e proxy-t që shtuat në aplikacion.

Për akses të përhershëm, përdorni në vend të kësaj regjistrimin e mbështetur të pronarit të rrjetit ose një portë të menaxhuar. Një proxy i kundërt është mjeti i gabuar për të shmangur kufizimet e pajisjes ose të burimeve të një VPN; i përdorur brenda tyre, ai është thjesht një rrugë e autorizuar aplikacioni me kufij të qartë.