Paleiskite užduotis po VPN iš dispečerio, o ne iš if-up

Scenarijui, kuris turi būti paleistas po VPN įjungimo, reikia įvykio iš komponento, kuris valdo ryšį. Failas, įdėtas į seną tinklo kabliukų katalogą, nėra atgalinis iškvietimas kiekvienam VPN, kurį gali sukurti NetworkManager, pppd ar atskiras OpenVPN procesas. Kiekvienas iš tų savininkų praneša apie skirtingą įvykį su skirtinga aplinka, todėl savininką reikia nustatyti prieš pasirenkant kabliuką. Priešingu atveju scenarijus yra teisingas ir tiesiog niekada nepasileidžia.

VPN, kurį valdo NetworkManager, tinkama vieta yra dispečeris, o vpn-up yra tinkamas veiksmas.

Naudokite vpn-up, o ne sąsajos įvykį

Dispečeris atskiria up nuo vpn-up. Pirmasis praneša apie suaktyvintą sąsają; antrasis praneša apie suaktyvintą VPN ryšį. Wi-Fi pakilimas reiškia tik tai, kad egzistuoja pagrindinė jungtis; tunelis gali dar derėtis arba niekada neautentifikuoti.

Scenarijus gauna sąsają ir veiksmą, o ryšio detalės ateina per aplinką, įskaitant profilio UUID ir VPN IP sąsają. Skaitykite tuos kintamuosius, o ne spręskite tapatybę iš įrenginių pavadinimų.

Apribokite atitikimą vienam ryšiui

Sutapdinkite pagal ryšio UUID arba kitą tapatybę, kurią pateikia dispečeris, o ne pagal tun priešdėlį ar ppp0. Sąsajų pavadinimai nėra stabilūs, vienu metu gali egzistuoti daugiau nei vienas tunelis, ir du profiliai gali turėti tą patį rodomą pavadinimą. Atitikimas pagal tun priešdėlį reiškia, kad scenarijus galiausiai pasileis ryšiui, kurio niekas neketino liesti. Jis taip pat gali pasileisti du kartus vienam profiliui, kai pakartotinis prisijungimas iš naujo sukuria įrenginį.

Padarykite užduotį idempotentišką. Atgalinis iškvietimas, kuris kiekvieno kvietimo metu prideda maršrutą, galiausiai užpildo lentelę dublikatais, ir būtent antroji kopija sugadina maršrutizavimą.

Žinokite, ko aktyvavimas neįrodo

vpn-pre-up vykdomas prieš NetworkManager pranešant apie visišką VPN aktyvavimą, ir valdytojas laukia tų scenarijų. Blokuojančią stadiją naudokite tik tada, kai užduotis tikrai ten priklauso, nes lėtas patikrinimas atitolina aktyvavimą, kurio laukia visi kiti komponentai.

Maršrutų buvimas neįrodo, kad programa klausosi, kad privatus vardas išsprendžiamas arba kad egzistuoja vartotojo sesija. Tikrinkite tai atskirai su ribotu laiku ir praneškite, kuris sluoksnis nepavyko, o ne kartokite visą grandinę.

Gerbkite kontekstą, kuriame vykdomas scenarijus

Dispečerio scenarijai vykdomi kaip root, už bet kokios vartotojo sesijos. Nepamanykite, kad prisijungusio vartotojo aplinka, grafinė sesija ar atrakintas raktų pakabukas yra prieinami. Niekas neturėtų reaguoti į trūkstamą darbalaukio kontekstą padarydamas kiekvieną prisijungimo duomenį skaitomą kiekvienam procesui. Laikykite vartotojo sesijos darbą vartotojo tarnyboje arba sesijos padėjėjuje, kuriam atgalinis iškvietimas gali duoti signalą neapsimetinėdamas vartotoju.

Scenarijaus nuosavybė ir teisės taip pat svarbios. Failas, vykdomas kaip root ir kurį bet kuris vartotojas gali pakeisti, yra privilegijų didinimo kelias, ir tai yra išvada, nepriklausoma nuo to, ar VPN logika teisinga.

Planuokite atsijungimą, kuris niekada neįvyks

NetworkManager dokumentuoja, kad vpn-pre-down neišduodamas priverstinio atsijungimo atvejais, pavyzdžiui, netikėtai nutraukus ar praradus ryšį. Todėl valymas, pastatytas tik aplink švelnų pre-down, iš prigimties yra nepilnas. Bet kokia bendra būsena, kurią keičia scenarijus, turi kitą savininką, galintį ją atkurti po gedimo, ir tas atkūrimo kelias turi būti tikrinamas, o ne priimamas kaip savaime suprantamas.

Išbandykite kabliuką įprastu prisijungimu, pakartotiniu prisijungimu, tyčiniu atsijungimu ir ištrauktu kabeliu. Užrašykite UUID, veiksmą ir sąsają, kuri pasileido, neregistruodami paslapčių. Tas įrašas yra vienintelis patikimas įrodymas, kad kabliukas veikė jūsų numatytam ryšiui, ir jis daro kitą pakeitimą saugiu.