Appen skal ikke kjøre mens VPN-en er på: hva som håndhever det

Kill switches og regler mot overlapp peker i motsatte retninger, noe som forklarer hvorfor vanlige VPN-innstillinger aldri uttrykker den andre. Kill switchen reagerer på en tunnel som har falt, mens dette kravet reagerer på en tunnel som er oppe og holder en applikasjon utenfor bildet. Én designbeslutning avgjør det meste: om applikasjonen stoppes, hindres i å starte, eller bare fratas nettverkstilgang. Velg det laget før du griper etter en brannmurregel eller en prosessdrepende løkke, for en regel som håndheves ved observasjon lekker et vindu ved hver start.

Myten: en kill switch hindrer programmer i å starte

Kill switches er trafikkontroll, og de er ærlige om det: de tillater eller avviser pakker etter tunnelens tilstand. Ingen av dem nekter å starte et program, og ingen undersøker hvilken kjørbar fil som åpnet en socket. En skrivebordsnarvei, en planlagt oppgave og en bakgrunnshjelper når alle nettverket uten å passere noe som kjenner applikasjonens navn. Avstanden mellom de to mekanismene er der mesteparten av forvirringen bor.

Ordningen som faktisk avgjør om et program får starte, er applikasjonskontroll. På Windows betyr det AppLocker eller WDAC, og på administrert macOS betyr det en tillatelsesliste som håndheves av enhetsprofilen. Begge er uavhengige av tunnelen, og derfor slås de to kravene sammen i samme sak og blir deretter oppfylt av ingen av dem.

Navngi modusen før du navngir verktøyet

Skriv regelen som en tilstandsmaskin med tre tilstander: vanlig bruk, VPN-arbeidsøkt og avslutning. Den forbudte overlappen tilhører den midterste tilstanden, ikke klientprogramvaren.

Den som endrer tilstanden, eier tre handlinger i rekkefølge: fullføre applikasjonens arbeid, be om normal nedstenging og bekrefte at instansen er borte før tunnelen kommer opp. Rekkefølgen betyr også noe i den andre enden, for en VPN som kobler til først og stopper programmet etterpå, har allerede tillatt overlappen. Hvis kravet dekker etablering av forbindelsen, er det for sent å vente på en tilkoblet-indikator.

Hva en toveis konflikt faktisk gjør

For to tjenester som faktisk styres av systemd, er Conflicts= symmetrisk: start av den ene stopper den andre. Unit-referansen dokumenterer denne atferden og krever separat en eksplisitt rekkefølge når den ene må fullføre stopp før den andre starter. Uten disse rekkefølgeoppføringene kappes stopp og start, og resultatet avhenger av timing.

Det er ikke en blokkeringsliste. Koble avhengigheten feil vei, og start av applikasjonen stopper i stedet VPN-en, som er feilen man bør mistenke når en tunnel kobler seg fra av seg selv på et forutsigbart tidspunkt. En skrivebordsapplikasjon er ikke en systemd-unit, og en NetworkManager-tilkobling er heller ikke en unit, så dette mønsteret virker bare for tjenester du pakker inn selv.

Test overgangene, ikke bare første start

Fire overganger avgjør om kravet holder: å gå inn i økten med applikasjonen kjørende, å starte den på nytt midt i økten, en mislykket VPN-start og en bevisst frakobling. Test hver enkelt og oppbevar resultatet ved siden av unit-filene. Kommandoene nedenfor leser den nåværende relasjonen og øver deretter på overgangen som betyr 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 være inaktiv, og den fjerde bør bare liste tunnelstilkoblingen mens en økt kjører. Et annet resultat betyr at overgangen ikke håndheves i det hele tatt.

Ny start under økten er tilfellet som avslører et innpakningsbasert design, fordi en snarvei startet fra skrivebordet aldri konsulterer et startskript. Hvis denne omgåelsen betyr noe, hører håndhevingen hjemme i applikasjonskontroll og ikke i VPN-klienten. Dokumenter også slutten på økten, og foretrekk en bevisst gjenopptakelse fremfor å gjenåpne hver prosess som ble stoppet ved inngangen. Noter resultatet av hver overgang i samme notat som oppbevarer unit-filene.