Ekzekutoni detyrat pas VPN nga dispeçeri, jo nga if-up

Një skript që duhet të ekzekutohet pasi VPN-ja ngrihet ka nevojë për një ngjarje nga komponenti që zotëron lidhjen. Një skedar i vendosur në një drejtori të vjetër grepash rrjeti nuk është kthim thirrjeje për çdo VPN që NetworkManager, pppd ose një proces OpenVPN i pavarur mund të krijojnë. Secili prej këtyre pronarëve raporton një ngjarje tjetër me një mjedis tjetër, prandaj pronari duhet identifikuar përpara se të zgjidhet grepi. Përndryshe skripti është i saktë dhe thjesht nuk ekzekutohet kurrë.

Për një VPN të menaxhuar nga NetworkManager, dispeçeri është vendi i duhur, dhe vpn-up është veprimi i duhur.

Përdorni vpn-up, jo ngjarjen e ndërfaqes

Dispeçeri dallon up nga vpn-up. I pari raporton një ndërfaqe të aktivizuar; i dyti raporton një lidhje VPN të aktivizuar. Ngritja e Wi-Fi-t do të thotë vetëm se lidhja bazë ekziston; tuneli mund të jetë ende duke negociuar, ose mund të mos autentikohet kurrë.

Skripti merr ndërfaqen dhe veprimin, ndërsa detajet e lidhjes vijnë përmes mjedisit, duke përfshirë UUID-në e profilit dhe ndërfaqen IP të VPN-së. Lexoni ato variabla në vend që të nxirrni identitetin nga emrat e pajisjeve.

Kufizoni përputhjen në një lidhje

Përputhni sipas UUID-së së lidhjes, ose një identiteti tjetër që ofron dispeçeri, jo sipas një prefiksi tun ose ppp0. Emrat e ndërfaqeve nuk janë të qëndrueshëm, mund të ekzistojë më shumë se një tunel në të njëjtën kohë, dhe dy profile mund të mbajnë të njëjtin emër shfaqjeje. Përputhja e një prefiksi tun do të thotë që skripti përfundimisht do të aktivizohet për një lidhje që askush nuk synonte ta prekte. Ai gjithashtu mund të aktivizohet dy herë për një profil kur një rilidhje rindërton pajisjen.

Bëjeni detyrën idempotente. Një kthim thirrjeje që shton një rrugë në çdo thirrje përfundimisht e mbush tabelën me dublikata, dhe kopja e dytë është ajo që prish rrugëtimin.

Dijeni çfarë nuk provon aktivizimi

vpn-pre-up ekzekutohet përpara se NetworkManager të raportojë VPN-në plotësisht të aktivizuar, dhe menaxheri pret ato skripte. Përdorni një fazë bllokuese vetëm kur detyra vërtet i përket atij vendi, sepse një kontroll i ngadaltë vonon aktivizimin që presin të gjithë komponentët e tjerë.

Ekzistenca e rrugëve nuk provon që një aplikacion po dëgjon, që një emër privat zgjidhet ose që ekziston një sesion përdoruesi. Kontrollojini ato veçmas me një afat të kufizuar, dhe raportoni cila shtresë dështoi në vend që të riparprovoni të gjithë zinxhirin.

Respektoni kontekstin në të cilin ekzekutohet skripti

Skriptet e dispeçerit ekzekutohen si root, jashtë çdo sesioni përdoruesi. Mos supozoni se janë të disponueshme mjedisi i përdoruesit të identifikuar, sesioni i tij grafik ose një varëse çelësash e zhbllokuar. Askush nuk duhet t'i përgjigjet mungesës së kontekstit të desktopit duke i bërë çdo kredencial të lexueshëm nga çdo proces. Mbajeni punën e sesionit të përdoruesit në një shërbim përdoruesi ose në një ndihmës sesioni të cilit kthimi i thirrjes mund t'i dërgojë sinjal pa u shtirur si përdoruesi.

Pronësia dhe lejet mbi skriptin kanë gjithashtu rëndësi. Një skedar i ekzekutuar si root që çdo përdorues mund ta zëvendësojë është një rrugë për rritje privilegjesh, dhe është një gjetje e pavarur nga fakti nëse logjika e VPN-së është e saktë.

Planifikoni shkëputjen që nuk aktivizohet kurrë

NetworkManager dokumenton se vpn-pre-down nuk emetohet për shkëputje të detyruara, si një përfundim i papritur ose humbje e lidhjes. Prandaj, një pastrim i ndërtuar vetëm rreth një pre-down të qetë është i paplotë nga ndërtimi. Çdo gjendje e përbashkët që skripti ndryshon kërkon një pronar tjetër që mund ta rivendosë pas një dështimi, dhe ai rrugë rikuperimi duhet testuar, jo supozuar.

Provoni grepin me një lidhje normale, një rilidhje, një shkëputje të qëllimshme dhe një kabllo të shkëputur. Regjistroni UUID-në, veprimin dhe ndërfaqen që u aktivizua, pa regjistruar sekrete. Ai regjistrim është prova e vetme e besueshme që grepi u ekzekutua për lidhjen që synonit, dhe është ai që e bën ndryshimin e radhës të sigurt.