Aplikace nesmí běžet, když je VPN zapnutá: co to vynucuje

Kill switch a pravidla zákazu překryvu ukazují opačným směrem, což vysvětluje, proč běžné nastavení VPN nikdy nevyjadřuje to druhé. Kill switch reaguje na tunel, který spadl, zatímco tento požadavek reaguje na tunel, který je nahoře, a drží aplikaci mimo obraz. Jedno designové rozhodnutí vyřeší většinu: zda se aplikace zastaví, zablokuje se její spuštění, nebo se jí jen odebere síťový přístup. Zvolte tuto vrstvu dřív, než sáhnete po pravidle firewallu nebo smyčce zabíjející procesy, protože pravidlo vynucené pozorováním propouští okno při každém spuštění.

Mýtus: kill switch brání programům ve spuštění

Kill switch jsou řízení provozu a jsou v tom upřímné: povolují nebo odmítají pakety podle stavu tunelu. Žádný z nich neodmítne spustit program a žádný nezkoumá, který spustitelný soubor otevřel socket. Zástupce na ploše, naplánovaná úloha i pomocník na pozadí se dostanou do sítě, aniž by prošly něčím, co zná jméno aplikace. Vzdálenost mezi těmito dvěma mechanismy je místo, kde žije většina zmatku.

Uspořádání, které skutečně rozhoduje, zda program smí začít, je řízení aplikací. Ve Windows to znamená AppLocker nebo WDAC, ve spravovaném macOS seznam povolených vynucený profilem zařízení. Obojí je nezávislé na tunelu, a proto se oba požadavky sloučí do jednoho ticketu a pak je nesplní ani jeden.

Pojmenujte režim dřív, než pojmenujete nástroj

Napište pravidlo jako stavový automat se třemi stavy: běžné použití, pracovní relace VPN a odchod. Zakázaný překryv patří prostřednímu stavu, ne klientskému softwaru.

Kdo mění stav, vlastní tři akce v pořadí: dokončit práci aplikace, požádat o její normální vypnutí a potvrdit, že instance zmizela, než se tunel zvedne. Pořadí je důležité i na druhém konci, protože VPN, která se připojí první a program zastaví druhá, už překryv povolila. Pokud požadavek zahrnuje navázání spojení, čekání na indikátor připojení je pozdě.

Co dvousměrný konflikt skutečně dělá

Pro dvě služby skutečně spravované systemd je Conflicts= symetrické: spuštění jedné zastaví druhou. Reference k unit toto chování dokumentuje a zvlášť vyžaduje explicitní pořadí, když jedna musí dokončit zastavení před startem druhé. Bez těchto položek pořadí se zastavení a start předhánějí a výsledek závisí na čase.

To není seznam zákazů. Zapojte závislost opačně a spuštění aplikace místo toho zastaví VPN, což je porucha, kterou je třeba podezřívat, když se tunel sám odpojí v předvídatelném okamžiku. Desktopová aplikace není unit systemd a připojení NetworkManager také není unit, takže tento vzor funguje jen pro služby, které si sami obalíte.

Testujte přechody, ne jen první spuštění

Čtyři přechody rozhodují, zda požadavek platí: vstup do relace s běžící aplikací, její opětovné spuštění uprostřed relace, neúspěšný start VPN a úmyslné odpojení. Otestujte každý a výsledek uložte vedle unit souborů. Níže uvedené příkazy čtou současný vztah a pak procvičí přechod, na kterém záleží nejvíc.

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

Třetí příkaz by měl nechat aplikaci neaktivní a čtvrtý by měl vypsat jen tunelové připojení, dokud relace běží. Jiný výsledek znamená, že přechod není vůbec vynucen.

Opětovné spuštění během relace je případ, který odhaluje design založený na obalu, protože zástupce spuštěný z plochy nikdy nekonzultuje spouštěcí skript. Pokud na tomto obejití záleží, vynucení patří do řízení aplikací, ne do klienta VPN. Zdokumentujte i konec relace a dejte přednost záměrnému pokračování před znovuotevřením každého procesu zastaveného při vstupu. Výsledek každého přechodu zapište do stejné poznámky, která uchovává unit soubory.