WSL2 ei peri yrityksen VPN:ää, ja juuri se on vika

Sisäinen wiki latautuu Edgessä, mutta git clone jakelun sisällä päättyy aikakatkaisuun. Tämä yksittäinen havainto luetaan yleensä muotoon «VPN estää WSL2:n», ja seuraava tunti menee /etc/resolv.conf-tiedoston muokkaamiseen. Hyödyllisempi luenta on, että WSL2:lla ei koskaan ollut isännän verkkopolkua: se toimii apu-VM:ssä, jolla on oma sovitin, omat reitit ja Windowsin sille luoma resolver-tiedosto. Kaikki seuraava riippuu siitä, mitä noista kolmesta teiltä todella puuttuu.

Apu-VM:llä on oma pino, mittarit ja resolver

Oletusarvoisessa NAT-tilassa jakelu istuu virtuaalikytkimen takana ja saavuttaa internetin isännän kautta, mutta ei näe isännän sovittimia. ip addr näyttää yhden liitännän yksityisellä osoitteella, ip route näyttää oletusreitin tuon kytkimen kautta, ja /etc/resolv.conf on luotu tiedosto, joka osoittaa Windowsin valitsemaan stub-resolveriin. Mikään tästä ei muutu siksi, että Windowsin puolella käynnistettiin VPN-asiakas.

Siksi «selain toimii» todistaa niin vähän. Selain käyttää isännän pinoa, tunnelia ja isännän resolver-käytäntöä. Kuoresi käyttää toista pinoa, joka sattuu jakamaan fyysisen verkkokortin. Ne ovat samaa mieltä onnellisessa tapauksessa ja eroavat juuri silloin, kun VPN asentaa suodattimen, kirjoittaa DNS-listan uudelleen tai lisää reitin virtuaalikytkimen aliverkkoon.

Kaksi testiä ratkaisee, missä maailmassa olet, ja ne on ajettava jakelun sisällä:

getent hosts example.com
curl -sS -m 8 -o /dev/null -w "%{http_code}\n" 1.1.1.1
ip route
cat /etc/resolv.conf

Nimien epäonnistuminen kirjaimellisen osoitteen vastatessa on resolver-ongelma. Nimien ja osoitteiden epäonnistuminen yhdessä on polkuongelma, eikä mikään resolverin muokkaus kosketa sitä. Seuraavaksi tulevat todisteet Windowsin puolelta: Get-NetAdapter | Get-DnsClientServerAddress ja route print -4 näyttävät, onko tunneli vallannut aliverkon, jossa VM:si elää.

Myytti yksi: yrityksen DNS-palvelimet korjaavat asian

Resolver-tiedoston muokkaaminen on klassinen neuvo, ja se on oikea noin puolet ajasta. Kun se on oikea, se on oikea tietystä syystä: luotu tiedosto osoittaa resolveriin, joka tuntee vain julkiset nimet, joten kysely intranet.example.internal:sta palaa olemattomana, vaikka polku on kunnossa.

VPN:n palvelimien kiinnittäminen tarkoittaa Windowsin estämistä luomasta tiedostoa uudelleen, koska mikä tahansa käsin kirjoitettu tiedosto korvataan seuraavalla käynnistyksellä:

[network]
generateResolvConf = false

Tallenna se nimellä /etc/wsl.conf, aja wsl --shutdown Windowsista, käynnistä sitten jakelu ja kirjoita /etc/resolv.conf niin, että tunnelin palvelimet ovat ensin ja julkinen resolver vain varana. Se on pysyvä muutos, jolla on ylläpitokustannus: tiedosto ei enää seuraa isäntää, joten kun yrityksen DNS-osoitteet muuttuvat, jakelu kysyy edelleen vanhoja. Jonkun on omistettava tuo tiedosto.

Se ei tee mitään myöskään silloin, kun vika on laajempi. Jos curl osoitteeseen 1.1.1.1 päättyy aikakatkaisuun, tunneliasiakas suodattaa virtuaalikytkintä tai reitittää VM:n aliverkon tunneliin, ja oikea resolver antaa vain nimiä, joihin ei vieläkään pääse.

Myytti kaksi: mittarin muutos pitää

