Запускайте завдання після VPN із диспетчера, а не з if-up

Скрипту, який має виконуватися після підняття VPN, потрібна подія від компонента, що володіє з’єднанням. Файл, покладений у старий каталог мережевих хуків, не є зворотним викликом для кожного VPN, який можуть створити NetworkManager, pppd або окремий процес OpenVPN. Кожен із цих власників повідомляє про іншу подію з іншим середовищем, тому власника треба визначити до вибору хука. Інакше скрипт коректний і просто ніколи не запускається.

Для VPN, яким керує NetworkManager, диспетчер — правильне місце, а vpn-up — правильна дія.

Використовуйте vpn-up, а не подію інтерфейсу

Диспетчер розрізняє up і vpn-up. Перший повідомляє про активований інтерфейс; другий повідомляє про активоване VPN-з’єднання. Підняття Wi-Fi означає лише, що базове з’єднання існує; тунель може ще домовлятися або так і не автентифікуватися.

Скрипт отримує інтерфейс і дію, а відомості про з’єднання надходять через середовище, зокрема UUID профілю та IP-інтерфейс VPN. Читайте ці змінні, а не виводьте ідентичність із назв пристроїв.

Обмежте збіг одним з’єднанням

Зіставляйте за UUID з’єднання або за іншою ідентичністю, яку надає диспетчер, а не за префіксом tun чи ppp0. Назви інтерфейсів нестабільні, одночасно може існувати більше одного тунелю, і два профілі можуть мати однакову відображувану назву. Зіставлення за префіксом tun означає, що скрипт зрештою спрацює для з’єднання, якого ніхто не збирався чіпати. Він також може спрацювати двічі для одного профілю, коли перепідключення перебудовує пристрій.

Зробіть завдання ідемпотентним. Зворотний виклик, що додає маршрут під час кожного виклику, зрештою заповнює таблицю дублікатами, і саме друга копія ламає маршрутизацію.

Знайте, чого не доводить активація

vpn-pre-up виконується до того, як NetworkManager повідомить про повну активацію VPN, і менеджер чекає на ці скрипти. Використовуйте блокуючу стадію лише тоді, коли завдання справді належить туди, бо повільна перевірка затримує активацію, яку чекають усі інші компоненти.

Наявність маршрутів не доводить, що застосунок слухає, що приватна назва розв’язується або що існує сеанс користувача. Перевіряйте це окремо з обмеженим часом очікування і повідомляйте, який рівень відмовив, замість повторювати весь ланцюг.

Поважайте контекст, у якому працює скрипт

Скрипти диспетчера працюють від root, поза будь-яким сеансом користувача. Не припускайте, що доступні середовище користувача, який увійшов, його графічний сеанс або розблокований брелок із ключами. Ніхто не повинен відповідати на відсутність контексту робочого столу тим, що зробить кожні облікові дані читабельними для кожного процесу. Тримайте роботу сеансу користувача в службі користувача або помічнику сеансу, якому зворотний виклик може подати сигнал, не видаючи себе за користувача.

Володіння та права на скрипт теж важливі. Файл, що виконується від root і який може замінити будь-який користувач, — це шлях до підвищення привілеїв, і це висновок, незалежний від того, чи правильна логіка VPN.

Плануйте відключення, яке ніколи не спрацює

NetworkManager документує, що vpn-pre-down не видається для примусових відключень, як-от неочікуване завершення або втрата зв’язку. Тому очищення, побудоване лише навколо м’якого pre-down, є неповним за побудовою. Будь-який спільний стан, який змінює скрипт, потребує іншого власника, здатного відновити його після збою, і цей шлях відновлення треба перевіряти, а не припускати.

Перевірте хук звичайним підключенням, перепідключенням, навмисним відключенням і витягнутим кабелем. Записуйте UUID, дію та інтерфейс, що спрацював, не журналюючи секретів. Цей запис — єдиний надійний доказ того, що хук працював для потрібного вам з’єднання, і саме він робить наступну зміну безпечною.