Post-VPN-Aufgaben über den Dispatcher ausführen, nicht über if-up
Ein alter Schnittstellen-Hook sieht keine VPN-Verbindung. Gleichen Sie vpn-up über die Profil-UUID ab, halten Sie die Aufgabe wiederholbar und planen Sie einen Abbau ein, der nie ausgelöst wird.
Ein Skript, das nach dem Hochfahren des VPN laufen muss, braucht ein Ereignis von der Komponente, die die Verbindung besitzt. Eine Datei in einem alten Hook-Verzeichnis des Netzwerks ist kein Callback für jedes VPN, das NetworkManager, pppd oder ein eigenständiger OpenVPN-Prozess anlegen kann. Jeder dieser Eigentümer meldet ein anderes Ereignis mit einer anderen Umgebung, deshalb muss der Eigentümer bestimmt werden, bevor der Hook gewählt wird. Sonst ist das Skript korrekt und läuft einfach nie.
Für ein von NetworkManager verwaltetes VPN ist der Dispatcher die richtige Stelle, und vpn-up ist die richtige Aktion.
vpn-up nutzen, nicht das Schnittstellen-Ereignis
Der Dispatcher unterscheidet up von vpn-up. Das erste meldet eine aktivierte Schnittstelle; das zweite meldet eine aktivierte VPN-Verbindung. Dass WLAN hochkommt, heißt nur, dass die zugrunde liegende Strecke existiert; der Tunnel verhandelt vielleicht noch oder authentifiziert sich nie.
Das Skript erhält die Schnittstelle und die Aktion, während Verbindungsdetails über die Umgebung kommen, darunter die Profil-UUID und die IP-Schnittstelle des VPN. Lesen Sie diese Variablen, statt die Identität aus Gerätenamen abzuleiten.
Den Abgleich auf eine Verbindung begrenzen
Gleichen Sie über die UUID der Verbindung ab oder über eine andere Identität, die der Dispatcher liefert, statt über ein tun-Präfix oder ppp0. Schnittstellennamen sind nicht stabil, es kann gleichzeitig mehr als einen Tunnel geben, und zwei Profile können denselben Anzeigenamen tragen. Ein tun-Präfix abzugleichen heißt, dass das Skript irgendwann für eine Verbindung auslöst, die niemand anfassen wollte. Es kann auch zweimal für ein Profil auslösen, wenn ein erneutes Verbinden das Gerät neu aufbaut.
Machen Sie die Aufgabe idempotent. Ein Callback, der bei jedem Aufruf eine Route anhängt, füllt die Tabelle irgendwann mit Duplikaten, und die zweite Kopie ist die, die das Routing zerbricht.
Wissen, was die Aktivierung nicht beweist
vpn-pre-up läuft, bevor NetworkManager das VPN als vollständig aktiviert meldet, und der Manager wartet auf diese Skripte. Verwenden Sie eine blockierende Stufe nur, wenn die Aufgabe wirklich dorthin gehört, denn eine langsame Prüfung verzögert die Aktivierung, auf die alle anderen Komponenten warten.
Vorhandene Routen beweisen nicht, dass eine Anwendung lauscht, ein privater Name aufgelöst wird oder eine Benutzersitzung existiert. Prüfen Sie das getrennt mit einem begrenzten Zeitlimit und melden Sie, welche Schicht versagt hat, statt die ganze Kette zu wiederholen.
Den Kontext achten, in dem das Skript läuft
Dispatcher-Skripte laufen als root, außerhalb jeder Benutzersitzung. Gehen Sie nicht davon aus, dass die Umgebung des angemeldeten Benutzers, seine grafische Sitzung oder ein entsperrter Schlüsselbund verfügbar sind. Niemand sollte auf einen fehlenden Desktop-Kontext reagieren, indem er jede Anmeldeinformation für jeden Prozess lesbar macht. Halten Sie Arbeit der Benutzersitzung in einem Benutzerdienst oder einem Sitzungshelfer, dem der Callback signalisieren kann, ohne den Benutzer nachzuahmen.
Eigentum und Rechte am Skript zählen ebenfalls. Eine als root ausgeführte Datei, die jeder Benutzer ersetzen kann, ist ein Weg zur Rechteausweitung, und das ist ein Befund unabhängig davon, ob die VPN-Logik korrekt ist.
Den Abbau einplanen, der nie ausgelöst wird
NetworkManager dokumentiert, dass vpn-pre-down bei erzwungenen Trennungen wie einer unerwarteten Beendigung oder verlorener Konnektivität nicht ausgelöst wird. Aufräumen, das nur um ein sauberes pre-down herum gebaut ist, ist daher konstruktionsbedingt unvollständig. Jeder gemeinsame Zustand, den das Skript ändert, braucht einen anderen Eigentümer, der ihn nach einem Absturz wiederherstellen kann, und dieser Wiederherstellungsweg muss getestet statt angenommen werden.
Prüfen Sie den Hook mit einer normalen Verbindung, einer erneuten Verbindung, einer absichtlichen Trennung und einem gezogenen Kabel. Protokollieren Sie die UUID, die Aktion und die Schnittstelle, die ausgelöst hat, ohne Geheimnisse zu loggen. Dieser Eintrag ist der einzige verlässliche Beleg dafür, dass der Hook für die beabsichtigte Verbindung lief, und er macht die nächste Änderung sicher.