Kun nimet ratkeavat mutta liikenne lähtee fyysisen sovittimen kautta, vipu on liitännän mittareissa. Anna VPN-sovittimelle korkea kustannus ja WSL-kytkimelle matala:

Get-NetAdapter | Where-Object InterfaceDescription -Match "AnyConnect" | Set-NetIPInterface -InterfaceMetric 4000
Get-NetIPInterface -InterfaceAlias "vEthernet (WSL)" | Set-NetIPInterface -InterfaceMetric 1

Muista sitten, että monissa asiakasversioissa tunnelisovitin luodaan uudelleen joka yhteydellä ja mittari palaa oletukseensa. Kertaluonteinen komento on korjaus, joka vanhenee hiljaa, yleensä viikonlopun aikana, ja tiketti palaa sanoilla «viime viikolla se toimi». VPN-tapahtuman käynnistämä ajastettu tehtävä tai komentosarja, jonka käyttäjä ajaa yhteyden jälkeen, on tämän korjauksen rehellinen versio.

Sama vanheneminen koskee isännän reittejä, jotka lisättiin yhden itsepäisen etuliitteen vuoksi. Ne ovat arvokkaita diagnoosina, koska ne kertovat, onko ongelma yksi kohde vai koko polku, mutta ne eivät ole arkkitehtuuri.

Myytti kolme: yksi korjaus kattaa jokaisen Windows-version

wsl-vpnkit on sidecar-kaava: pieni jakelu omistaa isännän puolen polun ja välittää muille jakeluille virtuaalisen pistokkeen kautta, joten sovellusliikenne lakkaa riippumasta suodatetusta kytkimestä. Se tarvitsee toimivan vakiopolun, eli networkingMode- ja dnsTunneling-ohitukset on poistettava tiedostosta %UserProfile%\.wslconfig, generateResolvConf = true on palautettava jokaiseen toimivaan jakeluun ja palvelu on käynnistettävä kirjautuessa.

Peilattu tila on sisäänrakennettu vaihtoehto Windows 11 22H2:ssa ja uudemmissa, ja se on yksi asetus plus sammutus:

[wsl2]
networkingMode=mirrored

Jakelun sisällä ip addr luettelee silloin isännän sovittimet, tunneli voi näkyä niiden joukossa, ja DNS-tunnelointi välittää haut Windowsin resolverin kautta vaikka asiakas kirjoittaisi DNS-listan uudelleen. Se ei ole yleispätevä: jotkin suodatinajurit pudottavat peilatun polun edelleen, ja Hyper-V-palomuurin säännöt voivat vaatia nimenomaisen luvan. Microsoftin WSL-verkko-opas on sivu, joka kannattaa tarkistaa omaa versiota vasten ennen uudemmalle kirjoitetun reseptin soveltamista.

Testaa kolme asiaa jokaisen muutoksen jälkeen

Valitse yksi mekanismi konetta kohden ja kirjoita se muistiin, koska kaksi yhdistyvät huonosti. Sidecar peilatun tilan päällä kaksinkertaistaa välityksen, ja peilattu isäntä, jolla on vanhentunut sidecar-merkintä tiedostossa .wslconfig, tapaa epäonnistua päivityksen jälkeen eikä ennen sitä.

Minkä tahansa valitsitkin, hyväksymistesti on samat kolme pyyntöä jakelun sisällä: sisäinen nimi, julkinen nimi ja raaka osoite. Toista ne sitten tunnelin irrottamisen ja uudelleenyhdistämisen jälkeen sekä wsl --shutdown:n jälkeen. Jos vain sisäinen nimi epäonnistuu, kyse on resolver-käytännöstä; jos sisäinen ja julkinen nimi epäonnistuvat yhdessä toimivan osoitteen kanssa, kyse on edelleen resolver-käytännöstä; jos kaikki epäonnistuu, kyse on polusta.

Jos yksi sisäinen isäntä epäonnistuu muiden toimiessa, lopeta resolverin tuijottaminen ja etsi puuttuva reitti tuolle etuliitteelle. Jos kaikki toimii seuraavaan uudelleenyhdistämiseen asti, olet löytänyt korjauksen, joka riippuu ajonaikaisesta tilasta, ja se on sovellettava automaattisesti uudelleen tai korvattava jommallakummalla yllä olevista mekanismeista.