Dalawang app ang nagbubukas ng koneksyon sa parehong office server, at isa lamang sa kanila ang dapat gumamit ng tunnel. Hindi maipahayag ng isang ruta ang kagustuhang iyon, dahil nakabatay sa destinasyon ang mga routing table at wala silang kaalaman kung aling proseso ang nagbukas ng socket. Madalas magkaiba ang hinihiling ng mga tao at ang kailangan nila. Paghiwalayin ang dalawa bago baguhin ang anumang configuration.

Ang pumipili ay destinasyon, hindi kailanman proseso

Nagsisimula ang bawat desisyon sa routing sa isang destinasyong address at nagtatapos sa isang interface. Hindi kailanman tinatanong ng kernel kung aling programa ang nagpadala ng packet, at sa macOS hindi rin nagruruta ang pf ayon sa proseso, kaya hindi maaaring ilagay ng isang firewall rule ang isang app sa ibang landas. Kaya ang parehong server, mula man sa browser o sa tool sa pag-uulat, ay isang landas para sa dalawa. Kaya ang paghihiwalay sa antas ng app ay dapat magmula sa iba pa maliban sa ruta: isang VPN plugin na nagmamay-ari ng socket, isang proxy na kumukuha ng koneksyon sa ngalan ng app, o isang hiwalay na network stack. Wala sa mga ito ang pagbabago sa routing.

Dalawang app na kausap ang isang address ang pinakamalinis na pagsubok ng isang disenyo. Kung hindi maaaring magkaiba ang sagot sa pagitan nila, nakabatay sa destinasyon ang disenyo, anuman ang itawag dito.

Ano ang tunay na naibibigay ng ordinaryong split tunnel

Nag-iinstall ang split tunnel ng mga ruta para sa mga pribadong prefix at iniiwan ang lahat ng iba sa pisikal na landas. Karaniwang ito ang ibig sabihin ng kahilingan: maabot ang office server sa pamamagitan ng tunnel, panatilihing direkta ang pampublikong pag-browse. Simple ito, sinusuportahan ito ng bawat karaniwang client, at ipinapatupad ito ng parehong mekanismo tulad ng anumang iba pang ruta. Suriin ang partikular na destinasyon gamit ang route -n get sa halip na basahin ang default na ruta, dahil madalas na iniiwan ng split tunnel na hindi ginalaw ang default na ruta.

Ang mano-manong pag-edit ng default na ruta ay hindi conversion sa anuman. Nakikipaglaban ito sa sariling pagpapanumbalik ng ruta ng client at, sa mga client na nag-iinstall ng patakaran sa proteksyon, maaaring iwan ang makina sa kalagayang hindi inaasahan ninyo o ng client. I-configure ang split tunnel sa mga sinusuportahang setting ng client.

Ano ang kailangan ng per-app VPN sa macOS

Ang tunay na per-app VPN sa macOS ay isang tampok na Network Extension na pinapatakbo ng isang configuration profile. Ang isang management payload ay nagmamapa ng mga piling app sa isang VPN configuration, at pagkatapos ay iruruta ng system ang trapiko ng mga app na iyon nang naaayon. Isa itong pinamamahalaang deployment, na nangangahulugan ng MDM, isang pinirmahang profile, at isang administrator na nagmamay-ari ng dalawa.

Ang mano-manong pag-install ng client ay hindi lumilikha ng mapping na iyon, at hindi ginagawang indibidwal na mapipili ng ordinaryong settings pane ang mga app. Maaaring ilantad ng vendor ang sarili nitong mga patakaran sa app, at sinusunod ng mga iyon ang dokumentasyon nito sa halip na isang pangkalahatang tuntunin.

Tatlong paraan ng paghihiwalay bawat app nang walang MDM

Kung saan walang management, ang proxy ang praktikal na sagot. Itakda ang sariling proxy configuration ng app, o gumamit ng PAC file na pumipili ayon sa destinasyon at protocol para lamang sa app na iyon.

Tinatapos ng lokal na proxy ang koneksyon at muling nililikha ito sa pamamagitan ng tunnel, kaya hindi kailanman kailangan ng app ang isang ruta. Ang ikalawang opsyon ay isang hiwalay na network stack: isang virtual machine o container na may sariling default na ruta, na naaabot ng app sa pamamagitan ng lokal na address. Ang ikatlo ay tanggapin ang routing na nakabatay sa destinasyon at bitawan ang pangangailangan, na tapat kapag parehong app ay pinapayagang gumamit ng tunnel. Lahat ng tatlo ay masusubok, at wala sa kanila ang nagpapanggap na alam ng isang ruta ang mga proseso.

Isulat ang kahilingan para hindi malabo ang sagot

Ilarawan ang workflow sa halip na ang mekanismo: aling app ang nangangailangan ng aling serbisyo, kailangan bang ilayo ang isa pang app sa parehong serbisyo, at ano ang dapat mangyari habang patay ang tunnel. Ang tatlong sagot na iyon ang pumipili ng disenyo. Sinasabi rin nila sa administrator kung ang kahilingan ay pagbabago sa routing o proyekto ng deployment.

Isama nang tahasan ang kaso ng ibinukod na app. Ang client na humihinto sa isang app kapag hindi available ang protektadong landas nito ay kumikilos nang iba kaysa sa client na hinahayaang bumalik ito sa pisikal na interface, at agad napapansin ng mga user ang pagkakaibang iyon. Pangalanan ang inaasahan sa ticket. Pagkatapos ay i-verify sa aktwal na makina, dahil madalas na kumikilos nang iba ang parehong produkto sa macOS kaysa sa Windows, at ang dokumentasyon nito para sa macOS ang tanging mapagkakatiwalaang pinagmulan kung ano ang ginagawa ng mga setting nito.

Kaugnay na mga artikulo