resolv.conf unter WSL 2: DNS stirbt, wenn sich das VPN verbindet

WSL erzeugt resolv.conf aus den Windows-Adaptern, die es sieht, daher kommt der Resolver des VPN womöglich nie an. Stoppen Sie die Erzeugung, und testen Sie dann einen Firmennamen.

Das Surfen innerhalb der Distribution funktioniert, und der erste interne Hostname scheitert in dem Moment, in dem der Tunnel hochkommt. Der Reflex ist, einen öffentlichen Resolver einzutragen, was das Internet wiederherstellt und den Firmennamen für den Rest des Tages unerreichbar macht. Unter WSL 2 ist /etc/resolv.conf erzeugte Ausgabe und keine Konfiguration, und genau dieser Mechanismus ist es wert, verstanden zu werden. Die Lösung ist kein besserer Resolver, sondern der Besitz der Datei.

Die Datei wird erzeugt, nicht konfiguriert

WSL 2 schreibt die Datei beim Start aus den Windows-Adaptern, die es in diesem Moment sieht, und druckt oben einen Kommentar, der das sagt. Wenn ein VPN-Client danach einen Adapter hinzufügt oder umschreibt, erzeugt die Distribution nicht zwingend etwas neu, und die Datei beschreibt weiterhin ein Netz, das es nicht mehr gibt.

Ein zweiter Fehlermodus ist leiser: WSL kopiert Server möglicherweise nur aus einigen Adaptern. Hat der physische Adapter bereits einen IPv6-Resolver, können die IPv4-Server, die der VPN-Adapter liefert, verworfen statt angehängt werden, und die Datei wirkt vollständig, während sie genau den auslässt, der interne Namen beantwortet.

Vergleichen Sie die Windows-Sicht mit der Linux-Sicht

Lesen Sie beide Seiten, bevor Sie bearbeiten. Sehen Sie in der Distribution nach, was die Datei enthält und ob sie eine reguläre Datei oder ein Link ist. Listen Sie unter Windows den Resolver jedes Adapters auf, einschließlich des vom VPN erzeugten:

ls -l /etc/resolv.conf
cat /etc/resolv.conf
Get-DnsClientServerAddress -AddressFamily IPv4
Get-NetAdapter | Where-Object Status -eq 'Up'

Wenn der VPN-Adapter die Firmenserver zeigt und Linux etwas anderes, liegt die Abweichung in der Erzeugung und nicht in der Erreichbarkeit. Vergleichen Sie die Adapterliste ebenso wie die Adressen, denn ein fehlender Adapter erklärt einen fehlenden Server. Diese Unterscheidung entscheidet, ob Sie WSL oder eine Firewall reparieren, und beides hat nichts gemeinsam.

Schalten Sie die Erzeugung ab und schreiben Sie Ihre eigene Datei

Eine dokumentierte Einstellung hindert WSL daran, die Datei neu zu schreiben, und sie steht in /etc/wsl.conf. Fügen Sie dieser Datei einen Netzwerkabschnitt hinzu:

[network]
generateResolvConf = false

Beenden Sie dann die Distribution von Windows aus mit wsl --shutdown und starten Sie sie erneut. Ist der Pfad ein symbolischer Link und keine reguläre Datei, entfernen Sie den Link, bevor Sie eigenen Inhalt schreiben, denn Schreiben über den Link kann das erzeugte Ziel beim nächsten Start neu anlegen. Ab diesem Punkt gehört die Datei Ihnen und nichts schreibt sie neu.

nameserver 172.28.4.10
nameserver 172.28.4.11
search site.corp.example
options timeout:1 attempts:2 rotate

Ohne Suchdomäne wird ein unqualifizierter Hostname mit der öffentlichen Wurzel ergänzt und kommt als „keine solche Domäne“ zurück. timeout hindert einen toten ersten Server daran, jede Abfrage zu blockieren, attempts begrenzt, wie viele Versuche eine Abfrage verbraucht, und rotate verteilt Wiederholungen, statt immer oben zu beginnen. Der Preis ist, dass die Datei keinem VPN mehr folgt, dessen Resolveradresse sich zwischen Sitzungen ändert.

Behandeln Sie einen Resolver, der wandert, und prüfen Sie dann

Manche Clients geben einen sitzungsspezifischen Resolver aus, sodass eine statische Datei bei der nächsten Verbindung bricht. Zwei Vorgehen sind vertretbar. Schreiben Sie die Datei aus einem kleinen Skript, wann immer sich die Adresse ändert, oder lassen Sie die Erzeugung an und stellen Sie sicher, dass der Adapter, von dem WSL kopiert, den Firmenserver trägt. Das zweite braucht keinen Hook und scheitert, wann immer die Erzeugung den VPN-Adapter überspringt; beide verlangen weiterhin, den IPv6-Konflikt zuerst zu lösen.

Windows wendet außerdem eigene Namensrichtlinien an, etwa eine Suffixsuchliste oder eine Auflösungsrichtlinie für bestimmte Domänen, und das Kopieren von Adapteradressen bildet diese Regeln nicht nach. Löst sich ein Name unter Windows und nicht in der Distribution mit demselben Server, vergleichen Sie die Suffixbehandlung, bevor Sie den Tunnel beschuldigen.

Testen Sie mit einem Namen statt mit einem Paket: getent hosts sensor-access0.corp.example geht durch den Resolver-Stack, während ein Ping gegen eine zwischengespeicherte oder wörtliche Adresse gelingen kann. Wiederholen Sie das dann nach Trennen und erneutem Verbinden, denn eine Einstellung, die einmal funktioniert und beim Fortsetzen neu erzeugt wird, wurde nie repariert. Sichern Sie den vorherigen Inhalt und notieren Sie, welche Komponente den Pfad auf dieser Maschine besitzt, damit die nächste Änderung mit Belegen beginnt.

Ähnliche Artikel