resolv.conf zu bearbeiten behebt DNS nach dem VPN-Trennen nicht

Sie trennen das VPN, ping 1.1.1.1 antwortet weiterhin, und jede Namensauflösung hängt, bevor die Seite schließlich aufgibt. Dann zeigt cat /etc/resolv.conf einen Nameserver, den es nur jemals innerhalb des Tunnels gab, meist an erster Stelle der Liste. Das Löschen dieser Zeile scheint das Problem für etwa zehn Minuten zu beheben, bis ein Suspend, ein Wi-Fi-Roaming oder ein Neustart sie zurückbringt. Die Datei, die Sie bearbeitet haben, ist nicht die Einstellung; sie ist eine Darstellung des Link-Status, der einer anderen Komponente gehört.

Warum ein veralteter Eintrag Sekunden pro Auflösung kostet

Der glibc-Resolver geht die Nameserver-Liste der Reihe nach durch und wartet einen Timeout ab, bevor er den nächsten versucht, und resolv.conf(5) begrenzt diese Liste auf drei Einträge. Setzen Sie einen Resolver auf der Tunnelseite wie 10.8.0.1 an die Spitze, nachdem der Tunnel weg ist, und jede Auflösung zahlt den Timeout, bevor sie auf einen Server durchfällt, der antwortet. Deshalb sieht das Symptom wie eine tote Verbindung und nicht wie ein DNS-Fehler aus: Browser blockieren, laufen in eine Zeitüberschreitung und liefern manchmal eine zwischengespeicherte Adresse, die später veraltet.

Das erklärt auch, warum die Beschwerde als „das Internet ist kaputt“ ankommt. Ein Ping auf eine IP-Adresse beweist, dass der Link in Ordnung ist, was den Fehler wie einen der Anwendung aussehen lässt. Die Resolver-Liste ist das Erste, was man liest, und das Letzte, was man bearbeitet.

Der Mythos: resolv.conf ist eine Einstellungsdatei

Fragen Sie, was der Pfad tatsächlich ist, bevor Sie ihn ändern:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf

Auf einem systemd-resolved-Host ist es ein symbolischer Link auf eine Stub-Datei, die auf 127.0.0.53 zeigt, und die echten Server leben im Pro-Link-Zustand, den resolvectl ausgibt. Auf einem NetworkManager-Host ist es möglicherweise eine Datei, die NetworkManager aus der aktiven Verbindung schreibt. Bei manchen Hersteller-Clients ist es eine einfache Datei, die beim Verbinden an Ort und Stelle neu geschrieben und, wenn Sie Pech haben, beim Trennen nie wiederhergestellt wird. Das sind drei verschiedene Eigentümer, und die ersten beiden von Hand zu bearbeiten bewirkt entweder nichts oder hält bis zum nächsten Netzwerkereignis.

resolvectl status ist die Ansicht, die die Wahrheit sagt: DNS-Server pro Link, Routing-Domänen und ob der Tunnel-Link noch existiert. resolvectl query example.com geht weiter und zeigt, welche Schnittstelle geantwortet hat. Nutzen Sie beides, bevor Sie eine Datei anfassen, und bedenken Sie, dass ein Browser mit eigenem sicheren DNS all das ignoriert.

Finden Sie den Eigentümer, bevor Sie etwas bearbeiten

Drei Komponenten konkurrieren normalerweise um dieselbe Einstellung: systemd-resolved, NetworkManager und was auch immer der VPN-Client installiert hat. Identifizieren Sie zuerst die lebende:

systemctl is-active systemd-resolved
nmcli connection show --active
ps aux | grep -E "openvpn|wg-quick|vpn"

Wenn resolved aktiv ist und der symbolische Link auf ihren Stub zeigt, ist die globale Datei generierte Ausgabe und Ihre Bearbeitung kosmetisch. Wenn NetworkManager die Verbindung besitzt, gehören die Server zum Verbindungsprofil, also ist die Lösung eine nmcli-Eigenschaftsänderung statt einer Dateibearbeitung. Wenn ein Hersteller-Daemon läuft, überlebt nur sein eigener Wiederherstellungspfad die nächste Verbindung.

Räumen Sie den Link-Status auf, den der Client hinterlassen hat

Ein getöteter Client kann seinen Aufräum-Hook nicht ausführen. SIGKILL lässt sich überhaupt nicht abfangen, SIGINT und SIGTERM hingegen schon, daher hinterlässt ein Tunnel, der nach einem erzwungenen Kill „einfach aufhörte“, oft sowohl die Schnittstellenregistrierung als auch den Resolver-Eintrag an Ort und Stelle. Finden Sie die konkrete PID und senden Sie das Signal nur an diese:

