Voer take ná die VPN vanaf die dispatcher uit, nie vanuit if-up nie

’n Skrip wat na die VPN moet loop wanneer dit opkom, het ’n gebeurtenis nodig van die komponent wat die verbinding besit. ’n Lêer wat in ’n ou netwerkwak-gids neergesit word, is nie ’n terugroep vir elke VPN wat NetworkManager, pppd of ’n selfstandige OpenVPN-proses mag skep nie. Elkeen van daardie eienaars rapporteer ’n ander gebeurtenis met ’n ander omgewing, so die eienaar moet geïdentifiseer word voordat die wak gekies word. Anders is die skrip korrek en werk dit eenvoudig nooit nie.

Vir ’n VPN wat deur NetworkManager bestuur word, is die dispatcher die regte plek, en vpn-up is die regte aksie.

Gebruik vpn-up, nie die koppelvlak-gebeurtenis nie

Die dispatcher onderskei up van vpn-up. Die eerste rapporteer ’n geaktiveerde koppelvlak; die tweede rapporteer ’n geaktiveerde VPN-verbinding. Wi-Fi wat opkom beteken net die onderliggende skakel bestaan; die tonnel kan nog onderhandel, of kan glad nooit verifieer nie.

Die skrip ontvang die koppelvlak en die aksie, terwyl verbindingsbesonderhede deur die omgewing inkom, insluitend die profiel-UUID en die VPN-IP-koppelvlak. Lees daardie veranderlikes in plaas daarvan om identiteit uit toestelname af te lei.

Beperk die passing tot een verbinding

Pas die verbinding-UUID, of ’n ander identiteit wat die dispatcher verskaf, eerder as ’n tun-voorvoegsel of ppp0. Koppelvlakname is nie stabiel nie, meer as een tonnel kan gelyktydig bestaan, en twee profiele kan dieselfde vertoonnaam dra. Om ’n tun-voorvoegsel te pas beteken die skrip sal uiteindelik vuur vir ’n verbinding wat niemand bedoel het om aan te raak nie. Dit kan ook twee keer vir een profiel vuur wanneer ’n herverbinding die toestel herbou.

Maak die taak idempotent. ’n Terugroep wat by elke oproep ’n roete byvoeg, vul uiteindelik die tabel met duplikate, en die tweede kopie is die een wat roetering breek.

Weet wat aktivering nie bewys nie

vpn-pre-up loop voordat NetworkManager die VPN ten volle geaktiveer rapporteer, en die bestuurder wag vir daardie skripte. Gebruik ’n blokkerende fase net wanneer die taak werklik daar hoort, want ’n stadige kontrole vertraag die aktivering wat elke ander komponent wag om te sien.

Dat roetes teenwoordig is, bewys nie dat ’n toepassing luister, ’n private naam oplos, of ’n gebruikersessie bestaan nie. Kontroleer dit afsonderlik met ’n begrensde tydsduur, en rapporteer watter laag misluk het in plaas daarvan om die hele ketting weer te probeer.

Respekteer die konteks waarin die skrip loop

Dispatcher-skripte loop as root, buite enige gebruikersessie. Moenie aanvaar dat die aangemelde gebruiker se omgewing, grafiese sessie of ontslote sleutelring beskikbaar is nie. Niemand behoort op ’n ontbrekende lessenaarkonteks te reageer deur elke geloofsbrief vir elke proses leesbaar te maak nie. Hou gebruikersessie-werk in ’n gebruikerdiens of ’n sessiehulp wat die terugroep kan sein sonder om die gebruiker na te boots.

Eienaarskap en regte op die skrip maak ook saak. ’n Lêer wat deur root uitgevoer word en wat enige gebruiker kan vervang, is ’n voorreg-eskalasiepad, en dit is ’n bevinding onafhanklik van of die VPN-logika korrek is.

Beplan vir die ontkoppeling wat nooit vuur nie

NetworkManager dokumenteer dat vpn-pre-down nie uitgestuur word vir gedwonge ontkoppelings soos ’n onverwagte beëindiging of verlore konnektiwiteit nie. Dus is opruiming wat slegs rondom ’n grasieuse pre-down gebou is, per konstruksie onvolledig. Enige gedeelde toestand wat die skrip verander, het ’n ander eienaar nodig wat dit na ’n ineenstorting kan herstel, en daardie herstelpad moet getoets word eerder as aangeneem.

Toets die wak met ’n normale verbinding, ’n herverbinding, ’n doelbewuste ontkoppeling en ’n uitgetrekte kabel. Teken die UUID, die aksie en die koppelvlak aan wat gevuur het, sonder om geheime te log. Daardie rekord is die enigste betroubare bewys dat die wak vir die verbinding geloop het wat jy bedoel het, en dit is wat die volgende verandering veilig maak.