Kjør oppgaver etter VPN fra dispatcheren, ikke fra if-up

Et skript som må kjøre etter at VPN-en kommer opp, trenger en hendelse fra komponenten som eier tilkoblingen. En fil som legges i en gammel mappe for nettverkskroker, er ikke en tilbakeringing for hver VPN som NetworkManager, pppd eller en selvstendig OpenVPN-prosess kan opprette. Hver av disse eierne rapporterer en annen hendelse med et annet miljø, så eieren må identifiseres før kroken velges. Ellers er skriptet riktig og kjører rett og slett aldri.

For en VPN som administreres av NetworkManager, er dispatcheren riktig sted, og vpn-up er riktig handling.

Bruk vpn-up, ikke grensesnitthendelsen

Dispatcheren skiller up fra vpn-up. Den første rapporterer et aktivert grensesnitt; den andre rapporterer en aktivert VPN-tilkobling. At Wi-Fi kommer opp betyr bare at den underliggende lenken finnes; tunnelen forhandler kanskje fortsatt, eller blir kanskje aldri autentisert.

Skriptet mottar grensesnittet og handlingen, mens tilkoblingsdetaljer kommer gjennom miljøet, inkludert profilens UUID og VPN-ens IP-grensesnitt. Les disse variablene i stedet for å utlede identitet fra enhetsnavn.

Begrens matchingen til én tilkobling

Match på tilkoblingens UUID, eller en annen identitet dispatcheren leverer, i stedet for et tun-prefiks eller ppp0. Grensesnittnavn er ikke stabile, det kan finnes mer enn én tunnel samtidig, og to profiler kan ha samme visningsnavn. Å matche et tun-prefiks betyr at skriptet til slutt utløses for en tilkobling ingen mente å røre. Det kan også utløses to ganger for én profil når en gjenoppkobling bygger enheten på nytt.

Gjør oppgaven idempotent. En tilbakeringing som legger til en rute ved hvert kall, fyller til slutt tabellen med duplikater, og det er den andre kopien som ødelegger rutingen.

Vit hva aktivering ikke beviser

vpn-pre-up kjører før NetworkManager rapporterer at VPN-en er fullt aktivert, og behandleren venter på disse skriptene. Bruk et blokkerende trinn bare når oppgaven virkelig hører hjemme der, fordi en treg sjekk forsinker aktiveringen som alle andre komponenter venter på å se.

At ruter finnes beviser ikke at en applikasjon lytter, at et privat navn løses opp, eller at en brukerøkt finnes. Sjekk dette separat med en begrenset tidsavbrudd, og rapporter hvilket lag som feilet i stedet for å prøve hele kjeden på nytt.

Respekter konteksten skriptet kjører i

Dispatcherens skript kjører som root, utenfor enhver brukerøkt. Ikke anta at miljøet til den innloggede brukeren, den grafiske økten eller en opplåst nøkkelring er tilgjengelig. Ingen bør svare på en manglende skrivebordskontekst ved å gjøre hver legitimasjon lesbar for hver prosess. Hold arbeid i brukerøkten i en brukertjeneste eller en økthjelper som tilbakeringingen kan signalisere uten å etterligne brukeren.

Eierskap og rettigheter på skriptet betyr også noe. En fil som kjøres som root og som enhver bruker kan erstatte, er en vei til privilegieheving, og det er et funn uavhengig av om VPN-logikken er riktig.

Planlegg for frakoblingen som aldri utløses

NetworkManager dokumenterer at vpn-pre-down ikke sendes ut ved tvungne frakoblinger som en uventet avslutning eller tapt tilkobling. Derfor er opprydding som bare bygger på en rolig pre-down, ufullstendig av natur. Enhver delt tilstand skriptet endrer, trenger en annen eier som kan gjenopprette den etter et krasj, og den gjenopprettingsveien må testes i stedet for antas.

Prøv kroken med en normal tilkobling, en gjenoppkobling, en bevisst frakobling og en trukket kabel. Registrer UUID-en, handlingen og grensesnittet som utløste, uten å logge hemmeligheter. Den registreringen er det eneste pålitelige beviset på at kroken kjørte for tilkoblingen du mente, og det er den som gjør den neste endringen trygg.