WSL2 verliert DNS nach dem VPN-Verbindungsaufbau? Zwei Ursachen

Eine veraltete Resolver-Datei und eine konkurrierende Routenmetrik erzeugen dasselbe Symptom in WSL2. Erfassen Sie beide Seiten und reparieren Sie dann die, die wirklich defekt ist.

Ping per Adresse funktioniert innerhalb der Distribution, Paketinstallationen und git-Abrufe nicht, und der Fehler trat direkt nach dem Hochfahren des Tunnels auf. Nur Namen wurden nicht mehr aufgelöst, was auf DNS und nicht auf Konnektivität hindeutet. Pakete neu zu installieren ist hier der beliebteste falsche erste Schritt. WSL2 hat zwei unabhängige Wege, genau dieses Symptom zu erzeugen, und sie brauchen unterschiedliche Reparaturen.

Warum die Distribution einen eigenen Resolver hält

Der DNS-Client von Windows wird innerhalb der Distribution nicht verwendet. WSL2 baut beim Start eine eigene Resolver-Datei auf, die auf eine Stub-Adresse zeigt, die Windows am virtuellen Switch für die Hilfs-VM veröffentlicht.

Diese Anordnung ist bei gewöhnlichen Netzwerkänderungen stabil, weil sie einmal geschrieben und wiederverwendet wird. Sie ist nicht mehr korrekt, wenn ein Tunnel-Client die Adapterliste des Hosts neu schreibt, nachdem die Hilfs-VM bereits gestartet ist.

Nichts in der Distribution beobachtet die Änderung, also zeigt die Datei weiter auf eine Adresse, die vielleicht nicht mehr auf dem Pfad liegt. Die nächste Auflösung wartet dann, läuft in eine Zeitüberschreitung oder bekommt eine Antwort von einem Server, der von der internen Zone nie gehört hat. Von innen hört der Resolver einfach auf zu antworten, und jeder Name scheitert auf einmal.

Sammeln Sie zuerst Belege auf beiden Seiten

Halten Sie fest, was die Distribution sieht, dann was Windows sieht, bevor Sie eines von beiden ändern. Erst die beiden Ansichten zusammen unterscheiden die Fehlerarten.

Geben Sie innerhalb der Distribution die Resolver-Datei, die Routing-Tabelle und je eine interne und eine öffentliche Auflösung aus:

ip -4 route
cat /etc/resolv.conf
getent hosts intranet.corp.example
getent hosts example.com

Listen Sie unter Windows die DNS-Server pro Adapter und die IPv4-Tabelle mit Metriken auf. Ein VPN-Client installiert üblicherweise eine Route für das WSL2-Subnetz, und ihre Metrik entscheidet, ob dieser Verkehr durch den Tunnel verlässt oder lokal bleibt.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Routenmetrik oder veraltete Datei

Der erste Fehler ist die veraltete Datei. Der Resolver wurde für den Adapterzustand beim Start geschrieben, und der Tunnel hat diesen Zustand geändert. Seine Stub-Adresse ist nun vielleicht nicht erreichbar, oder sie nennt einen Server, der von der internen Zone nichts weiß.

Der zweite ist ein Routingproblem. Wenn das VPN eine Route hinzufügt, die das WSL2-Subnetz abdeckt, mit einer Metrik unter der Link-Route des Hosts, geraten Pakete an die Hilfs-VM in den Tunnel. Dann laufen alle WSL2-Dienste in Zeitüberschreitungen, nicht nur DNS.

Der unterscheidende Test kostet eine Zeile. Wenn eine numerische Adresse wie ein öffentlicher Resolver weiter auf Ping antwortet, während Namen scheitern, ist der Pfad intakt und DNS das Problem. Das ist der Fall, in dem eine Resolver-Änderung gerechtfertigt ist, und der Fall, in dem sie es nicht ist, wird damit auch deutlich. Scheitert auch der numerische Test, hat die Hilfs-VM ihre Route verloren, und keine Resolver-Datei wird das richten.

Für den Routingfall nehmen Sie die automatische Metrik am Tunneladapter weg und geben ihm eine Zahl über der WSL2-Link-Route:

Get-NetAdapter | Where-Object InterfaceDescription -Match VPN | Set-NetIPInterface -InterfaceMetric 5500
wsl.exe --shutdown

Das Herunterfahren zählt. Eine Metrikänderung schreibt die laufende Hilfs-VM nicht neu, deshalb muss die Distribution neu aufgebaut werden, bevor die Änderung sichtbar wird.

Übernehmen Sie die Datei, bewusst

Wenn das Routing stimmt und nur interne Namen scheitern, ist der Resolver schuld, und Sie können den Generator anhalten. Das ist eine bewusste Änderung mit Wartungskosten, kein Behelf, den man nebenbei anwendet.

Erstellen Sie /etc/wsl.conf innerhalb der Distribution mit dem Netzwerkabschnitt, der die Erzeugung abschaltet, und schreiben Sie die Resolver-Datei dann selbst, Firmenserver zuerst und eine öffentliche Rückfalladresse danach:

[network]
generateResolvConf = false
search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

Die Reihenfolge zählt. Ein öffentlicher Resolver kann einen internen Namen nicht beantworten, und die Rückfalladresse existiert nur für Internet-Auflösungen. Sobald die Datei Ihnen gehört, erzeugt sie nichts neu, also wird ein Firmenserver, der umzieht, zu einem Ausfall, den Sie selbst bemerken müssen.

Prüfen Sie Namen, dann Pakete

Prüfen Sie einen internen und einen öffentlichen Namen mit dem System-Resolver und wiederholen Sie dann den Vorgang, der fehlschlug. Paketmanager verwenden manchmal einen eigenen Resolver, weshalb ein funktionierendes getent neben einer defekten Installation bestehen kann.

Wenn Sie das Neuschreiben automatisieren, machen Sie es idempotent: ohne Tunnel die vorhandene Datei behalten, statt eine leere Serverliste zu schreiben.

getent hosts intranet.corp.example
resolvectl status | head -20
getent hosts example.com

Eine funktionierende interne und eine funktionierende öffentliche Auflösung von innen in der Distribution sind das Ergebnis, das es festzuhalten lohnt. Ein grünes VPN-Symbol auf dem Host beweist keines von beiden.

Ähnliche Artikel