Lietotnei nevajadzētu darboties, kamēr VPN ir ieslēgts: kas to panāk

Kill switch un pārklāšanās aizlieguma noteikumi norāda pretējos virzienos, kas izskaidro, kāpēc parastie VPN iestatījumi nekad neizsaka otro. Kill switch reaģē uz tuneli, kas ir nokritis, savukārt šī prasība reaģē uz tuneli, kas ir augšā, un tur lietotni ārpus attēla. Viens dizaina lēmums atrisina lielāko daļu: vai lietotne tiek apturēta, vai tai tiek liegts startēt, vai vienkārši tiek atņemta piekļuve tīklam. Izvēlieties šo slāni, pirms ķeraties pie ugunsmūra noteikuma vai procesus nogalinošas cilpas, jo noteikums, kas tiek izpildīts ar novērošanu, katrā palaišanā noplūdina logu.

Mīts: kill switch liedz programmām startēt

Kill switch ir trafika kontrole, un viņi par to ir godīgi: tie atļauj vai noraida paketes atkarībā no tuneļa stāvokļa. Neviens no tiem neatsakās palaist programmu, un neviens nepārbauda, kurš izpildfails atvēra ligzdu. Darbvirsmas saīsne, ieplānots uzdevums un fona palīgs visi sasniedz tīklu, neizejot cauri nekam, kas zina lietotnes nosaukumu. Attālums starp šiem diviem mehānismiem ir vieta, kur dzīvo lielākā daļa apjukuma.

Kārtība, kas patiešām izlemj, vai programma drīkst startēt, ir lietotņu kontrole. Windows tas nozīmē AppLocker vai WDAC, bet pārvaldītā macOS — ierīces profila izpildītu atļauto sarakstu. Abi ir neatkarīgi no tuneļa, tāpēc abas prasības tiek apvienotas vienā biļetē un pēc tam neviena no tām netiek izpildīta.

Nosauciet režīmu, pirms nosaucat rīku

Rakstiet noteikumu kā stāvokļu mašīnu ar trim stāvokļiem: parasta lietošana, VPN darba sesija un iziešana. Aizliegtā pārklāšanās pieder vidējam stāvoklim, nevis klienta programmatūrai.

Kam pieder stāvokļa maiņa, tam ir trīs darbības secībā: pabeigt lietotnes darbu, pieprasīt tās parasto izslēgšanu un apstiprināt, ka eksemplārs ir pazudis, pirms tunelis paceļas. Secība ir svarīga arī otrā galā, jo VPN, kas pieslēdzas pirmais un pēc tam aptur programmu, jau ir pieļāvis pārklāšanos. Ja prasība ietver savienojuma izveidi, gaidīt savienots indikatoru ir par vēlu.

Ko divvirzienu konflikts patiešām dara

Diviem pakalpojumiem, ko patiešām pārvalda systemd, Conflicts= ir simetrisks: viena palaišana aptur otru. Unit atsauce dokumentē šo uzvedību un atsevišķi pieprasa skaidru secību, kad vienam jāpabeidz apstāšanās pirms otra sākšanas. Bez šiem secības ierakstiem apstāšanās un palaišana sacenšas, un rezultāts ir atkarīgs no laika.

Tas nav aizliegto saraksts. Pieslēdziet atkarību pretēji, un lietotnes palaišana tā vietā apturēs VPN, kas ir kļūme, kura jāuzskata par aizdomīgu, kad tunelis pats atvienojas paredzamā brīdī. Darbvirsmas lietotne nav systemd unit, un NetworkManager savienojums arī nav unit, tāpēc šis modelis darbojas tikai tiem pakalpojumiem, kurus jūs pats aptinat.

Pārbaudiet pārejas, nevis tikai pirmo palaišanu

Četras pārejas izlemj, vai prasība pastāv: ieiešana sesijā ar darbojošos lietotni, tās atkārtota palaišana sesijas vidū, neizdevusies VPN palaišana un tīša atvienošanās. Pārbaudiet katru un glabājiet rezultātu blakus unit failiem. Tālāk minētās komandas nolasa pašreizējo attiecību un pēc tam praktizē svarīgāko pāreju.

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

Trešajai komandai lietotne jāatstāj neaktīva, bet ceturtajai sesijas laikā jāuzskaita tikai tuneļa savienojums. Citāds rezultāts nozīmē, ka pāreja netiek izpildīta vispār.

Atkārtota palaišana sesijas laikā ir gadījums, kas atklāj apvalkā balstītu dizainu, jo saīsne, kas palaista no darbvirsmas, nekad nekonsultējas ar palaišanas skriptu. Ja šī apiešana ir svarīga, izpilde pieder lietotņu kontrolei, nevis VPN klientam. Dokumentējiet arī sesijas beigas un dodiet priekšroku apzinātai turpināšanai, nevis katra ieceļot apturētā procesa atkārtotai atvēršanai. Ierakstiet katras pārejas rezultātu tajā pašā piezīmē, kurā glabājas unit faili.