Programa neturi veikti, kai VPN įjungtas: kas tai užtikrina

Kill switch ir draudimo persidengti taisyklės rodo priešingomis kryptimis, todėl įprasti VPN nustatymai niekada neišreiškia antrosios. Kill switch reaguoja į nukritusį tunelį, o šis reikalavimas reaguoja į pakeltą tunelį ir laiko programą už kadro. Vienas dizaino sprendimas išsprendžia didžiąją dalį: ar programa sustabdoma, ar jai neleidžiama startuoti, ar tik atimama prieiga prie tinklo. Pasirinkite tą sluoksnį prieš imdamiesi ugniasienės taisyklės ar procesus žudančios kilpos, nes stebėjimu vykdoma taisyklė kiekvieno paleidimo metu praleidžia langą.

Mitas: kill switch neleidžia programoms startuoti

Kill switch yra srauto kontrolė, ir jie tai pripažįsta: jie leidžia arba atmeta paketus pagal tunelio būseną. Nė vienas jų neatsisako paleisti programos, ir nė vienas netikrina, kuris vykdomasis failas atidarė lizdą. Darbalaukio nuoroda, suplanuota užduotis ir fono pagalbininkas visi pasiekia tinklą neperėję per nieką, kas žinotų programos pavadinimą. Atstumas tarp šių dviejų mechanizmų yra vieta, kur gyvena didžioji dalis painiavos.

Tvarka, kuri iš tikrųjų nusprendžia, ar programa gali startuoti, yra programų kontrolė. Windows tai reiškia AppLocker arba WDAC, o valdomoje macOS – įrenginio profilio vykdomą leidžiamųjų sąrašą. Abu nepriklauso nuo tunelio, todėl abu reikalavimai sujungiami į vieną bilietą ir tada nė vienas neįvykdomas.

Įvardykite režimą prieš įvardydami įrankį

Parašykite taisyklę kaip būsenų mašiną su trimis būsenomis: įprastas naudojimas, VPN darbo sesija ir išėjimas. Draudžiamas persidengimas priklauso vidurinei būsenai, o ne kliento programinei įrangai.

Kas keičia būseną, turi tris veiksmus iš eilės: baigti programos darbą, paprašyti įprasto išjungimo ir patvirtinti, kad egzempliorius dingo, prieš tuneliui pakylant. Tvarka svarbi ir kitame gale, nes VPN, kuris prisijungia pirmas ir sustabdo programą antras, jau leido persidengimą. Jei reikalavimas apima ryšio užmezgimą, laukti prisijungimo indikatoriaus yra per vėlu.

Ką dvipusis konfliktas iš tikrųjų daro

Dviem paslaugoms, kurias tikrai valdo systemd, Conflicts= yra simetriškas: vienos paleidimas sustabdo kitą. Unit nuoroda dokumentuoja šį elgesį ir atskirai reikalauja aiškios tvarkos, kai viena turi baigti sustojimą prieš kitai pradedant. Be tų tvarkos įrašų sustojimas ir paleidimas lenktyniauja, o rezultatas priklauso nuo laiko.

Tai nėra draudžiamųjų sąrašas. Prijunkite priklausomybę atvirkščiai, ir programos paleidimas vietoj to sustabdys VPN, o tai yra gedimas, kuriuo verta įtarti, kai tunelis pats atsijungia numatomu momentu. Darbalaukio programa nėra systemd unit, o NetworkManager ryšys taip pat ne unit, todėl šis šablonas veikia tik paslaugoms, kurias patys apgaubiate.

Tikrinkite perėjimus, ne tik pirmą paleidimą

Keturi perėjimai nusprendžia, ar reikalavimas laikosi: įėjimas į sesiją su veikiančia programa, jos paleidimas iš naujo sesijos viduryje, nepavykęs VPN paleidimas ir sąmoningas atsijungimas. Išbandykite kiekvieną ir rezultatą laikykite šalia unit failų. Žemiau pateiktos komandos nuskaito dabartinį ryšį ir tada praktikuoja svarbiausią perėjimą.

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

Trečioji komanda turėtų palikti programą neaktyvią, o ketvirtoji turėtų išvardyti tik tunelio ryšį, kol sesija vyksta. Kitoks rezultatas reiškia, kad perėjimas visai nevykdomas.

Paleidimas iš naujo sesijos metu yra atvejis, atskleidžiantis apvalkalu pagrįstą dizainą, nes nuoroda, paleista iš darbalaukio, niekada nekonsultuoja paleidimo scenarijaus. Jei šis apėjimas svarbus, vykdymas priklauso programų kontrolei, o ne VPN klientui. Dokumentuokite ir sesijos pabaigą, ir teikite pirmenybę sąmoningam tęsimui, o ne kiekvieno įėjimo metu sustabdyto proceso atidarymui iš naujo. Užrašykite kiekvieno perėjimo rezultatą tame pačiame įraše, kuriame saugomi unit failai.