ps aux | grep -E "openvpn|wg-quick"
sudo kill <pid>
resolvectl revert tun0

Greifen Sie nicht zu pkill -f vpn oder killall vpn, bevor Sie die vollständige Trefferliste gelesen haben. -f vergleicht die gesamte Befehlszeile, kann also ein Wrapper-Skript, eine Editor-Sitzung oder einen nicht zusammenhängenden Prozess beenden, dessen Pfad die Zeichenfolge enthält. Den falschen Prozess mitten im Lauf zu beenden, ist der Weg, auf dem aus einem Resolver-Problem eine verlorene Datei wird.

resolvectl revert setzt die Laufzeit-DNS-Konfiguration dieses Links zurück, was enger ist als ein Neustart des Resolvers und viel enger als das Bearbeiten der globalen Datei. Wenn der Tunnel-Link ganz verschwunden ist, baut systemctl restart NetworkManager den Verbindungszustand neu auf, und das ist der Schritt, zu dem die Quell-Threads immer wieder zurückkehren. Achten Sie auf einen Dienstmanager mit Restart=always, denn er kann einen getöteten Client samt seinen DNS-Einstellungen direkt zurückbringen.

Die andere Richtung: gepushtes DNS, das nie ankam

Das Spiegelbild des veralteten Eintrags ist ein Tunnel ganz ohne brauchbaren Resolver. Eine DNS-Option im Profil ist eine Anfrage; die Komponente, die die Verbindung verwaltet, muss sie an den Resolver weitergeben. Wenn das Log zeigt, dass der Server empfangen wurde, der Tunnel-Link aber keine DNS-Einstellungen trägt, fehlt die Integration, nicht der Server.

Testen Sie die Übergabe, indem Sie sie manuell durchführen, was „der Server ist falsch“ von „niemand hat ihn angewendet“ trennt:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

Die Routing-Domäne, die alles abfängt, schickt jeden Namen an diesen Link, was ein Full-Tunnel-Client will und was Split-DNS nicht verwenden darf. Diese Einstellungen verschwinden bei der nächsten Verbindung. Um sie in NetworkManager dauerhaft zu machen, deaktivieren Sie automatisches DNS, setzen Sie den Server auf die Verbindung und fügen Sie die Domäne hinzu:

nmcli connection modify office ipv4.ignore-auto-dns yes
nmcli connection modify office ipv4.dns 10.10.10.10
nmcli connection modify office ipv4.dns-search "~."

Für einen Firmentunnel, der nur interne Namen beantworten soll, listen Sie diese Zonen mit einer führenden Tilde statt des Alles-Abfangens auf, damit öffentliche Namen weiterhin den lokalen Resolver nutzen.

Workarounds, die zum nächsten Ausfall werden

resolv.conf vor dem Verbinden zu kopieren und danach wiederherzustellen ist eine legitime Zeile in einem Runbook, und es ist ein Workaround statt einer Reparatur. Er scheitert genau dann, wenn es darauf ankommt, weil ein Absturz oder ein erzwungener Neustart die Wiederherstellung überspringt. Schreiben Sie ihn als Workaround auf, damit die nächste Person nicht darauf aufbaut.

systemd-resolved zu deaktivieren und öffentliche Server fest zu verdrahten ist der andere beliebte Schritt. Er macht Verbinden und Trennen vorhersehbar und entfernt das DNS pro Link für jedes andere Netzwerk, was Split-DNS für interne Namen bricht und den Zweck eines Tunnels zunichtemacht, der Abfragen darin halten soll. resolvconf zu installieren und öffentliche Server festzunageln kostet dasselbe mit einer zusätzlichen Schicht. Behandeln Sie beides als Diagnose: Wenn es das Surfen wiederherstellt, haben Sie gelernt, dass die Resolver-Integration schuld ist, nicht dass die öffentlichen Server richtig sind.

Die dauerhafte Lösung ist ein Eigentümer pro Schicht: Entscheiden Sie, welche Komponente das DNS des Tunnel-Links besitzt und welche den globalen Standard, schreiben Sie es auf und entfernen Sie die anderen aus dem Pfad. Prüfen Sie dann nach einem Trennen mit einem Namen, den nur das VPN auflöst. Wenn ein privater Name weiterhin antwortet, wurde die Registrierung nicht entfernt; wenn gar nichts aufgelöst wird, zeigt die Datei auf einen Server, der nicht mehr existiert. Beides ist in resolvectl sichtbar, bevor Sie einen Browser öffnen.