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. Задокументируйте и конец сессии и предпочитайте намеренное продолжение повторному открытию каждого процесса, остановленного при входе. Запишите результат каждого перехода в ту же заметку, где хранятся файлы юнитов.

Похожие статьи