Приложението не трябва да работи, докато VPN е включен: какво го налага
Спирането на приложение, докато тунелът е вдигнат, не е kill switch. Решете кой притежава смяната на режима, какво блокира повторното стартиране и какво systemd може и не може да направи.
Kill switch и правилата за забрана на припокриване сочат в противоположни посоки, което обяснява защо обикновените VPN настройки никога не изразяват второто. Kill switch реагира на тунел, който е паднал, докато това изискване реагира на тунел, който е вдигнат, и държи приложението извън картината. Едно дизайнерско решение решава по-голямата част: дали приложението се спира, блокира се стартирането му или просто се лишава от мрежов достъп. Изберете този слой, преди да посегнете към правило на защитна стена или цикъл за убиване на процеси, защото правило, наложено чрез наблюдение, пропуска прозорец при всяко стартиране.
Митът: kill switch не позволява на програмите да стартират
Kill switch са контрол на трафика и са честни за това: разрешават или отказват пакети според състоянието на тунела. Никое от тях не отказва стартиране на програма и никое не проверява кой изпълним файл е отворил сокет. Пряк път на работния плот, планирана задача и фонова помощна програма стигат до мрежата, без да минават през нещо, което знае името на приложението. Разстоянието между тези два механизма е мястото, където живее повечето объркване.
Подредбата, която наистина решава дали програма може да стартира, е контрол на приложенията. В Windows това означава AppLocker или WDAC, а в управляван macOS — списък за разрешаване, наложен от профила на устройството. И двете са независими от тунела, затова двете изисквания се сливат в един тикет и после нито едно не се изпълнява.
Наименувайте режима, преди да наименувате инструмента
Напишете правилото като машина на състоянията с три състояния: обичайна употреба, работна сесия с VPN и излизане. Забраненото припокриване принадлежи на средното състояние, не на клиентския софтуер.
Който сменя състоянието, притежава три действия по ред: да завърши работата на приложението, да поиска нормалното му изключване и да потвърди, че екземплярът е изчезнал, преди тунелът да се вдигне. Редът е важен и в другия край, защото VPN, който първо се свързва и после спира програмата, вече е допуснал припокриването. Ако изискването обхваща установяването на връзката, чакането на индикатор за свързаност е твърде късно.
Какво всъщност прави двупосочният конфликт
За две услуги, наистина управлявани от systemd, Conflicts= е симетрично: стартирането на едната спира другата. Справочникът за unit документира това поведение и отделно изисква явен ред, когато едната трябва да завърши спирането преди старта на другата. Без тези записи за ред спирането и стартирането се надпреварват и резултатът зависи от времето.
Това не е списък за забрана. Свържете зависимостта наобратно и стартирането на приложението вместо това спира VPN — това е отказът, който да подозирате, когато тунелът се изключи сам в предвидим момент. Приложение за работен плот не е systemd unit и връзка на NetworkManager също не е unit, така че този модел работи само за услуги, които сами обвивате.
Проверявайте преходите, не само първия старт
Четири прехода решават дали изискването издържа: влизане в сесията с работещо приложение, повторното му стартиране по средата на сесията, неуспешен старт на VPN и умишлено прекъсване. Тествайте всеки и запазете резултата до unit файловете. Командите по-долу четат текущата връзка и после упражняват прехода, който е най-важен.
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 клиента. Документирайте и края на сесията и предпочитайте умишлено възобновяване пред повторното отваряне на всеки процес, спрян при влизането. Запишете резултата от всеки преход в същата бележка, в която се пазят unit файловете.