Përcjellja dinamike e SSH si proxy SOCKS mbi VPN-në tuaj

Një aplikacion që flet vetëm SOCKS nuk ka me kë të flasë në një VPN të zakonshme, sepse tuneli mbart paketa dhe aplikacioni dëshiron një pikë fundore proxy. OpenSSH mund ta sigurojë atë pikë kur pronari i aksesit e lejon, sepse përcjellja dinamike e kthen një sesion SSH në një proxy lokal. Më pas janë dy kërcime që duhen mbajtur të ndara: tuneli që arrin hostin SSH dhe lidhja që ai host hap më tej. Ndarja e tyre shpjegon njëkohësisht pse funksionon kjo skemë dhe çfarë nuk do të bëjë kurrë.

Çfarë bëhet dhe çfarë nuk bëhet dëgjuesi SSH

Përcjellja dinamike e detyron klientin SSH të dëgjojë lokalisht dhe të flasë SOCKS4 ose SOCKS5 me çdo gjë që lidhet. Çdo kërkesë emërton një destinacion dhe serveri SSH hap lidhjen vijuese, prandaj kërkimi i destinacionit mund të ndodhë në anën tjetër. Kjo është përcjellje TCP në nivel aplikacioni, jo një VPN për të gjithë pajisjen. Nuk mbart asnjë shoqatë UDP, as ICMP, asgjë për aplikacionet që injorojnë plotësisht cilësimet e proxy-t. As kërcimi nga serveri SSH te aplikacioni nuk është brenda tunelit tuaj, gjë që ka rëndësi kur destinacioni pranon trafik vetëm nga rrjete të njohura.

Parakushtet janë reale: një rrugë drejt hostit SSH, një llogari e autorizuar, një çelës hosti i verifikuar i serverit dhe leja për të përcjellë. Asnjërën nuk e krijon proxy-i, dhe e fundit zakonisht mungon e para. Konfirmoni të katërtat para se të diagnostikoni çdo gjë tjetër, sepse nga ana e klientit dështimi duket i njëjtë, cilado qoftë që mungon.

Nisni atë në loopback me një port të qartë

Zgjidhni një port lokal të papërdorur dhe lidhni atë shprehimisht me loopback, në vend që të lini adresën jashtë. Tre opsionet më poshtë ekzistojnë secili për një arsye.

ssh -D 127.0.0.1:1080 -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  [email protected]

-N kalon komandën në distancë dhe -T kalon pseudo-terminalin, kështu që sesioni ekziston vetëm për të përcjellë. ExitOnForwardFailure e bën klientin të dalë kur dëgjuesi nuk mund të krijohet, në vend që të punojë pa përcjelljen që kërkuat. ControlPath=none e mban sesionin jashtë një lidhjeje ekzistuese të multipleksuar që mund të shtojë përcjelljet e veta. Loopback e mban dëgjuesin jashtë LAN-it, por në një makinë të ndarë kjo nuk është kufi autorizimi, sepse edhe procese të tjera lokale mund ta arrijnë. Referenca e klientit OpenSSH dokumenton të gjitha këto flamuj, dhe paralajmërimi për loopback rrjedh nga ajo çfarë është një socket që dëgjon.

Dërgoni emrat përmes proxy-t, jo rreth tij

Një klient SOCKS5 mund ta zgjidhë vetë destinacionin ose t'i kërkojë proxy-t ta bëjë, dhe kjo zgjedhje përcakton cili zgjidhës përgjigjet. Me socks5h curl e dërgon emrin e hostit përmes proxy-t, kështu që kërkimi ndodh në serverin SSH. Me socks5 të thjeshtë laptopi zgjidh i pari dhe udhëton vetëm lidhja, gjë që e zhvlerëson në heshtje qëllimin kur emri është i brendshëm. Kërkesa më poshtë zbraz edhe listën pa proxy, kështu që një vlerë NO_PROXY e trashëguar nuk mund ta çojë rreth proxy-t.

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

Vlerësimi i certifikatës dhe hyrja e vetë aplikacionit vazhdojnë të zbatohen, sepse proxy-i nuk zëvendëson asnjërën. Mbeten dy kërkime: laptopi duhet të arrijë hostin SSH nëpër rrugën e lejuar të VPN dhe DNS, dhe serveri SSH duhet ta zgjidhë vetë emrin e aplikacionit. E dyta mund të testohet veçmas para se çdo trafik të kalojë përmes proxy-t.

ssh [email protected] getent hosts app.corp.example

Provoni një destinacion të lejuar, pastaj mbyllni sesionin

Testoni një destinacion që politika e lejon dhe një që duhet ta refuzojë, sepse një përcjellje që punon provon vetëm se dëgjuesi punon dhe asgjë më shumë. Aplikacioni sheh adresën e burimit që zgjedh serveri SSH, dhe kjo nuk është adresa e tunelit të laptopit tuaj. Aty ku ana e largët regjistron lidhjet sipas burimit, ai ndryshim është gjëja e parë që duhet kontrolluar kur një kërkesë refuzohet.

Ndalni sesionin përmes procesit që e zotëron, në vend që të vrisni një shell të palidhur. Pastaj konfirmoni se dëgjuesi është zhdukur, sepse një port që ende përgjigjet është një sesion që nuk e keni mbyllur vërtet. Hiqni vetëm cilësimin e proxy-t që solli ky ushtrim, dhe lini pjesën tjetër të konfigurimit të aplikacionit në paqe. Një terminal pa mbikëqyrje që mban një rregull përcjelljeje nuk është shërbim, dhe një proxy i përhershëm kërkon një cikël jete të miratuar, jo një dritare të harruar.

ss -ltn | grep 1080

Dështimet që kjo skemë nuk mund t'i rregullojë

Disa simptoma tregojnë drejtpërdrejt kufijtë më sipër, dhe njohja e hershme e tyre kursen një pasdite korrigjimi të proxy-t. Tabela lidh atë që shihni me atë që zakonisht do të thotë. Çdo gjë në kolonën e fundit është çështje dizajni, jo gabim konfigurimi.

Tre rreshtat e parë janë ata që njerëzit i diagnostikojnë gabim, sepse secili prodhon një përpjekje lidhjeje në vend të një gabimi për vetë proxy-n. Një emër që zgjidhet në laptop nuk thotë asgjë për zgjidhësin e serverit, dhe dështimi lexohet në vend të kësaj si problem certifikate ose afati kohor. Aplikacionet vetëm me UDP qëndrojnë jashtë dizajnit, jo të prishura brenda tij, dhe asnjë opsion ssh shtesë nuk e ndryshon këtë. Rreshti i shfletuesit është kujtesa e zakonshme se cilësimet e proxy-t janë për çdo aplikacion veç e veç. Rreshti i fundit është arsyeja pse ekziston kontrolli i mbylljes: një port që ende dëgjon do të thotë se tani e zotëron diçka tjetër.