Dynamic na SSH Forwarding bilang SOCKS Proxy sa Ibabaw ng Iyong VPN

Ang app na SOCKS lang ang sinasalita ay walang makakausap sa karaniwang VPN, dahil nagdadala ng packet ang tunnel at gusto ng app ng proxy endpoint. Makapagbibigay ang OpenSSH ng endpoint na iyon kapag pinapayagan ng may-ari ng access, dahil ginagawang lokal na proxy ng dynamic na forwarding ang isang SSH session. Pagkatapos, may dalawang hakbang na dapat hiwalayin: ang tunnel na umaabot sa SSH host, at ang koneksyon na binubuksan nito pagkatapos. Ang paghihiwalay sa kanila ay nagpapaliwanag kung bakit gumagana ang kaayusang ito at kung ano ang hindi nito gagawin.

Ano ang nagiging SSH listener at ano ang hindi

Pinipilit ng dynamic na forwarding ang SSH client na makinig nang lokal at makipag-usap ng SOCKS4 o SOCKS5 sa lahat ng kumokonekta. Binabanggit ng bawat kahilingan ang isang destinasyon at binubuksan ng SSH server ang susunod na koneksyon, kaya maaaring mangyari ang paghahanap ng destinasyon sa kabilang dulo. Ito ay TCP forwarding sa antas ng aplikasyon, hindi VPN para sa buong device. Wala itong dinadalang UDP association, wala ring ICMP, at wala para sa mga app na tuluyang binabalewala ang mga setting ng proxy. Ang hakbang mula sa SSH server patungo sa app ay wala rin sa loob ng iyong tunnel, na mahalaga kapag tumatanggap lang ng trapiko ang destinasyon mula sa mga kilalang network.

Totoong mga paunang kailangan ang sumusunod: ruta papunta sa SSH host, awtorisadong account, beripikadong host key ng server, at pahintulot na mag-forward. Wala sa mga ito ang nililikha ng proxy, at ang huli ang karaniwang unang nawawala. Tiyakin ang apat bago mag-debug ng iba pa, dahil mula sa client ay pareho ang hitsura ng kabiguan, alinman ang nawawala.

Simulan ito sa loopback na may tahasang port

Pumili ng hindi ginagamit na lokal na port at tahasan itong itali sa loopback sa halip na iwanang blangko ang address. Ang tatlong opsyon sa ibaba ay may isa't isang dahilan.

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

-N ay lumalaktaw sa remote na utos at -T ay lumalaktaw sa pseudo-terminal, kaya ang session ay para sa pag-forward lang. ExitOnForwardFailure ay nagpapaalis sa client kapag hindi malikha ang listener, sa halip na tumakbo nang walang forwarding na hiningi mo. ControlPath=none ay naglalayo sa session mula sa umiiral na multiplex na koneksyon na maaaring magdagdag ng sarili nitong forwarding. Ang loopback ay naglalayo sa listener mula sa LAN, ngunit sa shared na makina hindi ito hangganan ng awtorisasyon, dahil maaabot din ito ng ibang lokal na proseso. Ang sanggunian ng OpenSSH client ay nagdodokumento ng lahat ng flag na ito, at ang babala sa loopback ay nagmumula sa kung ano ang socket na nakikinig.

Ipadala ang mga pangalan sa proxy, hindi paligid nito

Maaaring solusyunan ng SOCKS5 client mismo ang destinasyon o hilingin sa proxy na gawin iyon, at ang pagpiling iyon ang nagtatakda kung aling resolver ang sasagot. Sa socks5h, ipinapadala ng curl ang hostname sa proxy, kaya sa SSH server nangyayari ang paghahanap. Sa socks5 na simple, ang laptop ang unang nagreresolba at ang koneksyon lang ang bumibiyahe, na tahimik na sumisira sa layunin kapag panloob ang pangalan. Ang kahilingan sa ibaba ay naglilinis din ng listahan ng walang-proxy, kaya hindi ito maaaring ihatid ng minanang halaga ng NO_PROXY sa paligid ng proxy.

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

Nalalapat pa rin ang beripikasyon ng sertipiko at ang sariling pag-login ng app, dahil hindi pinapalitan ng proxy ang alinman. Dalawang paghahanap ang natitira: kailangang maabot ng laptop ang SSH host sa pinapayagang landas ng VPN at DNS, at kailangang solusyunan ng SSH server mismo ang pangalan ng app. Ang pangalawa ay masusubok nang hiwalay bago dumaan ang anumang trapiko sa proxy.

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

Patunayan ang isang pinapayagang destinasyon, pagkatapos isara ang session

Subukan ang destinasyong pinapayagan ng patakaran at ang dapat nitong tanggihan, dahil ang gumaganang forwarding ay nagpapatunay lang na gumagana ang listener at wala nang iba. Nakikita ng app ang source address na pinipili ng SSH server, at hindi iyon ang tunnel address ng iyong laptop. Kung saan nila-log ng malayong dulo ang mga koneksyon ayon sa source, ang pagkakaibang iyon ang unang dapat tingnan kapag tinanggihan ang isang kahilingan.

Itigil ang session sa pamamagitan ng prosesong nagmamay-ari nito sa halip na patayin ang walang kaugnayang shell. Pagkatapos ay tiyakin na wala na ang listener, dahil ang port na sumasagot pa ay session na hindi mo talaga isinara. Alisin lamang ang setting ng proxy na ipinakilala ng pagsasanay na ito, at iwanang payapa ang natitirang configuration ng app. Ang terminal na walang nagbabantay na may hawak ng panuntunan sa forwarding ay hindi serbisyo, at ang permanenteng proxy ay nangangailangan ng aprubadong lifecycle, hindi ng nakalimutang window.

ss -ltn | grep 1080

Mga kabiguang hindi kayang ayusin ng kaayusang ito

Ang ilang sintomas ay direktang tumuturo sa mga hangganan sa itaas, at ang maagang pagkilala sa kanila ay nakakatipid ng isang hapon ng pag-debug ng proxy. Iniuugnay ng talahanayan ang nakikita mo sa karaniwang kahulugan nito. Anuman sa huling kolumna ay tanong sa disenyo, hindi pagkakamali sa configuration.

Ang unang tatlong hilera ang madalas mali ang diagnosis, dahil bawat isa ay gumagawa ng pagtatangka sa koneksyon sa halip na error tungkol sa proxy mismo. Ang pangalang nareresolba sa laptop ay walang sinasabi tungkol sa resolver ng server, at ang kabiguan ay binabasa bilang problema sa sertipiko o timeout. Ang mga app na UDP lang ay nasa labas ng disenyo, hindi sira sa loob nito, at walang karagdagang opsyon sa ssh ang makapagbabago niyon. Ang hilera ng browser ay ang karaniwang paalala na ang mga setting ng proxy ay bawat app. Ang huling hilera ang dahilan kung bakit may pagsusuri sa pagsasara: ang port na nakikinig pa ay nangangahulugang may ibang nagmamay-ari nito ngayon.