WSL 2 se resolv.conf: DNS sterf wanneer die VPN koppel

Blaai binne die distribusie werk, en die eerste interne gasheernaam misluk sodra die tonnel opkom. Die refleks is om ’n publieke resolver by te voeg, wat die internet herstel en die korporatiewe naam vir die res van die dag onbereikbaar maak. Op WSL 2 is /etc/resolv.conf gegenereerde uitset eerder as konfigurasie, en dit is die meganisme wat die moeite werd is om te verstaan. Die oplossing is nie ’n beter resolver nie, dit is eienaarskap van die lêer.

Die lêer word gegenereer, nie gekonfigureer nie

WSL 2 skryf die lêer by die opstart uit die Windows-adapters wat dit op daardie oomblik kan sien, en dit druk ’n opmerking boaan wat dit sê. Wanneer ’n VPN-kliënt daarna ’n adapter byvoeg of herskryf, genereer die distribusie nie noodwendig enigiets nie, en die lêer beskryf steeds ’n netwerk wat nie meer bestaan nie.

’n Tweede foutmodus is stiller: WSL kopieer dalk bedieners van slegs sommige adapters. As die fisiese adapter al ’n IPv6-resolver het, kan die IPv4-bedieners wat die VPN-adapter voorsien, weggegooi word in plaas van bygevoeg, en die lêer lyk volledig terwyl dit juis die een weglaat wat interne name beantwoord.

Vergelyk die Windows-aansig met die Linux-aansig

Lees beide kante voordat jy redigeer. Kyk binne die distribusie wat die lêer bevat en of dit ’n gewone lêer of ’n skakel is. Lys op Windows die resolver vir elke adapter, insluitend die een wat die VPN geskep het:

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

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

Wanneer die VPN-adapter die korporatiewe bedieners wys en Linux iets anders wys, lê die verskil in generering eerder as bereikbaarheid. Vergelyk die adapterlys sowel as die adresse, want ’n ontbrekende adapter verduidelik ’n ontbrekende bediener. Daardie onderskeid besluit of jy WSL of ’n firewall regmaak, en die twee het niks gemeen nie.

Skakel generering af en skryf jou eie

Een gedokumenteerde instelling keer dat WSL die lêer herskryf, en dit woon in /etc/wsl.conf. Voeg ’n netwerkafdeling by daardie lêer:

[network]
generateResolvConf = false

Beëindig dan die distribusie vanaf Windows met wsl --shutdown en begin dit weer. As die pad ’n simskakel eerder as ’n gewone lêer is, verwyder die skakel voordat jy jou eie inhoud skryf, want deur die skakel te skryf kan die gegenereerde teiken by die volgende opstart herskep. Van daardie punt af is die lêer joune en niks herskryf dit nie.

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

Sonder ’n soekdomein word ’n ongekwalifiseerde gasheernaam met die publieke wortel voltooi en kom terug as geen sodanige domein nie. timeout keer dat ’n dooie eerste bediener elke opsoek laat hang, attempts beperk hoeveel pogings ’n opsoek spandeer, en rotate versprei herprobeerslae in plaas van om altyd bo te begin. Die ruil is dat die lêer nie meer ’n VPN volg wie se resolveradres tussen sessies verander nie.

Hanteer ’n resolver wat beweeg, en verifieer dan

Sommige kliënte gee ’n sessiespesifieke resolver uit, so ’n statiese lêer breek by die volgende verbinding. Twee benaderings is verdedigbaar. Skryf die lêer uit ’n klein script wanneer die adres verander, of laat generering aan en maak seker die adapter waarvan WSL kopieer, dra die korporatiewe bediener. Die tweede het geen haak nodig nie en misluk wanneer generering die VPN-adapter oorslaan; beide vereis steeds dat die IPv6-konflik eers opgelos word.

Windows pas ook sy eie naambeleide toe, soos ’n agtervoegsel-soeklys of ’n resolusiebeleid vir spesifieke domeine, en om adapteradresse te kopieer reproduseer nie daardie reëls nie. As ’n naam op Windows oplos en nie in die distribusie met dieselfde bediener nie, vergelyk die hantering van agtervoegsels voordat jy die tonnel blameer.

Toets met ’n naam eerder as ’n pakkie: getent hosts sensor-access0.corp.example gaan deur die resolver-stapel, terwyl ’n ping kan slaag teen ’n gekaste of letterlike adres. Herhaal dan ná ’n ontkoppeling en herverbinding, want ’n instelling wat een keer werk en by hervatting weer gegenereer word, was nooit reggemaak nie. Stoor die vorige inhoud en let op watter komponent die pad op daardie masjien besit, sodat die volgende verandering met bewyse begin.