Bigyan ng SOCKS proxy ang isang malayong Pi sa pamamagitan ng iyong SSH client

Ipinapalagay mo na ang SOCKS proxy ay dapat tumakbo kung saan mayroon nang access sa network. Maaaring ilagay ng OpenSSH ang listener sa lubos na ibang lugar. Ang malayong dynamic na pagpapasa ay nagbubukas ng SOCKS port sa isang malayong host at pinagmumulan ng bawat koneksyon mula sa iyong lokal na SSH client, na nagdadala ng aprubadong VPN path ng iyong laptop. Nakakakuha ang Pi ng limitadong proxy; hindi nito namamana ang iyong tunnel o ang iyong mga pribilehiyo.

Maaaring magkaiba ang listener at ang panig kung saan nagsisimula ang koneksyon

Ang karaniwang ssh -D 1080 ay nagpapatakbo ng listener sa sarili mong makina at nagpapadala ng mga koneksyon mula doon. Binabaliktad ito ng malayong dynamic na pagpapasa: lumilitaw ang listener sa malayong host, at bawat koneksyong tinatanggap nito ay binubuksan mula sa lokal na panig. manwal ng OpenSSH client ay nagdodokumento ng -R na walang takdang destinasyon bilang eksaktong kaayusang SOCKS4/5 na ito.

Ang isang sinusuportahang utos mula sa laptop ay ganito ang hitsura, kung saan ang account, mga host at port ay itinuturing na mga placeholder:

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

Tatlong detalye ang gumagawa ng kapaki-pakinabang na gawain doon. Ang -S none ay naglalayo ng session mula sa isang pinagsasaluhang control master, ang ExitOnForwardFailure ay mabilis na nabigo sa halip na iwan ka sa kalahating bukas na session, at ang PermitRemoteOpen ay nililimitahan kung hanggang saan maaaring makarating ang malayong listener. Gumamit ng awtorisadong Pi account at i-verify ang host key bago magdagdag ng anuman sa mga ito.

Ano ba talaga ang inilalantad ng malayong listener

Suriin ang patakaran sa pagpapasa ng server bago umasa sa listener. Sa GatewayPorts no, ang malayong pagpapasa ay nananatiling nakatali sa loopback, at iyon ang exposure na gusto mo. Ang server na naka-configure na piliting gumamit ng wildcard na pagpapasa ay naglalathala ng parehong port sa bawat interface, na ginagawang isang bagay na maaaring maabot ng lokal na network ang isang personal na proxy.

Ang loopback ay hindi rin hangganan sa bawat user. Maaaring kumonekta ang ibang proseso sa Pi sa 127.0.0.1:1080 kung alam nito ang port, kaya ang mga lokal na account ng Pi at lahat ng tumatakbo rito ay bahagi ng iyong disenyo ng access. Ito ay dahilan para mapanatiling makitid ang listahan ng destinasyon, hindi dahilan para laktawan ang pagsusuri ng patakaran.

Panatilihing partikular ang pinapayagang destinasyon para sa application na sinusubukan mong maabot. Ang pagpapalit nito ng walang limitasyong pagpapasa upang gumana ang isang walang kaugnayang programa ay nagpapalawak ng landas na lampas sa problemang sinimulan mo. Ang listahan ng destinasyon ay nagtatala rin kung para saan ang session, na tumutulong sa sinumang mag-audit nito mamaya. Isulat ito sa tabi ng account na ginamit mo.

Ipasa ang isang application sa proxy

Ang client sa Pi na nakakaunawa ng proxy ay maaaring gumawa ng kahilingan. Ang unlaping socks5h ay nagbibigay ng pangalan ng destinasyon sa proxy, kaya ang paghahanap at ang koneksyon ay parehong nangyayari sa panig ng laptop, at tumutugma ito sa pinangalanang destinasyon sa PermitRemoteOpen:

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

Panatilihin ang normal na pagpapatunay ng sertipiko at ang sariling authentication ng application. Binabago ng proxy kung saan ginagawa ang TCP connection; hindi nito ginagawang ligtas ang isang serbisyong walang authentication, at hindi nito ginagawang mapagkakatiwalaan ang isang self-signed endpoint.

Kailangan pa rin ng laptop ang sariling ruta at access sa resolver patungo sa SSH server at sa application. Ang trapiko ng SSH client nito ay dapat piliin ng aprubadong patakaran ng VPN, at ang isang split-tunnel exception ay maaaring magpadala ng trapikong iyon sa ibang landas kaysa sa sinubukan mo.

Patunayan ang landas at isara ito

Kumpirmahin na ang listener ay umiiral kung saan mo ito inaasahan at ang sinasadyang destinasyon lamang ang tumutugon:

$ 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/

Maaaring patunayan ng ExitOnForwardFailure na naitatag ang pagpapasa, at hindi pa rin nito mapatunayan na nagtatagumpay ang pag-login sa application sa ibaba ng daloy. Subukan ang application, hindi lang ang port. Ang listener na tumatanggap at pagkatapos ay binibigo ang bawat kahilingan ay karaniwang nangangahulugang mali ang pangalan ng destinasyon o ang ruta ng laptop, hindi na nabigo ang tunnel.

Ang kaayusang ito ay nagdadala ng TCP lamang. Nananatili sa labas nito ang UDP, ICMP at mga programang bumabalewala sa mga setting ng proxy, at nagtatapos ang pagpapasa sa sandaling magtapos ang session ng SSH. Itigil ang session na iyon kapag tapos ka na at alisin ang setting ng proxy na idinagdag mo sa application.

Para sa permanenteng access, gamitin sa halip ang sinusuportahang enrollment ng may-ari ng network o isang pinamamahalaang gateway. Ang reverse proxy ay maling kasangkapan para iwasan ang mga paghihigpit sa device o resources ng isang VPN; gamit sa loob ng mga ito, ito ay simpleng isang awtorisadong landas ng application na may malinaw na hangganan.