Lokal na SSH forwarding o buong VPN para sa isang Mac screen?

Kailangan mong makita ang screen ng isang Mac mula sa sarili mong makina, ang Mac ay nasa likod ng host na maaari mo nang SSH-an, at ang tanong ay kung karapat-dapat ito sa isang VPN. Karaniwang hindi. Ang isang lokal na forwarding ay nagdadala ng isang TCP port sa pamamagitan ng SSH session na mayroon ka na, at para sa isang screen sa isang host ito ay isang mas maliit at mas madaling i-audit na kaayusan kaysa sa pag-route ng buong network.

Tatlong kondisyon ang nagpapasya, at alinman sa mga ito ay maaaring magtulak sa iyo patungo sa pinamamahalaang VPN.

Tatlong kondisyon ang nagpapasya

Ang una ay saklaw: isang serbisyo sa isang host, o maraming host at maraming port. Ang pangalawa ay kung ang bawat pagtalon sa pagitan ng bastion at target ay pinagkakatiwalaan na, dahil pinoprotektahan lamang ng SSH ang segment na tinatapos nito. Ang pangatlo ay kung sino ang kailangang sumuporta sa kaayusan pagkatapos mong buuin ito, dahil ang gawang-kamay na tunnel ay karaniwang humahaba pa sa taong nakaintindi nito. Pangalanan ang taong iyon bago ka magsimula, at isulat ang utos sa lugar kung saan niya ito mahahanap. Ang hindi dokumentadong forwarding ay isang hinaharap na insidente na may naantalang petsa ng pagsisimula.

Kung ang mga sagot ay «isa», «oo» at «ako, sa ngayon», ang forwarding ang tamang kasangkapan. Kung magbabago ang anumang sagot, ang suportadong disenyo ng remote access ay mas mura sa loob ng isang taon kaysa sa pagsusuri ng insidenteng sumusunod sa isang hindi dokumentadong tunnel.

I-forward ang isang port, hindi ang network

Ang lokal na forwarding ay nagbubukas ng tagapakinig sa iyong makina at ipinapasa ang bawat koneksyon sa pamamagitan ng SSH server patungo sa destinasyong maabot ng server na iyon. Para sa Mac na ang serbisyo ng screen sharing ay nakikinig sa TCP 5900, at bastion na kayang lutasin ang mac.corp.example, ang utos ay maikli at sadyang makitid. Ang bawat opsyon sa loob nito ay mayroon upang mapanatiling maliit ang kaayusan: walang shell, walang tagapakinig sa lahat ng interface, walang daemon. Basahin ito bilang pahayag ng saklaw, hindi bilang resipe.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:15900:mac.corp.example:5900 [email protected]

Ang pagbigkis ng tagapakinig sa 127.0.0.1 ay naglalayo nito sa lahat ng iba pang interface. Ito ay hindi pormalidad: ang forwarding na nakabigkis sa lahat ng interface ay ginagawang bukas na relay ang iyong laptop papasok sa corporate network para sa sinumang nasa parehong Wi-Fi ng café. Kung ginagamit na ang port, pumili ng ibang mataas na port at i-update ang viewer; huwag ihinto ang walang kaugnayang serbisyo para magkasya ang halimbawa.

Ang account sa bastion ay nangangailangan din ng pahintulot na mag-forward patungo sa destinasyong iyon. Ang ilang hardened na SSH configuration ay ganap na nagpapahinto sa port forwarding, at ang ilan ay naglilimita nito sa pamamagitan ng permit-listen o permit-open na direktiba. Basahin ang patakaran ng server bago ipagpalagay na ang tinanggihang channel ay nangangahulugang mali ang password.

Ano ang ine-encrypt ng SSH, at saan ito tumitigil

