Predpokladáte, že SOCKS proxy musí bežať tam, kde sieťový prístup už existuje. OpenSSH dokáže umiestniť listener úplne inam. Vzdialené dynamické presmerovanie otvorí port SOCKS na vzdialenom hostiteľovi a každé spojenie začína z vášho miestneho SSH klienta, ktorý nesie schválenú VPN cestu notebooku. Pi dostane obmedzenú proxy; nezdedí váš tunel ani vaše oprávnenia.

Listener a strana, z ktorej spojenie vzniká, sa môžu líšiť

Bežný ssh -D 1080 spúšťa listener na vašom vlastnom stroji a odtiaľ posiela spojenia. Vzdialené dynamické presmerovanie to obracia: listener sa objaví na vzdialenom hostiteľovi a každé spojenie, ktoré prijme, sa otvára z miestnej strany. manuál klienta OpenSSH dokumentuje -R bez pevného cieľa presne ako toto usporiadanie SOCKS4/5.

Podporovaný príkaz z notebooku vyzerá takto, pričom účet, hostitelia a port sa považujú za zástupné hodnoty:

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

Tri detaily tam robia užitočnú prácu. -S none drží reláciu mimo zdieľaného riadiaceho mastera, ExitOnForwardFailure zlyhá rýchlo, namiesto toho aby vás nechal s na pol otvorenou reláciou, a PermitRemoteOpen obmedzuje, kam až sa vzdialený listener dostane. Použite autorizovaný účet Pi a pred pridaním čohokoľvek z toho overte kľúč hostiteľa.

Čo vzdialený listener skutočne vystavuje

Predtým, než sa na listener spoľahnete, skontrolujte politiku presmerovania servera. S GatewayPorts no zostáva vzdialené presmerovanie viazané na loopback, a to je expozícia, ktorú chcete. Server nastavený tak, aby vynucoval wildcard presmerovanie, publikuje ten istý port na každom rozhraní, čo z osobnej proxy urobí niečo, čo lokálna sieť dokáže dosiahnuť.

Loopback tiež nie je hranicou medzi používateľmi. Iný proces na Pi sa môže pripojiť k 127.0.0.1:1080, ak pozná port, takže miestne účty Pi a všetko, čo na ňom beží, sú súčasťou vášho návrhu prístupu. To je dôvod držať zoznam cieľov úzky, nie dôvod vynechať kontrolu politiky.

Držte povolený cieľ konkrétny pre aplikáciu, ku ktorej sa snažíte dostať. Nahradenie neobmedzeným presmerovaním, aby fungoval nesúvisiaci program, rozširuje cestu ďaleko za problém, s ktorým ste začali. Zoznam cieľov tiež zaznamenáva, na čo relácia bola, čo pomáha tomu, kto ju bude neskôr auditovať. Zapíšte ho vedľa účtu, ktorý ste použili.

Pošlite jednu aplikáciu cez proxy

Klient na Pi, ktorý rozumie proxy, potom môže požiadavku odoslať. Predpona socks5h odovzdá proxy názov cieľa, takže vyhľadanie aj spojenie prebiehajú na strane notebooku, a zodpovedá pomenovanému cieľu v PermitRemoteOpen:

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

Zachovajte bežné overenie certifikátu aj vlastnú autentifikáciu aplikácie. Proxy mení, kde sa vytvára TCP spojenie; nerobí neautentifikovanú službu bezpečnou a nepremieňa samopodpísaný koncový bod na dôveryhodný.

Notebook stále potrebuje vlastnú trasu a prístup k resolveru ku SSH serveru aj k aplikácii. Premávku jeho SSH klienta musí vyberať schválená politika VPN a výnimka split-tunnel môže tú premávku poslať inou cestou, než akú ste testovali.

Dokážte cestu a zatvorte ju

Potvrďte, že listener existuje tam, kde ho očakávate, a že odpovedá len zamýšľaný cieľ:

$ 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 dokáže preukázať, že presmerovanie bolo nadviazané, a napriek tomu nedokáže potvrdiť, že prihlásenie do aplikácie ďalej uspeje. Testujte aplikáciu, nielen port. Listener, ktorý prijme a potom zlyhá pri každej požiadavke, zvyčajne znamená, že názov cieľa alebo trasa notebooku sú nesprávne, nie že tunel zlyhal.

Toto usporiadanie prenáša len TCP. UDP, ICMP a programy ignorujúce nastavenia proxy zostávajú mimo neho a presmerovanie sa skončí v okamihu, keď sa skončí relácia SSH. Keď skončíte, tú reláciu zastavte a odstráňte nastavenie proxy, ktoré ste pridali aplikácii.

Na trvalý prístup použite namiesto toho podporovanú registráciu vlastníka siete alebo spravovanú bránu. Reverzná proxy je nesprávny nástroj na obchádzanie obmedzení VPN týkajúcich sa zariadení alebo zdrojov; použitá v ich vnútri je jednoducho jedna povolená cesta aplikácie s výslovnými limitmi.

Súvisiace články