Spouštějte úlohy po VPN z dispečeru, ne z if-up
Starý háček rozhraní VPN připojení neuvidí. Párujte vpn-up podle UUID profilu, udržte úlohu opakovatelnou a počítejte s odpojením, které nikdy nepřijde.
Skript, který se má spustit po navázání VPN, potřebuje událost od komponenty, která spojení vlastní. Soubor vložený do starého adresáře síťových háčků není zpětné volání pro každou VPN, kterou může vytvořit NetworkManager, pppd nebo samostatný proces OpenVPN. Každý z těchto vlastníků hlásí jinou událost s jiným prostředím, takže vlastníka je třeba určit dřív, než se háček vybere. Jinak je skript správný a prostě se nikdy nespustí.
U VPN spravované NetworkManagerem je dispečer správné místo a vpn-up je správná akce.
Používejte vpn-up, ne událost rozhraní
Dispečer rozlišuje up od vpn-up. První hlásí aktivované rozhraní; druhý hlásí aktivované VPN připojení. Nahození Wi-Fi znamená jen to, že podkladové spojení existuje; tunel může stále vyjednávat, nebo se nemusí nikdy autentizovat.
Skript dostává rozhraní a akci, zatímco podrobnosti spojení přicházejí prostředím, včetně UUID profilu a IP rozhraní VPN. Čtěte tyto proměnné místo toho, abyste identitu odvozovali z názvů zařízení.
Omezujte shodu na jedno spojení
Párujte podle UUID spojení nebo jiné identity, kterou dispečer poskytuje, ne podle prefixu tun nebo ppp0. Názvy rozhraní nejsou stabilní, současně může existovat víc než jeden tunel a dva profily mohou mít stejný zobrazovaný název. Párování podle prefixu tun znamená, že se skript dřív nebo později spustí pro spojení, kterého se nikdo nechtěl dotknout. Může se také spustit dvakrát pro jeden profil, když opětovné připojení znovu postaví zařízení.
Udělejte úlohu idempotentní. Zpětné volání, které při každém vyvolání přidá trasu, nakonec zaplní tabulku duplicitami, a právě druhá kopie rozbíjí směrování.
Vězte, co aktivace neprokazuje
vpn-pre-up běží dřív, než NetworkManager ohlásí plně aktivovanou VPN, a správce na tyto skripty čeká. Blokující fázi používejte jen tehdy, když úloha opravdu patří tam, protože pomalá kontrola zdržuje aktivaci, na kterou čekají všechny ostatní komponenty.
Přítomnost tras neprokazuje, že aplikace naslouchá, že se soukromé jméno překládá nebo že existuje uživatelská relace. Ověřujte to zvlášť s omezeným časovým limitem a hlaste, která vrstva selhala, místo abyste opakovali celý řetěz.
Respektujte kontext, ve kterém skript běží
Skripty dispečeru běží jako root, mimo jakoukoli uživatelskou relaci. Nepředpokládejte, že je k dispozici prostředí přihlášeného uživatele, grafická relace nebo odemčená klíčenka. Nikdo by na chybějící kontext plochy neměl reagovat tím, že každý údaj o přihlášení zpřístupní ke čtení každému procesu. Práci uživatelské relace držte v uživatelské službě nebo v pomocníkovi relace, kterému zpětné volání může signalizovat, aniž by se vydávalo za uživatele.
Vlastnictví a oprávnění skriptu také záleží. Soubor spouštěný jako root, který může nahradit kterýkoli uživatel, je cesta ke zvýšení oprávnění a je to zjištění nezávislé na tom, zda je logika VPN správná.
Počítejte s odpojením, které nikdy nepřijde
NetworkManager dokumentuje, že vpn-pre-down se nevysílá při vynucených odpojeních, jako je neočekávané ukončení nebo ztráta konektivity. Úklid postavený jen kolem klidného pre-down je proto konstrukčně neúplný. Jakýkoli sdílený stav, který skript mění, potřebuje jiného vlastníka, který ho po pádu obnoví, a tuto cestu obnovy je třeba otestovat, ne předpokládat.
Vyzkoušejte háček s normálním připojením, opětovným připojením, záměrným odpojením a vytaženým kabelem. Zaznamenejte UUID, akci a rozhraní, které se spustilo, bez protokolování tajemství. Tento záznam je jediný spolehlivý důkaz, že háček běžel pro vámi zamýšlené spojení, a právě on dělá další změnu bezpečnou.