Kill switches og regler om ingen overlapning peger i modsatte retninger, hvilket forklarer, hvorfor almindelige VPN-indstillinger aldrig udtrykker den anden. Kill switchen reagerer på en tunnel, der er faldet, mens dette krav reagerer på en tunnel, der er oppe, og holder en applikation ude af billedet. Én designbeslutning afgør det meste: om applikationen stoppes, forhindres i at starte, eller blot fratages netværksadgang. Vælg det lag, før du griber efter en firewallregel eller en procesdræberløkke, for en regel, der håndhæves ved observation, lækker et vindue ved hver start.

Myten: et kill switch forhindrer programmer i at starte

Kill switches er trafikkontrol, og de er ærlige om det: de tillader eller afviser pakker efter tunnelens tilstand. Ingen af dem nægter at starte et program, og ingen undersøger, hvilken eksekverbar fil der åbnede en socket. En skrivebordsgenvej, en planlagt opgave og en baggrundshjælper når alle netværket uden at passere noget, der kender applikationens navn. Afstanden mellem de to mekanismer er, hvor det meste forvirring bor.

Den ordning, der faktisk afgør, om et program må starte, er applikationskontrol. På Windows betyder det AppLocker eller WDAC, og på administreret macOS betyder det en tilladelsesliste, der håndhæves af enhedsprofilen. Begge er uafhængige af tunnelen, og derfor bliver de to krav slået sammen i samme sag og derefter opfyldt af ingen af dem.

Navngiv tilstanden, før du navngiver værktøjet

Skriv reglen som en tilstandsmaskine med tre tilstande: almindelig brug, VPN-arbejdssession og afslutning. Den forbudte overlapning hører til den midterste tilstand, ikke til klientsoftwaren.

Den, der skifter tilstand, ejer tre handlinger i rækkefølge: afslutte applikationens arbejde, anmode om dens normale nedlukning og bekræfte, at instansen er væk, før tunnelen kommer op. Rækkefølgen betyder også noget i den anden ende, for en VPN, der forbinder først og stopper programmet bagefter, har allerede tilladt overlapningen. Hvis kravet dækker forbindelsesoprettelse, er det for sent at vente på en forbundet-indikator.

Hvad en tovejskonflikt egentlig gør

For to tjenester, der reelt styres af systemd, er Conflicts= symmetrisk: start af den ene stopper den anden. Unit-referencen dokumenterer denne adfærd og kræver særskilt en eksplicit rækkefølge, når den ene skal afslutte stop, før den anden starter. Uden de rækkefølgeposter løber stop og start om kap, og resultatet afhænger af timing.

Det er ikke en blokeringsliste. Vend afhængigheden forkert, og start af applikationen stopper i stedet VPN’en, hvilket er den fejl, man skal mistænke, når en tunnel afbryder sig selv på et forudsigeligt tidspunkt. En skrivebordsapplikation er ikke en systemd-unit, og en NetworkManager-forbindelse er heller ikke en unit, så mønsteret virker kun for tjenester, du selv indpakker.

Test overgangene, ikke kun første start

Fire overgange afgør, om kravet holder: at gå ind i sessionen med applikationen kørende, at starte den igen midt i sessionen, et mislykket VPN-start og en bevidst afbrydelse. Test hver enkelt og gem resultatet ved siden af unit-filerne. Kommandoerne nedenfor læser den nuværende relation og udøver derefter den overgang, der betyder 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 kommando bør efterlade applikationen inaktiv, og den fjerde bør kun liste tunnelforbindelsen, mens en session kører. Et andet resultat betyder, at overgangen slet ikke håndhæves.

Genstarten under sessionen er det tilfælde, der afslører et indpakningsbaseret design, fordi en genvej startet fra skrivebordet aldrig spørger en launcher-skript. Hvis den omvej betyder noget, hører håndhævelsen til i applikationskontrol og ikke i VPN-klienten. Dokumentér også slutningen af sessionen, og foretræk en bevidst genoptagelse frem for at genåbne enhver proces, der blev stoppet på vej ind. Notér resultatet af hver overgang i samme note, som opbevarer unit-filerne.

Relaterede artikler