Pinoprotektahan ng SSH session ang trapiko mula sa iyong Mac patungo sa bastion, at dinadala ng forwarding ang VNC protocol sa loob ng session na iyon nang hindi ito naiintindihan. Kapag umalis ang koneksyon sa bastion patungo sa target, hindi na ito nasa loob ng iyong SSH session. Anumang proteksyon sa huling pagtalon ay pag-aari ng target protocol at ng sariling mga kontrol ng pribadong network.

Iyon ang dahilan kung bakit ang simpleng huling VNC na pagtalon ay hindi dapat ilarawan bilang naka-encrypt mula dulo hanggang dulo dahil lang gumamit ng SSH ang unang pagtalon. Ilarawan ang mga segment nang tapat: matibay mula sa client hanggang sa bastion, at pagkatapos ay ang sinusuportahan ng target. Kung ang pangangailangan ay ma-encrypt ang buong landas ng isang mekanismo, hindi ito natutugunan ng forwarding.

Ang pagpapatotoo sa target ay hiwalay na usapin muli. Ang SSH account ay hindi nagbibigay ng login sa macOS, at ang serbisyo ng screen sharing ay humihingi pa rin ng sarili nitong mga kredensyal at naglalapat pa rin ng sarili nitong listahan ng access. Ang lokal na tagapakinig na tumatanggap ng koneksyon ay walang pinapatunayan tungkol sa kung tatanggapin ng remote na serbisyo ang session.

Kailan ang buong VPN ang tamang desisyon

Piliin ang VPN kapag ang gawain ay nangangailangan ng higit sa isang port: ang mga function ng pamamahala at pag-uulat ng Apple Remote Desktop ay gumagamit ng karagdagang TCP at UDP trapiko na hindi kayang dalhin ng isang TCP forwarding. Ang forwarding ay hindi bahagyang implementasyon ng buong produkto; ito ay ibang, mas maliit na kasangkapan.

Piliin ito kapag maraming administrator ang kumokonekta mula sa nagbabagong lokasyon, dahil ang pinamamahalaang profile ay namamahagi ng ruta, kredensyal at patakaran nang hindi kailangang mag-imbento ng command line ang bawat isa. Piliin ito kapag kailangang ipakita ng audit trail kung sino ang kumonekta sa ano, dahil ang SSH session kada user at ang pinagsasaluhang lokal na forwarding ay nag-iiwan ng ibang-ibang talaan.

Piliin ito, sa huli, kapag ang target network ay hindi dapat maabot mula sa laptop nang wala ang sariling gate ng organisasyon. Ang personal na forwarding ay lumalampas sa gate na iyon ayon sa disenyo, at iyon ang dahilan kung bakit nabibilang ito sa talaan ng pagbabago at hindi sa kasaysayan ng shell.

Hayaang mabigo nang malakas ang forwarding

Gamitin ang ExitOnForwardFailure=yes upang ang nabigong pagbigkis ay ihinto ang session sa halip na mag-iwan ng shell na mukhang konektado at wala namang ipinapasa. Panatilihing naka-on ang pagpapatunay ng host key, at piliin ang key o agent kaysa sa password. Pagkatapos ay subukan ang eksaktong URL na gagamitin ng viewer, dahil ang gumaganang SSH session at gumaganang koneksyon sa screen ay dalawang magkaibang resulta.

Para sa native na client sa macOS, naaabot ang viewer sa pamamagitan ng lokal na URL: open "vnc://127.0.0.1:15900". Kung bumukas ang window at tinanggihan ng remote host ang pagpapatunay, maayos ang tunnel at ang problema ay nasa target. Kung hindi kailanman bumukas ang window, ang problema ay nasa tagapakinig o port.

Ihinto ang session kapag tapos ka na, at isulat ang port, bastion, target at patakaran ng account. Ang forwarding na walang nagdokumento ay hindi makikilala mula sa backdoor pagkalipas ng anim na buwan, at iyon ang pinakamalakas na argumento para panatilihin itong maliit, may pangalan at pansamantala.