resolv.conf i WSL 2: DNS dør når VPN-en kobler til
WSL genererer resolv.conf på nytt fra Windows-adapterne den ser, så VPN-ens resolver kommer kanskje aldri frem. Stopp genereringen, og test deretter et bedriftsnavn.
Nettlesing inne i distribusjonen virker, og det første interne vertsnavnet feiler i det øyeblikket tunnelen kommer opp. Refleksen er å legge til en offentlig resolver, som gjenoppretter internettet og gjør bedriftsnavnet utilgjengelig resten av dagen. På WSL 2 er /etc/resolv.conf generert utdata og ikke konfigurasjon, og det er denne mekanismen som er verdt å forstå. Løsningen er ikke en bedre resolver, det er eierskapet til filen.
Filen genereres, den konfigureres ikke
WSL 2 skriver filen ved oppstart fra Windows-adapterne den ser i det øyeblikket, og skriver ut en kommentar øverst som sier det. Når en VPN-klient senere legger til eller skriver om en adapter, regenererer ikke distribusjonen nødvendigvis noe, og filen fortsetter å beskrive et nettverk som ikke finnes lenger.
En andre feilmodus er stillere: WSL kopierer kanskje bare servere fra noen adaptere. Hvis den fysiske adapteren allerede har en IPv6-resolver, kan IPv4-serverne som VPN-adapteren leverer, bli droppet i stedet for lagt til, og filen ser komplett ut mens den nettopp utelater den som svarer på interne navn.
Sammenlign Windows-visningen med Linux-visningen
Les begge sider før du redigerer. Inne i distribusjonen ser du hva filen inneholder og om den er en vanlig fil eller en lenke. På Windows lister du opp resolveren for hver adapter, inkludert den VPN-en opprettet:
ls -l /etc/resolv.conf
cat /etc/resolv.conf
Get-DnsClientServerAddress -AddressFamily IPv4
Get-NetAdapter | Where-Object Status -eq 'Up'
Når VPN-adapteren viser bedriftens servere og Linux viser noe annet, ligger uenigheten i genereringen og ikke i tilgjengeligheten. Sammenlign adapterlisten så vel som adressene, fordi en manglende adapter forklarer en manglende server. Den forskjellen avgjør om du reparerer WSL eller en brannmur, og de to har ingenting til felles.
Slå av genereringen og skriv din egen fil
Én dokumentert innstilling hindrer WSL i å skrive filen på nytt, og den ligger i /etc/wsl.conf. Legg til en nettverksseksjon i den filen:
[network]
generateResolvConf = false
Avslutt deretter distribusjonen fra Windows med wsl --shutdown og start den igjen. Hvis banen er en symbolsk lenke og ikke en vanlig fil, fjern lenken før du skriver ditt eget innhold, fordi skriving gjennom lenken kan gjenopprette det genererte målet ved neste oppstart. Fra det punktet er filen din, og ingenting skriver den på nytt.
nameserver 172.28.4.10
nameserver 172.28.4.11
search site.corp.example
options timeout:1 attempts:2 rotate
Uten et søkedomene blir et ukvalifisert vertsnavn supplert med den offentlige roten og kommer tilbake som at det ikke finnes noe slikt domene. timeout hindrer en død første server i å blokkere hvert oppslag, attempts begrenser hvor mange forsøk et oppslag bruker, og rotate fordeler nye forsøk i stedet for alltid å starte øverst. Byttet er at filen ikke lenger følger en VPN der resolveradressen endres mellom økter.
Håndter en resolver som flytter på seg, og verifiser deretter
Noen klienter deler ut en økts-spesifikk resolver, så en statisk fil bryter ved neste tilkobling. To tilnærminger er forsvarlige. Skriv filen fra et lite skript hver gang adressen endres, eller la genereringen stå på og sørg for at adapteren WSL kopierer fra, bærer bedriftens server. Den andre trenger ingen krok og feiler hver gang genereringen hopper over VPN-adapteren; begge krever fortsatt at IPv6-konflikten løses først.
Windows bruker også egne navnepolicyer, som en suffikssøkeliste eller en oppløsningspolicy for bestemte domener, og kopiering av adapteradresser gjenskaper ikke disse reglene. Hvis et navn løses på Windows og ikke i distribusjonen med samme server, sammenlign suffiksbehandlingen før du gir tunnelen skylden.
Test med et navn og ikke med en pakke: getent hosts sensor-access0.corp.example går gjennom resolverstakken, mens en ping kan lykkes mot en bufret eller bokstavelig adresse. Gjenta deretter etter frakobling og tilkobling, fordi en innstilling som virker én gang og genereres på nytt ved gjenopptakelse aldri ble rettet. Lagre det forrige innholdet og noter hvilken komponent som eier banen på den maskinen, slik at neste endring begynner med bevis.