Aplikacija ne sme teči, medtem ko je VPN vklopljen: kaj to uveljavlja

Kill switchi in pravila prepovedi prekrivanja kažejo v nasprotni smeri, kar pojasnjuje, zakaj običajne nastavitve VPN nikoli ne izrazijo drugega. Kill switch se odziva na tunel, ki je padel, medtem ko se ta zahteva odziva na tunel, ki je gor, in drži aplikacijo izven slike. Ena oblikovalska odločitev reši večino: ali se aplikacija ustavi, se ji prepreči zagon ali se ji samo odvzame dostop do omrežja. Izberite to plast, preden segate po pravilu požarnega zidu ali zanki za ubijanje procesov, ker pravilo, uveljavljeno z opazovanjem, pušča okno pri vsakem zagonu.

Mit: kill switch preprečuje zagon programov

Kill switchi so nadzor prometa in so glede tega pošteni: dovolijo ali zavrnejo pakete glede na stanje tunela. Noben od njih ne zavrne zagona programa in noben ne pregleda, kateri izvršljivi program je odprl vtičnico. Bližnjica na namizju, načrtovana naloga in pomočnik v ozadju vsi dosežejo omrežje, ne da bi šli skozi kaj, kar pozna ime aplikacije. Razdalja med tema mehanizmoma je kraj, kjer živi večina zmede.

Ureditev, ki res odloči, ali se program sme zagnati, je nadzor aplikacij. V Windows to pomeni AppLocker ali WDAC, v upravljanem macOS pa seznam dovoljenih, ki ga uveljavlja profil naprave. Oba sta neodvisna od tunela, zato se zahtevi združita v isto zahtevo in ju nato ne izpolni nobena.

Poimenujte način, preden poimenujete orodje

Pravilo zapišite kot stroj stanja s tremi stanji: običajna uporaba, delovna seja VPN in izhod. Prepovedano prekrivanje pripada srednjemu stanju, ne odjemalski programski opremi.

Kdor spremeni stanje, ima tri dejanja po vrsti: dokončati delo aplikacije, zahtevati njeno običajno zaustavitev in potrditi, da je primerek izginil, preden se tunel dvigne. Vrstni red šteje tudi na drugem koncu, ker VPN, ki se prvi poveže in nato ustavi program, je prekrivanje že dovolil. Če zahteva zajema vzpostavitev povezave, je čakanje na indikator povezanosti prepozno.

Kaj dvosmerni konflikt v resnici počne

Za dve storitvi, ki ju resnično upravlja systemd, je Conflicts= simetričen: zagon ene ustavi drugo. Referenca enot dokumentira to vedenje in ločeno zahteva izrecen vrstni red, ko mora ena dokončati zaustavitev, preden se druga začne. Brez teh vnosov vrstnega reda se zaustavitev in zagon dirkata, izid pa je odvisen od časa.

To ni seznam prepovedi. Povežite odvisnost v nasprotno smer in zagon aplikacije bo namesto tega ustavil VPN, kar je napaka, ki jo je treba sumiti, ko se tunel sam odklopi v predvidljivem trenutku. Namizna aplikacija ni enota systemd in povezava NetworkManager tudi ni enota, zato ta vzorec deluje le za storitve, ki jih sami ovijete.

Preizkusite prehode, ne le prvega zagona

Štirje prehodi odločijo, ali zahteva drži: vstop v sejo z delujočo aplikacijo, njen ponovni zagon sredi seje, neuspešen zagon VPN in namerna prekinitev. Preizkusite vsakega in rezultat shranite ob datotekah enot. Spodnji ukazi preberejo trenutno razmerje in nato vadijo prehod, ki je najpomembnejši.

systemctl show work-vpn.service -p Conflicts -p After
systemctl start work-vpn.service
systemctl is-active office-sync.service
nmcli connection show --active

Tretji ukaz naj bi pustil aplikacijo neaktivno, četrti pa naj bi med sejo naštel le tunelsko povezavo. Drugačen rezultat pomeni, da prehod sploh ni uveljavljen.

Ponovni zagon med sejo je primer, ki razkrije zasnovo na ovoju, ker bližnjica, zagnana z namizja, nikoli ne posvetuje zagonske skripte. Če je ta obhod pomemben, uveljavljanje spada v nadzor aplikacij in ne v odjemalca VPN. Dokumentirajte tudi konec seje in dajte prednost namernemu nadaljevanju pred ponovnim odpiranjem vsakega procesa, ustavljenega ob vstopu. Rezultat vsakega prehoda zapišite v isto opombo, ki hrani datoteke enot.