In kill switch per app klinkt as de foarsichtige kar: by it fallen fan 'e tunnel ferliest allinnich de wurkclient syn netwurk, en al it oare bliuwt wurkjen. Dan merkt immen dat de persoanlike browser dochs in side laden hat, dat de syngronisaasjehelper fan deselde pakket trochgie mei besykjen, en dat in cachet namme noch hieltyd oplost waard nei in adres dat de tunnel nea rekke. It label op 'e funksje en de set ferbiningen dy't er echt beskermet, binne twa ferskillende dingen. Bepaal earst de beskerme set, want dy set beslút oft per-app hanthavening of in apparaatbrede ôfsluting de earlike beskriuwing is.

Begjin mei de set, net it label

In belied per app beskermet selekteare apps. In apparaatôfsluting rjochtet him op in bredere netwurkgrins, meastentiids mei dokumintearre útsûnderingen foar lokaal printsjen, beheartraffik of captive portals. Gjin fan beide labels is folslein oant jo trije fragen beäntwurdzje kinne: wat der bart mei útsletten apps, wat der bart mei de helpers dy't dy apps starte, en wat der bart mei ferbiningen dy't iepene wurde wylst beskerming net beskikber is.

Skriuw dy antwurden op foardat jo oan in clientynstelling komme. As de eask is "dizze leanclient mei noait bûten de tunnel mei it ynternet prate, en myn browser mei", is de set lyts en past per-app hanthavening. As de eask is "neat op dit apparaat berikt it ynternet sûnder beskerming, behalve de fernijingstsjinst", sil gjin belied per app dat leverje, want de apps dy't jo net neamden binne it probleem.

Per-app hanthavening matcht identifiers, net programmanammen

Android eksposearret VPN per app fia pakketten, en syn VpnService-dokumintaasje beskriuwt hoe't dat gearwurket mei altyd-oan-wurking en blokkearring. iOS konfigurearret VPN per app fia in behearprofyl en matcht op app of op domein. Windows en Linux hawwe hielendal gjin rûte per proses, dus itselde idee wurdt benadere mei in firewallregel beheind ta in programma of mei in regel dy't matcht op de eignersbrûker.

De grins is de identifier, en identifiers binne maklik om te omsilen. In app dy't in URL oan 'e systeembrowser jout, of in dokumint yn in viewer iepenet, giet nei in proses dat jo belied nea neamde. In opsje foar beëinigjen by fal is ek gjin pakketfilter: dy deadet de app dy't jo konfigurearren, wylst in bernproses, in wachtrige-arbeider of in browserljepper in besteande socket libben hâlde kin.

Ôfsluting dekt wat in belied per app net sjen kin

Apparaatbrede ôfsluting hellet de kar wei. Elk útgeand pakket dat net by de tunnel heart, wurdt weilitten, ek ferkear fan prosessen dêr't jo appbelied nea fan wist. Op Android is dat altyd-oan-VPN kombinearre mei de ynstelling foar it blokkearjen fan ferbiningen, en de hanthavening bart yn it systeem, net yn it clientfinster. Op in desktop is it in oanhâldende firewallregel of in standertrûte nei in ûnberikber gateway.

De kosten binne dat al it oare stopt, sadat de útsûnderingen diel wurde fan it ûntwerp ynstee fan in neitins. Lokale printers, tsjinstûntdekking, oanmelde by captive portals, behearagenten en OS-fernjings hawwe elk in dokumintearre gat nedich, want elk is in paad dat iepen bliuwt as de tunnel del is. De ôfsluting is mar sa sterk as de koartste ynskriuwing op dy list.

DNS, IPv6 en eftergrûnhelpers ferbergje de lekken

Dat in beskerme app in namme net oplosse kin, bewiist net dat cachete antwurden of direkt IP-ferkear blokkearre binne. As de oplosser noch bûten de tunnel berikber is, lost de namme op en mislearret de ferbining, wat liket op in wurkjende kill switch en it net is. Slimmer: in cachet record kin nei in adres wize dat de tunnel net draacht, sadat de ferbining direkt út giet wylst de app in VPN-flater rapportearret.

IPv6 hat syn eigen regel nedich op elk platfoarm dat it draait, want in dropregel foar v4 dekt gjin v6-rûte. Op mobyl kin in privee-DNS-ynstelling de oplossing ferpleatse nei in fersifere kanaal dat it apparaatbelied net ynspektearret. En eftergrûnhelpers binne de gewoane skuldige op desktop: in fernijings- of syngronisaasjeproses begjint foar de VPN-client en hâldt syn eigen ferbining, sadat it de feroare rûte nea sjocht.

Test trije apps en twa oergongen

TestWhat it proves
Included app, by name and by direct IPthe policy is applied, not just the resolver
Excluded app, same checksthe exclusion is intentional and documented
Helper or updater processnothing inherited an older route
Tunnel drop, then Wi-Fi to cellularthe block survives the transition

Rin elke rige twaris, ien kear mei in hostnamme en ien kear mei in letterlik adres, en noch ien kear oer IPv6 as it netwurk dat biedt. In slagge resultaat betsjut dat de ynbegrepen app stoppe, de útsletten app him hâlde en droech sa't jo skreaunen, en de helper net útglûpte. Skriuw it direkte gedrach op dat jo akseptabel fûnen, sadat de folgjende behearder in bewuste útsûndering fan in flater ûnderskiede kin.

Beskriuw dan it resultaat yn ien sin dy't de apps en de betingsten neamt, bygelyks: de leanclient hat gjin rûte bûten de tunnel, de browser is direkt neffens ûntwerp, en al it oare stopt as de tunnel del is. As dy sin dreech te skriuwen is, is it belied noch altyd twa belieds dy't mei-inoar fjochtsje.

Relatearre artikelen