Voer taken na de VPN uit vanuit de dispatcher, niet vanuit if-up

Een script dat na het opkomen van de VPN moet draaien, heeft een gebeurtenis nodig van de component die de verbinding bezit. Een bestand in een oude map met netwerkhooks is geen callback voor elke VPN die NetworkManager, pppd of een zelfstandig OpenVPN-proces kan aanmaken. Elk van die eigenaren meldt een andere gebeurtenis met een andere omgeving, dus de eigenaar moet worden geïdentificeerd voordat de hook wordt gekozen. Anders is het script correct en draait het simpelweg nooit.

Voor een VPN die door NetworkManager wordt beheerd, is de dispatcher de juiste plek, en vpn-up is de juiste actie.

Gebruik vpn-up, niet de interface-gebeurtenis

De dispatcher onderscheidt up van vpn-up. De eerste meldt een geactiveerde interface; de tweede meldt een geactiveerde VPN-verbinding. Dat Wi-Fi opkomt betekent alleen dat de onderliggende verbinding bestaat; de tunnel onderhandelt misschien nog, of authenticeert nooit.

Het script ontvangt de interface en de actie, terwijl verbindingsdetails via de omgeving binnenkomen, waaronder de UUID van het profiel en de IP-interface van de VPN. Lees die variabelen in plaats van identiteit af te leiden uit apparaatnamen.

Beperk de overeenkomst tot één verbinding

Koppel op de UUID van de verbinding, of op een andere identiteit die de dispatcher levert, in plaats van een tun-voorvoegsel of ppp0. Interfacenamen zijn niet stabiel, er kan tegelijk meer dan één tunnel bestaan, en twee profielen kunnen dezelfde weergavenaam dragen. Een tun-voorvoegsel koppelen betekent dat het script uiteindelijk afgaat voor een verbinding die niemand wilde aanraken. Het kan ook twee keer afgaan voor één profiel wanneer een herverbinding het apparaat opnieuw opbouwt.

Maak de taak idempotent. Een callback die bij elke aanroep een route toevoegt, vult de tabel uiteindelijk met duplicaten, en de tweede kopie is degene die de routering breekt.

Weet wat activering niet bewijst

vpn-pre-up draait voordat NetworkManager meldt dat de VPN volledig is geactiveerd, en de beheerder wacht op die scripts. Gebruik een blokkerende fase alleen wanneer de taak daar echt thuishoort, want een trage controle vertraagt de activering waar elke andere component op wacht.

Dat routes bestaan bewijst niet dat een toepassing luistert, dat een privénaam wordt opgelost of dat er een gebruikerssessie is. Controleer dat apart met een begrensde time-out, en meld welke laag faalde in plaats van de hele keten opnieuw te proberen.

Respecteer de context waarin het script draait

Dispatcherschripts draaien als root, buiten elke gebruikerssessie. Ga er niet van uit dat de omgeving van de aangemelde gebruiker, de grafische sessie of een ontgrendelde sleutelring beschikbaar zijn. Niemand zou op een ontbrekende desktopcontext moeten reageren door elk inloggegeven leesbaar te maken voor elk proces. Houd werk van de gebruikerssessie in een gebruikersdienst of een sessiehulp die de callback kan signaleren zonder de gebruiker na te bootsen.

Eigendom en rechten op het script tellen ook. Een bestand dat als root wordt uitgevoerd en dat elke gebruiker kan vervangen, is een pad voor rechtenverhoging, en dat is een bevinding los van de vraag of de VPN-logica correct is.

Plan voor de verbreking die nooit afgaat

NetworkManager documenteert dat vpn-pre-down niet wordt uitgezonden bij geforceerde verbrekingen zoals een onverwachte beëindiging of verloren connectiviteit. Opruiming die alleen rond een soepele pre-down is gebouwd, is daarom per constructie onvolledig. Elke gedeelde toestand die het script wijzigt, heeft een andere eigenaar nodig die die na een crash kan herstellen, en dat herstelpad moet worden getest in plaats van aangenomen.

Test de hook met een normale verbinding, een herverbinding, een opzettelijke verbreking en een getrokken kabel. Registreer de UUID, de actie en de interface die afging, zonder geheimen te loggen. Die registratie is het enige betrouwbare bewijs dat de hook draaide voor de verbinding die je bedoelde, en die maakt de volgende wijziging veilig.