WSL2 verloor DNS nadat de VPN verbond? Twee oorzaken

Ping op adres werkt binnen de distributie, pakketinstallaties en git-ophalingen niet, en de fout verscheen direct nadat de tunnel omhoogkwam. Alleen namen stopten met resolveren, wat op DNS wijst en niet op connectiviteit. Pakketten opnieuw installeren is hier de populairste verkeerde eerste stap. WSL2 heeft twee onafhankelijke manieren om precies dat symptoom te veroorzaken, en ze vragen verschillende reparaties.

Waarom de distributie een eigen resolver houdt

De DNS-client van Windows wordt niet binnen de distributie gebruikt. WSL2 bouwt bij het starten een eigen resolver-bestand, dat wijst naar een stub-adres dat Windows op de virtuele switch publiceert voor de hulp-VM.

Die regeling is stabiel bij gewone netwerkwijzigingen omdat ze één keer wordt geschreven en hergebruikt. De regeling is niet meer correct wanneer een tunnelclient de adapterlijst van de host herschrijft nadat de hulp-VM al is gestart.

Niets in de distributie houdt de wijziging in de gaten, dus het bestand blijft wijzen naar een adres dat misschien niet meer op het pad ligt. De volgende opzoeking wacht dan, loopt af of krijgt antwoord van een server die nog nooit van de interne zone heeft gehoord. Van binnenuit stopt de resolver gewoon met antwoorden, en elke naam faalt tegelijk.

Verzamel eerst bewijs aan beide kanten

Leg vast wat de distributie ziet, dan wat Windows ziet, voordat u een van beide wijzigt. Juist de twee weergaven samen onderscheiden de faalmodi.

Print binnen de distributie het resolver-bestand, de routetabel en een interne en een openbare opzoeking:

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

Op Windows, som de DNS-servers per adapter op en de IPv4-tabel met metriek. Een VPN-client installeert meestal een route voor het WSL2-subnet, en zijn metriek bepaalt of dat verkeer via de tunnel weggaat of lokaal blijft.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Routemetriek of verouderd bestand

De eerste fout is het verouderde bestand. De resolver is geschreven voor de adapterstatus bij het starten, en de tunnel heeft die status veranderd. Het stub-adres is nu misschien onbereikbaar, of het noemt een server die niets van de interne zone weet.

De tweede is een routeringsprobleem. Wanneer de VPN een route toevoegt die het WSL2-subnet dekt met een metriek lager dan de linkroute van de host, gaan pakketten gericht aan de hulp-VM de tunnel in. Dan loopt elke WSL2-dienst af, niet alleen DNS.

De onderscheidende test kost één regel. Als een numeriek adres zoals een openbare resolver nog op ping antwoordt terwijl namen falen, is het pad intact en is DNS het probleem. Dat is het geval waarin een resolver-wijziging gerechtvaardigd is, en het geval waarin dat niet zo is wordt ook duidelijk. Als de numerieke test ook faalt, heeft de hulp-VM zijn route verloren en geen enkel resolver-bestand lost dat op.

Voor het routeringsgeval, verwijder de automatische metriek op de tunneladapter en geef hem een getal boven de WSL2-linkroute:

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

Het afsluiten maakt uit. De metriek wijzigen herschrijft de draaiende hulp-VM niet, dus de distributie moet opnieuw worden gebouwd voordat de wijziging zichtbaar is.

Neem het bestand over, bewust

Als routering correct is en alleen interne namen falen, is de resolver de schuldige en kunt u de generator stoppen. Dat is een bewuste wijziging met onderhoudskosten, geen omweg om achteloos toe te passen.

Maak /etc/wsl.conf binnen de distributie met de netwerksectie die generatie uitschakelt, en schrijf daarna het resolver-bestand zelf, bedrijfsserver eerst en een openbare terugval daarna:

[network]
generateResolvConf = false

search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

De volgorde maakt uit. Een openbare resolver kan geen interne naam beantwoorden, en de terugval bestaat alleen voor internetopzoekingen. Zodra het bestand van u is, regenereert niets het, dus een bedrijfsserver die verhuist wordt een storing die u zelf moet opmerken.

Controleer namen, dan pakketten

Verifieer een interne en een openbare naam met de systeemresolver, en herhaal daarna de bewerking die faalde. Pakketbeheerders gebruiken soms een eigen resolver, daarom kan een werkende getent naast een kapotte installatie bestaan.

Als u het herschrijven automatiseert, maak het idempotent: zonder tunnel het bestaande bestand behouden in plaats van een lege serverlijst te schrijven.

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

Een werkende interne opzoeking en een werkende openbare opzoeking, van binnenuit de distributie, is het resultaat dat het vastleggen waard is. Een groen VPN-pictogram op de host bewijst geen van beide.