resolv.conf i WSL 2: DNS dör när VPN:en ansluter

WSL återskapar resolv.conf från de Windows-adapter som den ser, så VPN:ens resolver kanske aldrig kommer fram. Stoppa genereringen och testa sedan ett företagsnamn.

Bläddring inuti distributionen fungerar, och det första interna värdnamnet misslyckas i samma stund som tunneln kommer upp. Reflektionen är att lägga till en offentlig resolver, vilket återställer internet och gör företagsnamnet oåtkomligt resten av dagen. På WSL 2 är /etc/resolv.conf genererad utdata och inte konfiguration, och det är den mekanismen som är värd att förstå. Åtgärden är inte en bättre resolver, det är ägandet av filen.

Filen genereras, den konfigureras inte

WSL 2 skriver filen vid start utifrån de Windows-adapter som den ser i det ögonblicket, och skriver ut en kommentar högst upp som säger det. När en VPN-klient senare lägger till eller skriver om en adapter återskapar distributionen inte nödvändigtvis något, och filen fortsätter att beskriva ett nätverk som inte längre finns.

Ett andra felläge är tystare: WSL kopierar kanske bara servrar från vissa adaptrar. Om den fysiska adaptern redan har en IPv6-resolver kan de IPv4-servrar som VPN-adaptern levererar släppas i stället för att läggas till, och filen ser komplett ut medan den just utelämnar den som svarar på interna namn.

Jämför Windows-vyn med Linux-vyn

Läs båda sidorna innan du redigerar. Titta i distributionen vad filen innehåller och om den är en vanlig fil eller en länk. På Windows listar du resolvern för varje adapter, inklusive den som VPN:en skapade:

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

När VPN-adaptern visar företagets servrar och Linux visar något annat ligger oenigheten i genereringen och inte i nåbarheten. Jämför både adapterlistan och adresserna, eftersom en saknad adapter förklarar en saknad server. Den skillnaden avgör om du reparerar WSL eller en brandvägg, och de två har ingenting gemensamt.

Stäng av genereringen och skriv din egen fil

En dokumenterad inställning hindrar WSL från att skriva om filen, och den finns i /etc/wsl.conf. Lägg till ett nätverksavsnitt i den filen:

[network]
generateResolvConf = false

Avsluta sedan distributionen från Windows med wsl --shutdown och starta den igen. Om sökvägen är en symbolisk länk och inte en vanlig fil, ta bort länken innan du skriver ditt eget innehåll, eftersom skrivning genom länken kan återskapa det genererade målet vid nästa start. Från den punkten är filen din och ingenting skriver om den.

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

Utan en sökdomän kompletteras ett okvalificerat värdnamn med den offentliga roten och kommer tillbaka som att det inte finns någon sådan domän. timeout hindrar en död första server från att blockera varje uppslag, attempts begränsar hur många försök ett uppslag förbrukar, och rotate sprider ut nya försök i stället för att alltid börja högst upp. Byttet är att filen inte längre följer en VPN vars resolveradress ändras mellan sessioner.

Hantera en resolver som flyttar sig och verifiera sedan

Vissa klienter delar ut en sessionsspecifik resolver, så en statisk fil går sönder vid nästa anslutning. Två tillvägagångssätt är försvarbara. Skriv filen från ett litet skript varje gång adressen ändras, eller låt genereringen vara på och se till att adaptern som WSL kopierar från bär företagets server. Det andra behöver ingen krok och misslyckas varje gång genereringen hoppar över VPN-adaptern; båda kräver fortfarande att IPv6-konflikten löses först.

Windows tillämpar också sina egna namnprinciper, som en suffixsöklista eller en upplösningsprincip för särskilda domäner, och kopiering av adapteradresser återskapar inte dessa regler. Om ett namn löses i Windows men inte i distributionen med samma server, jämför suffixhanteringen innan du skyller på tunneln.

Testa med ett namn och inte med ett paket: getent hosts sensor-access0.corp.example går genom resolverstacken, medan en ping kan lyckas mot en cachad eller bokstavlig adress. Upprepa sedan efter frånkoppling och återanslutning, eftersom en inställning som fungerar en gång och genereras om när den återupptas aldrig blev fixad. Spara föregående innehåll och notera vilken komponent som äger sökvägen på den maskinen, så att nästa ändring börjar med bevis.

Relaterade artiklar