Aplikacija ne smije raditi dok je VPN uključen: što to provodi

Kill switch i pravila zabrane preklapanja pokazuju u suprotnim smjerovima, što objašnjava zašto obične VPN postavke nikad ne izražavaju drugo. Kill switch reagira na tunel koji je pao, dok ovaj zahtjev reagira na tunel koji je podignut i drži aplikaciju izvan slike. Jedna dizajnerska odluka rješava većinu: da li se aplikacija zaustavlja, blokira njeno pokretanje ili joj se samo oduzima mrežni pristup. Odaberite taj sloj prije nego posegnete za pravilom vatrozida ili petljom za ubijanje procesa, jer pravilo provedeno promatranjem propušta prozor pri svakom pokretanju.

Mit: kill switch sprječava programe da se pokrenu

Kill switch je kontrola prometa i iskreni su u vezi s tim: dopuštaju ili odbijaju pakete prema stanju tunela. Nijedan od njih ne odbija pokretanje programa i nijedan ne provjerava koja je izvršna datoteka otvorila socket. Prečica na radnoj površini, zakazani zadatak i pozadinski pomoćnik svi dolaze do mreže ne prolazeći kroz nešto što zna ime aplikacije. Razmak između ta dva mehanizma mjesto je gdje živi većina zabune.

Postavka koja zaista odlučuje smije li program početi jest kontrola aplikacija. Na Windowsu to znači AppLocker ili WDAC, a na upravljanom macOS-u popis dopuštenih koji provodi profil uređaja. Oba su neovisna od tunela, zato se dva zahtjeva spajaju u isti tiket i onda ih ne zadovoljava nijedan.

Imenujte režim prije nego imenujete alat

Napišite pravilo kao stroj stanja s tri stanja: obična upotreba, radna sesija VPN-a i izlazak. Zabranjeno preklapanje pripada srednjem stanju, a ne klijentskom softveru.

Ko mijenja stanje, posjeduje tri radnje po redu: završiti rad aplikacije, zatražiti njeno normalno isključivanje i potvrditi da je instanca nestala prije nego se tunel podigne. Redoslijed je važan i na drugom kraju, jer VPN koji se prvo poveže i zatim zaustavi program već je dopustio preklapanje. Ako zahtjev pokriva uspostavljanje veze, čekanje na indikator povezanosti je prekasno.

Što dvosmjerni sukob zaista radi

Za dvije usluge koje stvarno upravlja systemd, Conflicts= je simetričan: pokretanje jedne zaustavlja drugu. Referenca za unit dokumentira to ponašanje i zasebno zahtijeva izričit redoslijed kada jedna mora završiti zaustavljanje prije nego druga počne. Bez tih unosa redoslijeda zaustavljanje i pokretanje se utrkuju, a ishod ovisi o vremenu.

To nije popis zabrana. Spojite ovisnost naopako i pokretanje aplikacije umjesto toga zaustavlja VPN, što je kvar koji treba sumnjati kada se tunel sam prekine u predvidljivom trenutku. Stolna aplikacija nije systemd unit, a ni NetworkManager veza nije unit, pa ovaj obrazac radi samo za usluge koje sami obavijate.

Provjerite prijelaze, ne samo prvo pokretanje

Četiri prijelaza odlučuju drži li zahtjev: ulazak u sesiju s pokrenutom aplikacijom, njeno ponovno pokretanje usred sesije, neuspjelo pokretanje VPN-a i namjerno prekidanje. Testirajte svaki i čuvajte rezultat uz unit datoteke. Naredbe ispod čitaju trenutni odnos i zatim vježbaju prijelaz koji je najvažniji.

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ća naredba treba ostaviti aplikaciju neaktivnom, a četvrta navesti samo tunelsku vezu dok sesija traje. Drugačiji rezultat znači da prijelaz uopće nije proveden.

Ponovno pokretanje tijekom sesije slučaj je koji razotkriva dizajn temeljen na omotaču, jer prečica pokrenuta s radne površine nikad ne konzultira skriptu za pokretanje. Ako je taj zaobilaz važan, provedba pripada kontroli aplikacija, a ne VPN klijentu. Dokumentirajte i kraj sesije i radije namjerno nastavljanje nego ponovno otvaranje svakog procesa zaustavljenog pri ulasku. Zabilježite rezultat svakog prijelaza u istoj bilješci koja čuva unit datoteke.