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