Праграма не павінна працаваць, калі VPN уключаны: што гэта забяспечвае

Kill switch і правілы забароны перакрыцця паказваюць у процілеглыя бакі, што тлумачыць, чаму звычайныя налады VPN ніколі не выражаюць другое. Kill switch рэагуе на тунель, які ўпаў, а гэтае патрабаванне рэагуе на тунель, які ўзняты, і трымае праграму па-за кадрам. Адно праектнае рашэнне вырашае большасць: ці праграму спыняюць, ці блокуюць яе запуск, ці проста пазбаўляюць доступу да сеткі. Выберыце гэты ўзровень, перш чым брацца за правіла міжсеткавага экрана або цыкл забойцы працэсаў, бо правіла, якое выконваецца праз назіранне, сцякае акном пры кожным запуску.

Міф: kill switch не дае праграмам запусціцца

Kill switch — гэта кіраванне трафікам, і яны шчырыя ў гэтым: яны дазваляюць або адхіляюць пакеты ў залежнасці ад стану тунеля. Ніводзін з іх не адмаўляе ў запуску праграмы, і ніводзін не правярае, які выканальны файл адкрыў сокет. Ярлык на працоўным стале, запланаваная задача і фонавы памочнік — усе яны дасягаюць сеткі, не праходзячы праз нешта, што ведае імя праграмы. Адлегласць паміж гэтымі двума механізмамі — месца, дзе жыве большасць блытаніны.

Канфігурацыя, якая сапраўды вырашае, ці можа праграма запусціцца, — гэта кіраванне праграмамі. У Windows гэта азначае AppLocker або WDAC, а ў кіраванай macOS — белы спіс, які выконваецца профілем прылады. Абодва не залежаць ад тунеля, таму два патрабаванні аб’ядноўваюць у адзін тыкет і потым не задавальняюць ні адно з іх.

Назвіце рэжым перад тым, як назваць інструмент

Запішыце правіла як канечны аўтамат з трыма станамі: звычайнае выкарыстанне, рабочая сесія VPN і выхад. Забароненае перакрыццё належыць сярэдняму стану, а не кліенцкай праграме.

Той, хто змяняе стан, валодае трыма дзеяннямі па парадку: завяршыць працу праграмы, запытаць яе звычайнае выключэнне і пацвердзіць, што асобнік знік, перш чым тунель узнімецца. Парадак важны і на другім канцы, бо VPN, які спачатку падключаецца, а потым спыняе праграму, ужо дапусціў перакрыццё. Калі патрабаванне ахоплівае ўстанаўленне злучэння, чаканне індыкатара падключэння — запозна.

Што насамрэч робіць двухбаковы канфлікт

Для двух службаў, якія сапраўды кіруюцца systemd, Conflicts= сіметрычны: запуск адной спыняе другую. Даведнік па юнітах дакументуе гэтыя паводзіны і асобна патрабуе яўнага парадку, калі адна павінна скончыць спыненне да запуску другой. Без такіх запісаў парадку спыненне і запуск спаборнічаюць, і вынік залежыць ад часу.

Гэта не чорны спіс. Падключыце залежнасць у адваротным кірунку, і запуск праграмы спыніць VPN, што і з’яўляецца збоем, які варта падазраваць, калі тунель сам адключаецца ў прадказальны момант. Праграма для працоўнага стала не з’яўляецца юнітам systemd, і злучэнне NetworkManager таксама не юніт, таму гэты шаблон працуе толькі для службаў, якія вы абгортваеце самі.

Правярайце пераходы, а не толькі першы запуск

Чатыры пераходы вырашаюць, ці выконваецца патрабаванне: уваход у сесію з працуючай праграмай, яе паўторны запуск пасярэдзіне сесіі, няўдалы запуск VPN і наўмыснае адключэнне. Праверце кожны і захавайце вынік побач з файламі юнітаў. Каманды ніжэй чытаюць бягучую залежнасць, а затым практыкуюць пераход, які найбольш важны.

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

Трэцяя каманда павінна пакінуць праграму неактыўнай, а чацвёртая — паказаць толькі злучэнне тунеля, пакуль сесія ідзе. Іншы вынік азначае, што пераход зусім не выконваецца.

Перазапуск падчас сесіі — гэта выпадак, які выкрывае праект на аснове абгорткі, бо ярлык, запушчаны з працоўнага стала, ніколі не звяртаецца да скрыпта запуску. Калі гэты абыход важны, выкананне належыць кіраванню праграмамі, а не кліенту VPN. Задакументуйце і канец сесіі, і аддавайце перавагу наўмыснаму працягу замест паўторнага адкрыцця кожнага працэса, спыненага на ўваходзе. Запішыце вынік кожнага пераходу ў той жа нататцы, дзе захоўваюцца файлы юнітаў.