Aplikácia nesmie bežať, kým je VPN zapnutá: čo to vynucuje

Kill switch a pravidlá zákazu prekrývania ukazujú opačným smerom, čo vysvetľuje, prečo bežné nastavenia VPN nikdy nevyjadrujú to druhé. Kill switch reaguje na tunel, ktorý spadol, zatiaľ čo táto požiadavka reaguje na tunel, ktorý je hore, a drží aplikáciu mimo obrazu. Jedno dizajnové rozhodnutie vyrieši väčšinu: či sa aplikácia zastaví, zablokuje sa jej spustenie, alebo sa jej len odoberie sieťový prístup. Vyberte tú vrstvu skôr, než siahnete po pravidle firewallu alebo slučke zabíjajúcej procesy, pretože pravidlo vynútené pozorovaním prepúšťa okno pri každom spustení.

Mýtus: kill switch bráni programom spustiť sa

Kill switch sú riadenie prevádzky a sú v tom úprimné: povoľujú alebo odmietajú pakety podľa stavu tunela. Žiadny z nich neodmietne spustiť program a žiadny neskúma, ktorý spustiteľný súbor otvoril socket. Zástupca na ploche, naplánovaná úloha a pomocník na pozadí sa všetky dostanú do siete bez toho, aby prešli niečím, čo pozná názov aplikácie. Vzdialenosť medzi týmito dvoma mechanizmami je miesto, kde žije väčšina zmätku.

Usporiadanie, ktoré skutočne rozhoduje, či program smie začať, je riadenie aplikácií. V Windows to znamená AppLocker alebo WDAC, v spravovanom macOS zoznam povolených vynútený profilom zariadenia. Obe sú nezávislé od tunela, a preto sa obe požiadavky zlúčia do jedného tiketu a potom ich nesplní ani jedna.

Pomenujte režim skôr, než pomenujete nástroj

Napíšte pravidlo ako stavový automat s tromi stavmi: bežné použitie, pracovná relácia VPN a odchod. Zakázané prekrývanie patrí strednému stavu, nie klientskemu softvéru.

Kto mení stav, vlastní tri akcie v poradí: dokončiť prácu aplikácie, požiadať o jej normálne vypnutie a potvrdiť, že inštancia zmizla, kým sa tunel zdvihne. Poradie je dôležité aj na druhom konci, pretože VPN, ktorá sa pripojí prvá a program zastaví druhá, už prekrytie povolila. Ak požiadavka zahŕňa nadviazanie spojenia, čakanie na indikátor pripojenia je neskoro.

Čo naozaj robí dvojsmerný konflikt

Pre dve služby skutočne spravované systemd je Conflicts= symetrické: spustenie jednej zastaví druhú. Referencia k unit dokumentuje toto správanie a osobitne vyžaduje explicitné poradie, keď jedna musí dokončiť zastavenie pred štartom druhej. Bez týchto položiek poradia sa zastavenie a štart predbiehajú a výsledok závisí od času.

To nie je zoznam zákazov. Zapojte závislosť opačne a spustenie aplikácie namiesto toho zastaví VPN, čo je porucha, ktorú treba podozrievať, keď sa tunel sám odpojí v predvídateľnom okamihu. Desktopová aplikácia nie je unit systemd a pripojenie NetworkManager tiež nie je unit, takže tento vzor funguje len pre služby, ktoré si sami obalíte.

Testujte prechody, nie len prvý štart

Štyri prechody rozhodujú, či požiadavka platí: vstup do relácie s bežiacou aplikáciou, jej opätovné spustenie uprostred relácie, neúspešný štart VPN a úmyselné odpojenie. Otestujte každý a výsledok uložte vedľa unit súborov. Nižšie uvedené príkazy čítajú súčasný vzťah a potom precvičujú prechod, na ktorom záleží najviac.

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

Tretí príkaz by mal nechať aplikáciu neaktívnu a štvrtý by mal vypísať len tunelové pripojenie, kým relácia beží. Iný výsledok znamená, že prechod nie je vôbec vynútený.

Opätovné spustenie počas relácie je prípad, ktorý odhaľuje dizajn založený na obale, pretože zástupca spustený z plochy nikdy nekonzultuje spúšťací skript. Ak na tomto obídení záleží, vynútenie patrí do riadenia aplikácií, nie do klienta VPN. Zdokumentujte aj koniec relácie a uprednostnite úmyselné pokračovanie pred opätovným otvorením každého procesu zastaveného pri vstupe. Výsledok každého prechodu zapíšte do tej istej poznámky, ktorá uchováva unit súbory.