OpenVPN-DNS bleibt nach SIGKILL zurück: Prüfen Sie zuerst den Besitzer

DNS löst nicht mehr auf, nachdem ein OpenVPN-Client getötet wurde, und der erste Impuls ist, /etc/resolv.conf neu zu schreiben. Diese Änderung kann einen funktionierenden Resolver zerstören, während der eigentliche veraltete Zustand woanders liegt. Die zuerst zu klärende Frage ist, wer die DNS-Einstellungen besitzt, die der Tunnel installiert hat, und ob der Beendigungsweg, der die Bereinigung übersprang, tatsächlich eine Rolle spielte.

Drei Bedingungen entscheiden die Reparatur: das Signal, das den Prozess beendet hat, die Resolver-Komponente, die die Einstellungen erhielt, und ob die Tunnel-Verbindung noch existiert. Beantworten Sie sie in dieser Reihenfolge, und die Korrektur folgt meist, ohne eine globale Datei anzufassen.

Entscheiden Sie, welche Art von Beendigung vorliegt

In der Community-Ausgabe von OpenVPN sind sowohl SIGINT als auch SIGTERM Bitten um ein geordnetes Beenden. SIGKILL ist nicht abfangbar: Es kann weder blockiert noch behandelt werden, daher bekommt keine Shutdown-Routine die Chance zu laufen. Ein normales Ctrl+C in einem Vordergrundterminal erzeugt SIGINT, während ein Supervisor, der das Warten aufgibt, üblicherweise zu SIGKILL eskaliert. Der Unterschied zählt, weil nur der zweite Fall garantiert, dass die Hooks übersprungen wurden.

Der Lauf in screen oder tmux ändert nicht, welches Signal Ctrl+C sendet. Prüfen Sie, was der Prozess tatsächlich empfangen hat, statt was das Terminal normalerweise tut.

Wenn ein Dienst oder Verbindungsmanager den Tunnel ausführt, beenden Sie genau diese Verbindung über ihren Besitzer, statt die pid zu töten. Ein Manager kann den Prozess erneut hochfahren und lässt Sie mit einem frischen Tunnel und verwirrendem Resolver-Zustand zurück. Ein eigenständiger Prozess braucht nur eine gewöhnliche Beendigungsanforderung, damit die Bereinigung läuft.

Entscheiden Sie, wer den Resolver besitzt

systemd-resolved, ein Skript im resolvconf-Stil und ein einfaches Umschreiben der Datei sind drei verschiedene Besitzer. Der erste hält Einstellungen pro Link im Speicher und verwirft sie, wenn die Schnittstelle verschwindet. Der zweite hält Einträge, die bleiben, bis etwas sie entfernt. Der dritte schreibt eine Datei und überlässt die Wiederherstellung dem, der sie geschrieben hat.

Bestimmen Sie den Besitzer, bevor Sie einen Reparaturbefehl wählen. Dasselbe Symptom hat drei verschiedene richtige Antworten, je nachdem welcher Besitzer im Einsatz ist.

Ein von NetworkManager verwaltetes VPN besitzt möglicherweise bereits Resolver-Änderungen. Ein zweiter Helfer oben drauf erzeugt zwei Besitzer, die um denselben Link konkurrieren, und der Zustand des Verlierers taucht beim nächsten Wiederverbinden wieder auf. Wenn ein Manager zuständig ist, korrigieren Sie die Einstellung im Manager statt in einem Skript.

Was der down-Hook kann und was nicht

Das Skript down läuft einmal, nachdem das TUN/TAP-Gerät geschlossen wurde. Das Hinzufügen von down-pre kehrt diese Reihenfolge um und führt das Skript aus, während das Gerät noch existiert, was Helfer benötigen, die den lebenden Link brauchen.

Keine der beiden Direktiven lässt einen Hook nach SIGKILL laufen. Privilegien werden durch down-pre auch nicht wiederhergestellt: wenn der Daemon auf user oder group herabfällt oder in eine chroot wechselt, läuft der Hook mit dem Zugriff, den das ihm lässt. Ein aufgerufener Hook kann trotzdem scheitern, den Resolver zu aktualisieren. Die OpenVPN-Referenz behandelt die Signale und den Callback-Lebenszyklus.

Prüfen Sie den eigenen Fehler des Hooks neben dem Exit-Status des Prozesses. Eine fehlende Bereinigung und eine fehlgeschlagene Bereinigung sehen im Resolver gleich und in den Logs unterschiedlich aus.

Prüfen Sie, welcher Zustand tatsächlich bleibt

Auf einem System mit systemd-resolved zeigt resolvectl status, welcher Link noch die DNS-Server oder Routing-Domains des VPN trägt. Dieser Link kann zu einer Verbindung gehören, die fort ist, oder zu einem anderen Tunnel, der noch steht.

Eine Schnittstelle, die verschwindet, nimmt ihre Per-Link-Konfiguration mit, sodass ein übersprungener Hook mit sauberem DNS koexistieren kann. Wenn der Link noch registriert ist und ausschließlich der gestoppten Verbindung gehört, sollte der zuständige Manager ihn entfernen. Wenn ein älteres Skript eine globale Resolver-Datei umgeschrieben hat, suchen Sie stattdessen nach dem dokumentierten Wiederherstellungsschritt dieses Skripts.

Stellen Sie wieder her, ohne einen anderen Link zu stehlen

Wenn Per-Link-Einstellungen in Ihrer Verwaltung liegen, resolvectl revert nimmt den Linknamen und löscht die Laufzeit-DNS-Konfiguration für diese Schnittstelle. Es ist eine Laufzeitaktion und keine Profilbearbeitung, sodass die dauerhafte Verbindungskonfiguration unberührt bleibt. Benennen Sie den falschen Link, löschen Sie das DNS für einen funktionierenden Tunnel, deshalb stammt der Name aus der Statusausgabe.

Vergewissern Sie sich, dass /etc/resolv.conf ein verwalteter symbolischer Link ist, bevor Sie ihn bearbeiten, stoppen Sie den Client dann noch einmal normal und sehen Sie erneut auf DNS. Räumt der zweite Stopp auf, war das frühere Problem die erzwungene Beendigung und nicht die Konfiguration.