Køyr oppgåver etter VPN frå dispatcheren, ikkje frå if-up

Eit skript som må køyre etter at VPN-en kjem opp, treng ei hending frå komponenten som eig tilkoplinga. Ei fil som blir lagd i ei gammal mappe for nettverkskrokar, er ikkje ein tilbakekalling for kvar VPN som NetworkManager, pppd eller ein sjølvstendig OpenVPN-prosess kan opprette. Kvar av desse eigarane rapporterer ei anna hending med eit anna miljø, så eigaren må identifiserast før kroken blir vald. Elles er skriptet riktig og køyrer rett og slett aldri.

For ein VPN som blir styrt av NetworkManager, er dispatcheren rett stad, og vpn-up er rett handling.

Bruk vpn-up, ikkje grensesnitthendinga

Dispatcheren skil up frå vpn-up. Den første rapporterer eit aktivert grensesnitt; den andre rapporterer ei aktivert VPN-tilkopling. At Wi-Fi kjem opp tyder berre at den underliggjande lenkja finst; tunnelen forhandlar kanskje framleis, eller blir kanskje aldri autentisert.

Skriptet mottek grensesnittet og handlinga, medan tilkoplingsopplysningar kjem gjennom miljøet, inkludert UUID-en til profilen og IP-grensesnittet til VPN-en. Les desse variablane i staden for å utleie identitet frå einingnamn.

Afgrens matchinga til éi tilkopling

Match på UUID-en til tilkoplinga, eller ein annan identitet dispatcheren leverer, i staden for eit tun-prefiks eller ppp0. Grensesnittnamn er ikkje stabile, det kan finnast meir enn ein tunnel samstundes, og to profilar kan ha same visingsnamn. Å matche eit tun-prefiks tyder at skriptet til slutt blir utløyst for ei tilkopling ingen meinte å røre. Det kan òg bli utløyst to gonger for ein profil når ei attoppkopling byggjer eininga på nytt.

Gjer oppgåva idempotent. Ein tilbakekalling som legg til ei rute ved kvart kall, fyller til slutt tabellen med duplikat, og det er den andre kopien som øydelegg rutinga.

Vit kva aktivering ikkje beviser

vpn-pre-up køyrer før NetworkManager rapporterer at VPN-en er fullt aktivert, og behandlaren ventar på desse skripta. Bruk eit blokkerande trinn berre når oppgåva verkeleg høyrer heime der, fordi ein treg sjekk forseinkar aktiveringa som alle andre komponentar ventar på å sjå.

At ruter finst beviser ikkje at ein applikasjon lyttar, at eit privat namn blir løyst opp, eller at ei brukarøkt finst. Sjekk dette separat med ein avgrensa tidsfrist, og rapporter kva lag som feila i staden for å prøve heile kjeda på nytt.

Respekter konteksten skriptet køyrer i

Skripta til dispatcheren køyrer som root, utanfor kvar brukarøkt. Ikkje gå ut frå at miljøet til den innlogga brukaren, den grafiske økta eller ein opplåst nøkkelring er tilgjengeleg. Ingen bør svare på ein manglande skrivebordskontekst ved å gjere kvar legitimasjon lesbar for kvar prosess. Hald arbeid i brukarøkta i ein brukarteneste eller ein økthjelpar som tilbakekallinga kan signalisere utan å etterlikne brukaren.

Eigarskap og rettar på skriptet tel òg. Ei fil som blir køyrd som root og som kvar brukar kan erstatte, er ein veg til privilegieheving, og det er eit funn uavhengig av om VPN-logikken er riktig.

Planlegg for fråkoplinga som aldri blir utløyst

NetworkManager dokumenterer at vpn-pre-down ikkje blir sendt ut ved tvinga fråkoplingar som ein uventa avslutning eller tapt tilkopling. Derfor er opprydding som berre er bygd rundt ein roleg pre-down, ufullstendig av natur. Kvar delt tilstand skriptet endrar, treng ein annan eigar som kan gjenopprette han etter eit krasj, og den gjenopprettingsvegen må testast i staden for å bli antatt.

Prøv kroken med ei vanleg tilkopling, ei attoppkopling, ei medviten fråkopling og ein dregen kabel. Registrer UUID-en, handlinga og grensesnittet som blei utløyst, utan å logge løyndomar. Den registreringa er det einaste pålitelege beviset på at kroken køyrde for tilkoplinga du meinte, og det er den som gjer den neste endringa trygg.