Kør opgaver efter VPN fra dispatcheren, ikke fra if-up

Et script, der skal køre, efter VPN'en kommer op, har brug for en hændelse fra den komponent, der ejer forbindelsen. En fil, der lægges i en gammel mappe til netværkshooks, er ikke et callback for enhver VPN, som NetworkManager, pppd eller en selvstændig OpenVPN-proces kan oprette. Hver af disse ejere rapporterer en anden hændelse med et andet miljø, så ejeren skal identificeres, før hooket vælges. Ellers er scriptet korrekt og kører ganske enkelt aldrig.

For en VPN, der styres af NetworkManager, er dispatcheren det rigtige sted, og vpn-up er den rigtige handling.

Brug vpn-up, ikke interface-hændelsen

Dispatcheren skelner up fra vpn-up. Den første rapporterer et aktiveret interface; den anden rapporterer en aktiveret VPN-forbindelse. At Wi-Fi kommer op betyder kun, at det underliggende link findes; tunnelen forhandler måske stadig, eller bliver måske aldrig godkendt.

Scriptet modtager interfacet og handlingen, mens forbindelsesdetaljer kommer gennem miljøet, herunder profilens UUID og VPN'ens IP-interface. Læs disse variabler i stedet for at udlede identitet af enhedsnavne.

Afgræns matchningen til én forbindelse

Match på forbindelsens UUID eller en anden identitet, som dispatcheren leverer, i stedet for et tun-præfiks eller ppp0. Interface-navne er ikke stabile, der kan findes mere end en tunnel på samme tid, og to profiler kan bære samme viste navn. At matche et tun-præfiks betyder, at scriptet til sidst udløses for en forbindelse, som ingen havde tænkt sig at røre. Det kan også udløses to gange for én profil, når en genopkobling genopbygger enheden.

Gør opgaven idempotent. Et callback, der tilføjer en rute ved hvert kald, fylder til sidst tabellen med dubletter, og den anden kopi er den, der ødelægger routing.

Vid, hvad aktivering ikke beviser

vpn-pre-up kører, før NetworkManager rapporterer VPN'en som fuldt aktiveret, og manageren venter på disse scripts. Brug kun et blokerende trin, når opgaven virkelig hører der, fordi et langsomt tjek forsinker den aktivering, som alle andre komponenter venter på at se.

At ruter findes beviser ikke, at en applikation lytter, at et privat navn opløses, eller at en brugersession findes. Tjek dem separat med en afgrænset timeout, og rapportér hvilket lag der fejlede i stedet for at gentage hele kæden.

Respektér den kontekst, scriptet kører i

Dispatcherens scripts kører som root, uden for enhver brugersession. Antag ikke, at den login-brugers miljø, grafiske session eller oplåste nøglering er tilgængelig. Ingen bør reagere på en manglende skrivebordskontekst ved at gøre hver legitimationsoplysning læsbar for hver proces. Hold arbejde i brugersessionen i en brugertjeneste eller en sessionshjælper, som callbacket kan signalere uden at efterligne brugeren.

Ejerskab og rettigheder på scriptet betyder også noget. En fil, der køres som root, og som enhver bruger kan erstatte, er en vej til privilegieforhøjelse, og det er en konstatering uafhængig af, om VPN-logikken er korrekt.

Planlæg for afbrydelsen, der aldrig udløses

NetworkManager dokumenterer, at vpn-pre-down ikke udsendes ved tvungne afbrydelser som en uventet afslutning eller mistet forbindelse. Derfor er oprydning, der kun bygger på en rolig pre-down, ufuldstændig af natur. Enhver delt tilstand, som scriptet ændrer, har brug for en anden ejer, der kan genskabe den efter et nedbrud, og den gendannelsesvej skal testes i stedet for antages.

Afprøv hooket med en normal forbindelse, en genopkobling, en bevidst afbrydelse og et trukket kabel. Registrér UUID'et, handlingen og det interface, der udløste, uden at logge hemmeligheder. Den registrering er det eneste pålidelige bevis for, at hooket kørte for den forbindelse, du havde tænkt dig, og det er den, der gør den næste ændring sikker.