Kill switch bawat app kumpara sa pag-lock ng buong device: ano ang nagbabago

Ang kill switch bawat app ay parang maingat na pagpipilian: kapag bumagsak ang tunnel, ang work client lang ang nawawalan ng network, at patuloy na gumagana ang lahat ng iba. Tapos may makakapansin na nag-load pa rin ng pahina ang personal na browser, patuloy na nagtatangka ang sync helper na kasama ng parehong suite, at ang pangalang naka-cache ay niresolba pa rin sa address na hindi kailanman dumaan sa tunnel. Ang label sa feature at ang set ng koneksyong talagang pinoprotektahan nito ay dalawang magkaibang bagay. Tukuyin muna ang pinoprotektahang set, dahil ang set na iyon ang nagtatakda kung ang pagpapatupad bawat app o pag-lock ng buong device ang tapat na paglalarawan.

Magsimula sa set, hindi sa label

Pinoprotektahan ng patakaran bawat app ang mga piling application. Ang pag-lock ng device ay tumutungo sa mas malawak na hangganan ng network, kadalasan may mga nakadokumentong eksepsyon para sa lokal na pag-print, trapikong pang-administrasyon o captive portal. Wala sa dalawang label ang kumpleto hangga't hindi mo masagot ang tatlong tanong: ano ang nangyayari sa mga ibinukod na app, ano ang nangyayari sa mga helper na sinisimulan ng mga app na iyon, at ano ang nangyayari sa mga koneksyong binuksan habang hindi available ang proteksyon.

Isulat ang mga sagot na iyon bago hawakan ang anumang setting ng client. Kung ang pangangailangan ay "hindi dapat kailanman makipag-usap sa internet sa labas ng tunnel ang payroll client na ito, at ang browser ko ay maaari", maliit ang set at angkop ang pagpapatupad bawat app. Kung ang pangangailangan ay "walang anuman sa device na ito ang umabot sa internet nang walang proteksyon, maliban sa serbisyo ng update", walang patakaran bawat app ang gagawa niyon, dahil ang mga app na hindi mo pinangalanan ang problema.

Ang pagpapatupad bawat app ay tumutugma sa mga identifier, hindi sa mga pangalan ng programa

Inilalantad ng Android ang VPN bawat app sa pamamagitan ng mga package, at inilalarawan ng dokumentasyon ng VpnService nito kung paano ito nakikipag-ugnayan sa always-on na operasyon at pag-block. Kinokonfigura ng iOS ang VPN bawat app sa pamamagitan ng management profile at tumutugma ayon sa app o ayon sa domain. Walang ruta bawat proseso ang Windows at Linux, kaya ang parehong ideya ay tinatantiya ng firewall rule na limitado sa isang programa o ng rule na tumutugma sa nagmamay-ari na user.

Ang hangganan ay ang identifier, at madaling iwasan ang mga identifier. Ang app na naghahatid ng URL sa system browser, o nagbubukas ng dokumento sa viewer, ay lumilipat sa prosesong hindi kailanman pinangalanan ng iyong patakaran. Ang opsyon na wakasan kapag bumagsak ay hindi rin packet filter: pinapatay nito ang app na iyong kinonfigura, habang ang child process, queue worker o browser tab ay maaaring panatilihing buhay ang umiiral na socket.

Sinasaklaw ng pag-lock ang hindi nakikita ng patakaran bawat app

Tinatanggal ng pag-lock ng buong device ang pagpipilian. Bawat palabas na packet na hindi kabilang sa tunnel ay itinatapon, kasama ang trapiko mula sa mga prosesong hindi kailanman alam ng iyong patakaran sa app. Sa Android ito ay always-on na VPN na sinamahan ng setting na nagba-block ng mga koneksyon, at nangyayari ang pagpapatupad sa system, hindi sa window ng client. Sa desktop ito ay palagiang firewall rule o default na ruta na nakaturo sa hindi maabot na gateway.

Ang halaga ay humihinto ang lahat ng iba, kaya ang mga eksepsyon ay nagiging bahagi ng disenyo at hindi dagdag na isipan. Ang mga lokal na printer, pagtuklas ng serbisyo, pag-log in sa captive portal, mga ahente ng pamamahala at mga update ng OS ay nangangailangan ng nakadokumentong butas, dahil bawat isa ay landas na nananatiling bukas kapag down ang tunnel. Ang pag-lock ay kasing lakas lamang ng pinakamaikling entry sa listahang iyon.

Itinatago ng DNS, IPv6 at background helper ang mga leak

Ang kabiguan ng protektadong app na i-resolve ang isang pangalan ay hindi nagpapatunay na naka-block ang mga naka-cache na sagot o direktang IP traffic. Kung maabot pa rin ang resolver sa labas ng tunnel, niresolba ang pangalan at nabigo ang koneksyon, na mukhang gumaganang kill switch at hindi naman. Mas malala, ang naka-cache na record ay maaaring tumuro sa address na hindi dinadala ng tunnel, kaya direktang lumalabas ang koneksyon habang nag-uulat ang app ng VPN error.

Kailangan ng IPv6 ang sarili nitong rule sa bawat platform na nagpapatakbo nito, dahil hindi sinasaklaw ng drop rule para sa v4 ang rutang v6. Sa mobile, ang setting ng pribadong DNS ay maaaring maglipat ng resolution sa naka-encrypt na channel na hindi sinusuri ng patakaran ng device. At ang mga background helper ang karaniwang salarin sa desktop: ang proseso ng updater o sync sa tray ay nagsisimula bago ang VPN client at pinapanatili ang sarili nitong koneksyon, kaya hindi nito kailanman nakikita ang nabagong ruta.

Subukan ang tatlong app at dalawang transisyon

Patakbuhin ang bawat hilera nang dalawang beses, isang beses gamit ang hostname at isang beses gamit ang literal na address, at isa pang beses sa IPv6 kung inaalok ito ng network. Ang pagpasa ay nangangahulugang huminto ang kasamang app, kumilos ang ibinukod ayon sa isinulat mo, at hindi nakatakas ang helper. Itala ang direktang pag-uugaling itinuring mong katanggap-tanggap, para makilala ng susunod na administrador ang sinadyang eksepsyon sa isang pagkabigo.

Pagkatapos, ilarawan ang resulta sa isang pangungusap na nagpangalan sa mga app at kundisyon, halimbawa: walang ruta sa labas ng tunnel ang payroll client, direktang ang browser ayon sa disenyo, at humihinto ang lahat ng iba kapag down ang tunnel. Kung mahirap isulat ang pangungusap na iyon, dalawang patakaran pa rin ang patakarang iyon na nag-aaway.