Стартирайте задачите след VPN от диспечера, а не от if-up

Скрипт, който трябва да се изпълни след вдигане на VPN, се нуждае от събитие от компонента, който притежава връзката. Файл, поставен в стара директория за мрежови куки, не е обратно извикване за всяка VPN, която NetworkManager, pppd или самостоятелен процес OpenVPN може да създаде. Всеки от тези собственици съобщава различно събитие с различна среда, затова собственикът трябва да бъде установен, преди да се избере куката. Иначе скриптът е коректен и просто никога не се задейства.

За VPN, управлявана от NetworkManager, диспечерът е правилното място, а vpn-up е правилното действие.

Използвайте vpn-up, а не събитието на интерфейса

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

Скриптът получава интерфейса и действието, докато подробностите за връзката идват през средата, включително UUID на профила и VPN IP интерфейса. Четете тези променливи, вместо да извеждате самоличност от имената на устройствата.

Ограничете съвпадението до една връзка

Съпоставяйте по UUID на връзката или друга самоличност, която диспечерът предоставя, а не по префикс tun или ppp0. Имената на интерфейсите не са стабилни, едновременно може да съществува повече от един тунел, а два профила може да носят едно и също показвано име. Съпоставянето по префикс tun означава, че скриптът рано или късно ще се задейства за връзка, която никой не е възнамерявал да пипа. Може да се задейства и два пъти за един профил, когато повторното свързване пресъздаде устройството.

Направете задачата идемпотентна. Обратно извикване, което добавя маршрут при всяко извикване, в крайна сметка пълни таблицата с дубликати и именно второто копие чупи маршрутизацията.

Знайте какво не доказва активирането

vpn-pre-up се изпълнява, преди NetworkManager да отчете VPN като напълно активирана, и мениджърът чака тези скриптове. Използвайте блокиращ етап само когато задачата наистина принадлежи там, защото бавната проверка забавя активирането, което всеки друг компонент чака да види.

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

Уважавайте контекста, в който работи скриптът

Скриптите на диспечера работят като root, извън всяка потребителска сесия. Не предполагайте, че средата на влезлия потребител, графичната сесия или отключеният ключодържател са налични. Никой не бива да отговаря на липсващ контекст на работния плот, като прави всеки идентификатор четим от всеки процес. Дръжте работата по потребителската сесия в потребителска услуга или помощник на сесията, на който обратното извикване може да подаде сигнал, без да се представя за потребителя.

Собствеността и правата върху скрипта също имат значение. Файл, изпълняван като root, който всеки потребител може да замени, е път за повишаване на привилегии и е констатация, независима от това дали логиката на VPN е правилна.

Планирайте прекъсването, което никога не се задейства

NetworkManager документира, че vpn-pre-down не се излъчва при принудителни прекъсвания, като неочаквано прекратяване или загуба на свързаност. Затова почистване, изградено само около плавно pre-down, е непълно по конструкция. Всяко споделено състояние, което скриптът променя, се нуждае от друг собственик, който да го възстанови след срив, и този път за възстановяване трябва да се тества, а не да се предполага.

Изпробвайте куката с нормално свързване, повторно свързване, умишлено прекъсване и изваден кабел. Записвайте UUID, действието и интерфейса, който се е задействал, без да регистрирате тайни. Този запис е единственото надеждно доказателство, че куката е работила за връзката, която сте имали предвид, и именно той прави следващата промяна безопасна.