Стартувајте задачи по VPN од диспечерот, а не од if-up

Скриптата што мора да се изврши откако VPN ќе се подигне бара настан од компонентата што ја поседува врската. Датотека ставена во стара директорија за мрежни hook-ови не е повратен повик за секој VPN што NetworkManager, pppd или самостоен OpenVPN процес може да го создаде. Секој од тие сопственици пријавува различен настан со различно опкружување, затоа сопственикот мора да се идентификува пред да се избере hook-от. Инаку скриптата е точна и едноставно никогаш не се извршува.

За 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 е нецелосно по конструкција. Секоја споделена состојба што скриптата ја менува бара друг сопственик што може да ја врати по пад, и тој пат на обновување мора да се тестира, а не да се претпоставува.

Испробајте го hook-от со нормално поврзување, повторно поврзување, намерно исклучување и извлечен кабел. Запишете ги UUID, дејството и интерфејсот што се активираше, без да регистрирате тајни. Тој запис е единствениот сигурен доказ дека hook-от работел за врската што ја наменивте, и токму тој ја прави следната промена безбедна.