resolv.conf in WSL 2: DNS sterft zodra de VPN verbinding maakt

Browsen binnen de distributie werkt, en de eerste interne hostnaam faalt op het moment dat de tunnel omhoog komt. De reflex is een publieke resolver toevoegen, wat het internet herstelt en de bedrijfsnaam de rest van de dag onbereikbaar maakt. Op WSL 2 is /etc/resolv.conf gegenereerde uitvoer en geen configuratie, en dat is het mechanisme dat het begrijpen waard is. De oplossing is geen betere resolver, het is eigenaarschap van het bestand.

Het bestand wordt gegenereerd, niet geconfigureerd

WSL 2 schrijft het bestand bij het opstarten op basis van de Windows-adapters die het op dat moment ziet, en drukt bovenaan een opmerking af die dat zegt. Wanneer een VPN-client daarna een adapter toevoegt of herschrijft, genereert de distributie niet noodzakelijk iets opnieuw, en het bestand blijft een netwerk beschrijven dat niet meer bestaat.

Een tweede faalwijze is stiller: WSL kopieert servers misschien alleen van sommige adapters. Als de fysieke adapter al een IPv6-resolver heeft, kunnen de IPv4-servers die de VPN-adapter levert worden weggelaten in plaats van toegevoegd, en het bestand lijkt compleet terwijl het precies degene weglaat die interne namen beantwoordt.

Vergelijk de Windows-weergave met de Linux-weergave

Lees beide kanten voordat je bewerkt. Kijk binnen de distributie wat het bestand bevat en of het een gewoon bestand of een koppeling is. Vermeld op Windows de resolver voor elke adapter, inclusief degene die de VPN heeft gemaakt:

ls -l /etc/resolv.conf
cat /etc/resolv.conf

Get-DnsClientServerAddress -AddressFamily IPv4
Get-NetAdapter | Where-Object Status -eq 'Up'

Wanneer de VPN-adapter de bedrijfsservers toont en Linux iets anders, zit de onenigheid in de generatie en niet in bereikbaarheid. Vergelijk zowel de adapterlijst als de adressen, want een ontbrekende adapter verklaart een ontbrekende server. Dat onderscheid bepaalt of je WSL of een firewall repareert, en die twee hebben niets gemeen.

Schakel de generatie uit en schrijf je eigen bestand

Eén gedocumenteerde instelling voorkomt dat WSL het bestand herschrijft, en die staat in /etc/wsl.conf. Voeg een netwerksectie aan dat bestand toe:

[network]
generateResolvConf = false

Beëindig daarna de distributie vanuit Windows met wsl --shutdown en start hem opnieuw. Als het pad een symbolische koppeling is en geen gewoon bestand, verwijder de koppeling voordat je je eigen inhoud schrijft, want schrijven via de koppeling kan het gegenereerde doel bij de volgende start opnieuw aanmaken. Vanaf dat punt is het bestand van jou en niets herschrijft het.

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

Zonder zoekdomein wordt een niet-gekwalificeerde hostnaam aangevuld met de publieke root en komt terug als geen dergelijk domein. timeout voorkomt dat een dode eerste server elke opzoeking blokkeert, attempts beperkt hoeveel pogingen een opzoeking verbruikt, en rotate verdeelt nieuwe pogingen in plaats van altijd bovenaan te beginnen. De ruil is dat het bestand geen VPN meer volgt waarvan het resolveradres tussen sessies verandert.

Behandel een resolver die verschuift, en verifieer daarna

Sommige clients geven een sessiespecifieke resolver uit, dus een statisch bestand breekt bij de volgende verbinding. Twee benaderingen zijn verdedigbaar. Schrijf het bestand vanuit een klein script telkens wanneer het adres verandert, of laat de generatie aan en zorg dat de adapter waarvan WSL kopieert de bedrijfsserver draagt. De tweede heeft geen haak nodig en faalt telkens wanneer de generatie de VPN-adapter overslaat; beide vereisen nog steeds dat het IPv6-conflict eerst wordt opgelost.

Windows past ook zijn eigen naambeleid toe, zoals een achtervoegsel-zoeklijst of een resolutiebeleid voor bepaalde domeinen, en het kopiëren van adapteradressen reproduceert die regels niet. Als een naam op Windows wordt opgelost en niet in de distributie met dezelfde server, vergelijk dan de behandeling van achtervoegsels voordat je de tunnel de schuld geeft.

Test met een naam en niet met een pakket: getent hosts sensor-access0.corp.example gaat door de resolver-stack, terwijl een ping kan slagen tegen een gecacht of letterlijk adres. Herhaal daarna na een onderbreking en opnieuw verbinden, want een instelling die één keer werkt en bij hervatting opnieuw wordt gegenereerd is nooit gerepareerd. Bewaar de vorige inhoud en noteer welke component het pad op die machine bezit, zodat de volgende wijziging met bewijs begint.