WSL2 menetti DNS:n VPN-yhteyden jälkeen? Kaksi syytä

Vanhentunut resolver-tiedosto ja kilpaileva reitin metriikka tuottavat saman oireen WSL2:n sisällä. Tallenna molemmat puolet ja korjaa sitten se, joka on todella rikki.

Ping osoitteella toimii jakelun sisällä, pakettiasennukset ja git-haut eivät, ja vika ilmaantui heti tunnelin noustua. Vain nimien selvitys lakkasi, mikä viittaa DNS:ään eikä yhteyteen. Pakettien uudelleenasennus on täällä suosituin väärä ensimmäinen askel. WSL2:lla on kaksi riippumatonta tapaa tuottaa juuri tuo oire, ja ne vaativat erilaiset korjaukset.

Miksi jakelu pitää oman resolverinsa

Windowsin DNS-asiakasta ei käytetä jakelun sisällä. WSL2 rakentaa käynnistyksessä oman resolver-tiedostonsa, joka osoittaa stub-osoitteeseen, jonka Windows julkaisee apuvirtuaalikoneen virtuaalikytkimellä.

Järjestely on vakaa tavallisissa verkkomuutoksissa, koska se kirjoitetaan kerran ja sitä käytetään uudelleen. Järjestely lakkaa olemasta oikein, kun tunneliasiakas kirjoittaa isäntäkoneen sovitinluettelon uudelleen sen jälkeen, kun apuvirtuaalikone on jo käynnistynyt.

Mikään jakelun sisällä ei seuraa muutosta, joten tiedosto osoittaa edelleen osoitteeseen, joka ei ehkä enää ole polulla. Seuraava haku silloin odottaa, aikakatkaisee tai saa vastauksen palvelimelta, joka ei ole koskaan kuullut sisäisestä vyöhykkeestä. Sisältä resolver yksinkertaisesti lakkaa vastaamasta, ja kaikki nimet epäonnistuvat kerralla.

Kerää ensin todisteet molemmilta puolilta

Kirjaa, mitä jakelu näkee, ja sitten mitä Windows näkee, ennen kuin muutat kumpaakaan. Juuri kaksi näkymää yhdessä erottaa vikatilat.

Jakelun sisällä tulosta resolver-tiedosto, reititystaulukko sekä yksi sisäinen ja yksi julkinen haku:

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

Windowsissa luettele DNS-palvelimet sovitinkohtaisesti ja IPv4-taulukko metriikoineen. VPN-asiakas asentaa yleensä reitin WSL2-aliverkolle, ja sen metriikka ratkaisee, lähteekö liikenne tunnelin kautta vai jääkö paikalliseksi.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Reitin metriikka vai vanhentunut tiedosto

Ensimmäinen vika on vanhentunut tiedosto. Resolver kirjoitettiin käynnistyshetken sovitintilaa varten, ja tunneli muutti sitä tilaa. Sen stub-osoite voi nyt olla tavoittamaton, tai se voi nimetä palvelimen, joka ei tiedä sisäisestä vyöhykkeestä mitään.

Toinen on reititysongelma. Kun VPN lisää WSL2-aliverkon kattavan reitin, jonka metriikka on isäntäkoneen linkkireittiä alempi, apuvirtuaalikoneelle osoitetut paketit menevät tunneliin. Silloin jokainen WSL2-palvelu aikakatkaisee, ei vain DNS.

Erottava testi maksaa yhden rivin. Jos numeerinen osoite, kuten julkinen resolver, vastaa yhä pingiin, kun nimet epäonnistuvat, polku on ehjä ja ongelma on DNS:ssä. Se on tapaus, jossa resolverin muutos on perusteltu, ja tapaus, jossa se ei ole, käy myös ilmi. Jos myös numeerinen testi epäonnistuu, apuvirtuaalikone on menettänyt reittinsä, eikä mikään resolver-tiedosto korjaa sitä.

Reititystapausta varten poista tunnelisovittimen automaattinen metriikka ja anna sille WSL2:n linkkireittiä suurempi luku:

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

Sammuttaminen on tärkeää. Metriikan muutos ei kirjoita käynnissä olevaa apuvirtuaalikonetta uudelleen, joten jakelu on rakennettava uudelleen ennen kuin muutos näkyy.

Ota tiedosto haltuusi, tietoisesti

Jos reititys on oikein ja vain sisäiset nimet epäonnistuvat, syy on resolverissa ja voit pysäyttää generaattorin. Se on tietoinen muutos, jolla on ylläpitokustannus, ei kevyt kiertotie.

Luo jakelun sisällä /etc/wsl.conf verkkolohkolla, joka poistaa generoinnin käytöstä, ja kirjoita sitten resolver-tiedosto itse, yrityspalvelin ensin ja julkinen varavaihtoehto toiseksi:

[network]
generateResolvConf = false
search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

Järjestyksellä on väliä. Julkinen resolver ei voi vastata sisäiseen nimeen, ja varavaihtoehto on vain internet-hakuja varten. Kun tiedosto on sinun, mikään ei generoi sitä uudelleen, joten muuttava yrityspalvelin muuttuu katkokseksi, joka sinun on itse huomattava.

Tarkista nimet ja sitten paketit

Vahvista yksi sisäinen ja yksi julkinen nimi järjestelmän resolverilla ja toista sitten se toiminto, joka epäonnistui. Paketinhallintaohjelmat käyttävät joskus omaa resolveriaan, siksi toimiva getent voi olla olemassa rikkinäisen asennuksen rinnalla.

Jos automatisoit uudelleenkirjoituksen, tee siitä idempotentti: ilman tunnelia säilytä olemassa oleva tiedosto sen sijaan, että kirjoittaisit tyhjän palvelinluettelon.

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

Jakelun sisältä toimiva sisäinen haku ja toimiva julkinen haku on tulos, joka kannattaa kirjata. Vihreä VPN-kuvake isäntäkoneella ei todista kumpaakaan.

Aiheeseen liittyvät artikkelit