Appen skal ikkje køyre medan VPN-en er på: kva som handhevar det

Kill switches og reglar mot overlapp peikar i motsette retningar, noko som forklarar kvifor vanlege VPN-innstillingar aldri uttrykkjer den andre. Kill switchen reagerer på ein tunnel som har falle, medan dette kravet reagerer på ein tunnel som er oppe og held ein applikasjon utanfor biletet. Éi designavgjerd avgjer det meste: om applikasjonen blir stoppa, hindra i å starte, eller berre fråteken nettilgang. Vel det laget før du grip etter ein brannmurregel eller ei prosessdrepande løkke, for ein regel som blir handheva ved observasjon, lek eit vindauge ved kvar start.

Myten: ein kill switch hindrar program i å starte

Kill switches er trafikkontroll, og dei er ærlege om det: dei tillèt eller avviser pakkar etter tilstanden til tunnelen. Ingen av dei nektar å starte eit program, og ingen granskar kva køyrbar fil som opna ein socket. Ein skrivebordssnarveg, ei planlagd oppgåve og ein bakgrunnshjelpar når alle nettverket utan å passere noko som kjenner namnet på applikasjonen. Avstanden mellom dei to mekanismane er der mesteparten av forvirringa bur.

Ordninga som faktisk avgjer om eit program får starte, er applikasjonskontroll. På Windows tyder det AppLocker eller WDAC, og på administrert macOS tyder det ei tillatingsliste som blir handheva av einingprofilen. Begge er uavhengige av tunnelen, og difor blir dei to krava slått saman i same sak og deretter oppfylte av ingen av dei.

Namngje modusen før du namngjev verktøyet

Skriv regelen som ein tilstandsmaskin med tre tilstandar: vanleg bruk, VPN-arbeidsøkt og avslutning. Den forbodne overlappen høyrer til den midtarste tilstanden, ikkje klientprogramvara.

Den som endrar tilstanden, eig tre handlingar i rekkjefølgje: fullføre arbeidet til applikasjonen, be om normal nedstenging og stadfeste at instansen er borte før tunnelen kjem opp. Rekkjefølgja tel også i den andre enden, for ein VPN som koplar til først og stoppar programmet etterpå, har allereie tillate overlappen. Viss kravet dekkjer etablering av sambandet, er det for seint å vente på ein tilkopla-indikator.

Kva ein tovegs konflikt faktisk gjer

For to tenester som faktisk blir styrte av systemd, er Conflicts= symmetrisk: start av den eine stoppar den andre. Unit-referansen dokumenterer denne åtferda og krev separat ei eksplisitt rekkjefølgje når den eine må fullføre stopp før den andre startar. Utan desse rekkjefølgjepostane kappast stopp og start, og resultatet er avhengig av timing.

Det er ikkje ei blokkeringsliste. Kopla avhengigheita feil veg, og start av applikasjonen stoppar i staden VPN-en, som er feilen ein bør mistenke når ein tunnel koplar seg frå av seg sjølv på eit føreseieleg tidspunkt. Ein skrivebordsapplikasjon er ikkje ein systemd-unit, og ei NetworkManager-tilkopling er heller ikkje ein unit, så dette mønsteret verkar berre for tenester du pakkar inn sjølv.

Test overgangane, ikkje berre første start

Fire overgangar avgjer om kravet held: å gå inn i økta med applikasjonen køyrande, å starte han på nytt midt i økta, ein mislukka VPN-start og ein medviten fråkopling. Test kvar einaste og oppbevar resultatet ved sida av unit-filene. Kommandoane nedanfor les den noverande relasjonen og øver deretter på overgangen som tel mest.

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

Den tredje kommandoen bør la applikasjonen vere inaktiv, og den fjerde bør berre liste tunneltilkoplinga medan ei økt køyrer. Eit anna resultat tyder på at overgangen ikkje blir handheva i det heile.

Ny start under økta er tilfellet som avdekkjer eit innpakningsbasert design, fordi ein snarveg starta frå skrivebordet aldri konsulterer eit startskript. Viss denne omgåinga tel, høyrer handhevinga heime i applikasjonskontroll og ikkje i VPN-klienten. Dokumenter også slutten på økta, og føretrekk ein medviten gjenopptaking framfor å opne på nytt kvar prosess som vart stoppa ved inngangen. Noter resultatet av kvar overgang i same notatet som oppbevarer unit-filene.