Kill switches og regler mot overlapp peker i hver sin retning, og det forklarer hvorfor vanlige VPN-innstillinger aldri uttrykker den andre. Kill switchen reagerer på en tunnel som er nede, mens dette kravet reagerer på en tunnel som er oppe og holder en applikasjon utenfor bildet. Én designbeslutning avgjør mesteparten: om applikasjonen stanses, hindres i å starte, eller bare mister nettilgangen. Velg det laget før du tar i bruk en brannmurregel eller en løkke som dreper prosesser, for en regel som håndheves ved observasjon, lekker et vindu ved hver oppstart.

Myten: en kill switch hindrer programmer i å starte

Kill switches er trafikkontroll, og de er ærlige på det: de slipper gjennom 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 snarvei på skrivebordet, en planlagt oppgave og en bakgrunnshjelper når alle nettverket uten å gå gjennom noe som kjenner navnet på applikasjonen. Avstanden mellom disse to mekanismene er der det meste av forvirringen holder til.

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

Gi modusen et navn før du gir verktøyet et navn

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

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

Hva en toveis konflikt faktisk gjør

For to tjenester som virkelig styres av systemd, er Conflicts= symmetrisk: start av den ene stanser den andre. Unit-referansen dokumenterer denne oppførselen og krever separat en tydelig rekkefølge når den ene må fullføre stansingen før den andre starter. Uten disse rekkefølgeoppføringene konkurrerer stansing og start, og resultatet avhenger av tidspunktet.

Det er ikke en blokkeringsliste. Koble avhengigheten feil vei, og start av applikasjonen stanser i stedet VPN-en, som er feilen du 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 den første oppstarten

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-oppstart og en bevisst frakobling. Test hver av dem 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 skal la applikasjonen være inaktiv, og den fjerde skal bare liste tunnelstilkoblingen mens en økt pågår. Et annet resultat betyr at overgangen ikke håndheves i det hele tatt.

Omstart under økten er tilfellet som avdekker et innpakningsbasert design, fordi en snarvei som startes fra skrivebordet aldri spør et oppstartsskript. Hvis denne omgåelsen betyr noe, hører håndhevingen til i applikasjonskontroll og ikke i VPN-klienten. Dokumenter også slutten av økten, og foretrekk en bevisst gjenopptakelse fremfor å gjenåpne hver prosess som ble stanset ved inngangen. Noter resultatet av hver overgang i samme notat som oppbevarer unit-filene.

Relaterte artikler