Kill switchar och regler mot överlappning pekar i motsatta riktningar, vilket förklarar varför vanliga VPN-inställningar aldrig uttrycker den andra. Kill switchen reagerar på en tunnel som fallit, medan detta krav reagerar på en tunnel som är uppe och håller en applikation utanför bilden. Ett designbeslut avgör det mesta: om applikationen stoppas, hindras att starta eller bara berövas nätverksåtkomst. Välj det lagret innan du griper efter en brandväggsregel eller en processdödande loop, för en regel som upprätthålls genom observation läcker ett fönster vid varje start.

Myten: en kill switch hindrar program från att starta

Kill switchar är trafikkontroller, och de är ärliga om det: de tillåter eller nekar paket efter tunnelns tillstånd. Ingen av dem vägrar starta ett program, och ingen inspekterar vilken körbar fil som öppnade en socket. En skrivbordsgenväg, en schemalagd uppgift och en bakgrundshjälpare når alla nätverket utan att passera något som känner till applikationens namn. Avståndet mellan dessa två mekanismer är där det mesta av förvirringen bor.

Den ordning som faktiskt avgör om ett program får starta är applikationskontroll. På Windows betyder det AppLocker eller WDAC, och på hanterad macOS betyder det en tillåtelselista som upprätthålls av enhetsprofilen. Båda är oberoende av tunneln, och därför slås de två kraven ihop i samma ärende och uppfylls sedan av inget av dem.

Namnge läget innan du namnger verktyget

Skriv regeln som en tillståndsmaskin med tre tillstånd: vanlig användning, VPN-arbetspass och avslut. Den förbjudna överlappningen hör till det mellersta tillståndet, inte till klientprogramvaran.

Den som ändrar tillståndet äger tre åtgärder i ordning: slutföra applikationens arbete, begära dess normala avstängning och bekräfta att instansen är borta innan tunneln kommer upp. Ordningen spelar också roll i andra änden, för en VPN som ansluter först och stoppar programmet sedan har redan tillåtit överlappningen. Om kravet omfattar upprättandet av anslutningen är det för sent att vänta på en ansluten-indikator.

Vad en tvåvägskonflikt faktiskt gör

För två tjänster som verkligen hanteras av systemd är Conflicts= symmetriskt: start av den ena stoppar den andra. Unit-referensen dokumenterar detta beteende och kräver separat en uttrycklig ordning när den ena måste slutföra stoppet innan den andra startar. Utan dessa ordningsposter tävlar stopp och start, och resultatet beror på timing.

Det är inte en blockeringslista. Koppla beroendet bakvänt och start av applikationen stoppar i stället VPN, vilket är felet man bör misstänka när en tunnel kopplar ifrån sig själv vid en förutsägbar tidpunkt. En skrivbordsapplikation är inte en systemd-unit, och en NetworkManager-anslutning är inte heller en unit, så detta mönster fungerar bara för tjänster du själv paketerar.

Testa övergångarna, inte bara första starten

Fyra övergångar avgör om kravet håller: att gå in i passet med applikationen körande, att starta den igen mitt i passet, en misslyckad VPN-start och en avsiktlig frånkoppling. Testa var och en och förvara resultatet bredvid unit-filerna. Kommandona nedan läser den nuvarande relationen och övar sedan den övergång som 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

Det tredje kommandot bör lämna applikationen inaktiv, och det fjärde bör bara lista tunnelanslutningen medan ett pass körs. Ett annat resultat betyder att övergången inte upprätthålls alls.

Omstarten under passet är fallet som avslöjar en design baserad på inkapsling, eftersom en genväg som startas från skrivbordet aldrig konsulterar ett startskript. Om detta kringgående spelar roll hör upprätthållandet hemma i applikationskontroll och inte i VPN-klienten. Dokumentera också slutet på passet, och föredra en avsiktlig återupptagning framför att öppna varje process som stoppades vid inträdet igen. Notera resultatet av varje övergång i samma anteckning som förvarar unit-filerna.

Relaterade artiklar