sshuttle kumpara sa buong VPN: ano talaga ang saklaw ng paraan nito

Pinipili ang sshuttle dahil gumagana na ang SSH at mukhang pamilyar ang kriptograpiya, at nilalaktawan ng pangangatwirang iyon ang tanging tanong na nagpapasya kung angkop ito. Aling mga packet ang lumalabas sa makina, aling account ang nagdadala sa kanila sa kabilang panig, at gaano karaming lokal na pribilehiyo ang hinihingi ng kasangkapan. Nagkakaiba ang tatlong sagot na iyon ayon sa paraan ng pagpapasa, kaya ang isang setup na gumagana para sa isang aplikasyon ay maaaring tahimik na mabigo para sa susunod. Nagsisimula ang paliwanag sa ibaba sa protocol na talagang kailangan ng aplikasyon.

Magsimula sa protocol na kailangan ng aplikasyon

Ang suporta sa protocol sa sshuttle 2.0 ay nakasalalay sa paraang pipiliin mo. Ang mga paraang NAT at nft ng Linux ay humahawak ng TCP at DNS, at ang TPROXY ay nagdadagdag ng pangkalahatang UDP. Bawat plataporma at paraan ay may sariling hangganan, at ang macOS ay humaharang sa pamamagitan ng ganap na ibang mekanismo. Itala ang naka-install na bersyon, ang napiling paraan at ang mga protocol na kailangan ng aplikasyon bago pumili ng anuman.

Kaya't ang gumaganang kahilingang TCP ay napakakaunting pinapatunayan tungkol sa isang aplikasyong UDP o sa bawat paghahanap ng DNS. Itinuturing din ng sshuttle ang TCP bilang mga daloy sa halip na i-tunnel ang buong packet ng IP, kaya ang konklusyon sa throughput na hiniram mula sa karaniwang VPN ay hindi nalilipat dito. Ihambing ang mekanismong talagang pinapatakbo mo sa kargang talagang mayroon ka.

Ano ang kailangan ng kliyente nang lokal

Ang nakadokumentong kaayusan ng kliyente ay nangangailangan ng root o sudo, dahil nag-i-install ito ng lokal na mga tuntunin sa pagharang sa halip na gumawa ng interface ng tunnel. Ang isang katotohanang iyon ay nagbabago sa kuwento ng seguridad: ang isang prosesong may ganoong pribilehiyo ay maaaring ilipat ang trapiko ng buong makina, hindi lamang ng isang aplikasyon. Ituring ang pribilehiyo bilang bahagi ng disenyo at hindi bilang detalye ng pag-install.

Tiyakin kung aling mga tuntunin ang inilagay ng kasangkapan at na nawawala ang mga ito kapag ito ay lumabas. Ang isang sessiyong bumagsak at nag-iwan ng mga tuntunin sa pagharang ay maaaring magpadala ng trapiko sa isang itim na butas matagal pagkatapos na isipin ng operator na wala na ang koneksyon, at ang sintomas ay mukhang pagkawala ng network at hindi natirang tuntunin.

sudo sshuttle --method nft --dns 172.19.4.0/24
nft list ruleset | grep -i sshuttle
ip route

Ang unang utos ay ang anyo ng karaniwang tawag, kasama ang unlaping talagang kailangan mo. Ipinapakita ng pangalawa kung ano ang inilagay ng kasangkapan, at kinukumpirma ng pangatlo na walang interface ng tunnel na lumitaw, na siyang inaasahang resulta para sa disenyong ito.

Ano ang pinapatakbo ng malayong panig

Ang malayong panig ay isang awtorisadong account ng SSH at isang katugmang kapaligiran ng katulong na Python. Ang pag-log in na nagtagumpay sa ilalim ng limitadong shell ay hindi awtomatikong nagbibigay ng pahintulot na patakbuhin ang katulong na iyon, at ang account na kayang patakbuhin ang katulong ay hindi awtomatikong nakakaabot sa bawat target na serbisyo. Ang dalawang katotohanan ay kabilang sa kahilingan sa pag-access at hindi sa mga tala sa pag-troubleshoot.

Protektahan ang beripikasyon ng pagkakakilanlan ng host at ang pagpapatunay ng account. Ang pagtanggap ng hindi kilalang susi ng host upang gumana ang unang koneksyon ay nag-aalis ng pagsusuring ang malayong panig ang makinang nilalayon mo, at mas mabigat ito rito kaysa sa pagpapasa para sa isang layunin.

Limitahan ang malayong account sa mga serbisyong kailangan ng workflow, at pag-usapan ang saklaw na iyon sa mga nagpapatakbo ng host. Sila ay bahagi ng ugnayan ng tiwala, at walang setting sa panig ng kliyente ang nagbabago niyon.

Nasaan ang hangganan ng tiwala

Ang pagpapasa ng pribadong koneksyon ng API sa pamamagitan ng SSH ay hindi nagbibigay ng pahintulot sa bawat operasyon ng API. Nalalapat pa rin ang TLS ng aplikasyon at ang pag-log in sa aplikasyon, at hindi kayang gawing ligtas ng kasangkapan ang isang serbisyong walang pagpapatunay. Ang susunod na paglundag mula sa malayong host ay hindi rin awtomatikong parehong protektadong bahagi ng channel ng SSH, dahil sinusunod ng ikalawang koneksyong iyon ang anumang patakarang mayroon ang malayong host.

Isulat ang hangganan sa isang pangungusap: ang trapiko patungo sa mga unlaping ito ay lumalabas sa account na ito sa host na iyon. Kung ang pangungusap ay nangangailangan ng isang talata ng mga pagbubukod, ang disenyo ay gumagawa ng higit sa sinasabi ng dokumentasyon nito at karapat-dapat sa ikalawang pagtingin bago ito makarating sa produksyon.

Patunayan ito sa bawat protocol, pagkatapos ay piliin ang kasangkapan

Subukan ang bawat kinakailangang protocol gamit ang hindi nakakapinsalang kahilingan, kasama ang landas ng resolver at ang mga pamilya ng address na ginagamit ng aplikasyon. Isama sa pagsubok ang isang pagkaputol, upang ang pinapayagang pag-uugali sa pagkabigo ng aplikasyon ay maging kilalang resulta at hindi sorpresa sa panahon ng insidente. Ang sessiyong nagpasa nang tama habang tumatakbo ay walang sinasabi tungkol sa nangyayari kapag ito ay bumagsak.

Para sa iilang serbisyong tahasang pinangalanan, ang karaniwang lokal na pagpapasa ay mas madaling pagmamay-ari at mas madaling i-audit. Para sa trapiko ng aplikasyong umaayon sa paraan nito, nag-aalok ang sshuttle ng lehitimong gitnang landas. Kapag ang pangangailangan ay malawak na koneksyon ng IP, ang disenyo ng VPN ang tapat na sagot, at ang pagpili ay sumusunod sa saklaw at responsibilidad sa pagpapatakbo at hindi sa ranggo ng mga algorithm ng pag-encrypt.