WSL2 nededia firemnú VPN, a práve v tom je chyba

Interná wiki sa načíta v Edge, ale git clone vnútri distribúcie skončí časovým limitom. Toto jediné pozorovanie sa zvyčajne číta ako «VPN blokuje WSL2» a nasledujúca hodina padne na úpravu /etc/resolv.conf. Užitočnejšie čítanie je, že WSL2 nikdy nemal sieťovú cestu hostiteľa: beží v pomocnom VM s vlastným adaptérom, vlastnými trasami a súborom resolvera, ktorý preň Windows generuje. Všetko ďalšie závisí od toho, ktoré z tých troch vám skutočne chýba.

VM má vlastný stack, metriky a resolver

V predvolenom režime NAT stojí distribúcia za virtuálnym prepínačom a na internet sa dostane cez hostiteľa, ale adaptéry hostiteľa nevidí. ip addr zobrazuje jedno rozhranie s privátnou adresou, ip route zobrazuje predvolenú trasu cez tento prepínač a /etc/resolv.conf je generovaný súbor ukazujúci na stub resolver, ktorý vybral Windows. Nič z toho sa nemení tým, že sa na strane Windows spustil klient VPN.

Preto «prehliadač funguje» dokazuje tak málo. Prehliadač používa stack hostiteľa, tunel a resolver politiku hostiteľa. Váš shell používa iný stack, ktorý náhodou zdieľa fyzickú sieťovú kartu. Zhodujú sa v šťastnom prípade a rozchádzajú sa presne vtedy, keď VPN nainštaluje filter, prepíše zoznam DNS alebo pridá trasu pre podsiet virtuálneho prepínača.

Dva testy rozhodnú, v ktorom svete ste, a musia sa spustiť vnútri distribúcie:

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

Keď mená zlyhávajú, ale doslovná adresa odpovedá, je to problém resolvera. Keď mená a adresy zlyhávajú spolu, je to problém cesty a žiadna úprava resolvera sa ho nedotkne. Nasledujú dôkazy zo strany Windows: Get-NetAdapter | Get-DnsClientServerAddress a route print -4 ukážu, či tunel zabral podsiet, v ktorej žije váš VM.

Prvý mýtus: firemné DNS servery to opravia

Úprava súboru resolvera je klasická rada a je správna asi v polovici prípadov. Keď je správna, je správna z konkrétneho dôvodu: generovaný súbor ukazuje na resolver, ktorý pozná len verejné mená, takže dopyt na intranet.example.internal sa vráti ako neexistujúci, aj keď je cesta v poriadku.

Pripnutie serverov VPN znamená zastaviť Windows v regenerácii súboru, pretože každý ručne napísaný súbor sa pri ďalšom štarte nahradí:

[network]
generateResolvConf = false

Uložte to ako /etc/wsl.conf, spustite wsl --shutdown z Windows, potom naštartujte distribúciu a napíšte /etc/resolv.conf so servermi tunela prvými a verejným resolverom len ako zálohou. Je to trvalá zmena s nákladmi na údržbu: súbor už nenasleduje hostiteľa, takže keď sa firemné adresy DNS zmenia, distribúcia sa naďalej pýta staré. Niekto musí ten súbor vlastniť.

Nič nerobí ani vtedy, keď je zlyhanie širšie. Ak curl na 1.1.1.1 vyprší, klient tunela filtruje virtuálny prepínač alebo smeruje podsiet VM do tunela a správny resolver vám dá len mená, na ktoré sa stále nedá dostať.

Druhý mýtus: zmena metriky vydrží

Keď sa mená prekladajú, ale prevádzka odchádza cez fyzický adaptér, pákou sú metriky rozhrania. Dajte adaptéru VPN vysokú cenu a prepínaču WSL nízku:

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

Potom pamätajte, že v mnohých zostaveniach klienta sa adaptér tunela znovu vytvára pri každom pripojení a metrika sa vracia na predvolenú hodnotu. Jednorazový príkaz je oprava, ktorá potichu vyprší, zvyčajne cez víkend, a tiket sa vráti s «minulý týždeň to fungovalo». Naplánovaná úloha spúšťaná udalosťou VPN alebo skript, ktorý používateľ spustí po pripojení, je čestná verzia tejto opravy.

Rovnaká expirácia platí pre trasy hostiteľa pridané pre jeden tvrdohlavý prefix. Ako diagnostika majú cenu, pretože povedia, či je problém jedna destinácia alebo celá cesta, ale nie sú architektúra.

Tretí mýtus: jedna oprava pokryje každé zostavenie Windows

wsl-vpnkit je vzor sidecar: malá distribúcia vlastní cestu na strane hostiteľa a preposiela za iné distribúcie cez virtuálny socket, takže prevádzka aplikácií prestane závisieť od filtrovaného prepínača. Potrebuje funkčnú štandardnú cestu, čo znamená odstrániť prepisy networkingMode a dnsTunneling z %UserProfile%\.wslconfig, obnoviť generateResolvConf = true v každej funkčnej distribúcii a spustiť službu pri prihlásení.

Zrkadlový režim je vstavaná alternatíva vo Windows 11 22H2 a novších a je to jedno nastavenie plus vypnutie:

[wsl2]
networkingMode=mirrored

Vnútri distribúcie ip addr potom vypíše adaptéry hostiteľa, tunel sa medzi nimi môže objaviť a DNS tunelovanie preposiela dopyty cez resolver Windows, aj keď klient prepíše zoznam DNS. Nie je univerzálne: niektoré filtračné ovládače zrkadlovú cestu stále zahadzujú a pravidlá firewallu Hyper-V môžu vyžadovať výslovné povolenie. Príručka sietí WSL od Microsoftu je stránka, ktorú treba porovnať so svojím zostavením pred použitím receptu napísaného pre novšie.

Po každej zmene otestujte tri veci

Vyberte jeden mechanizmus na stroj a zapíšte ho, pretože dva sa kombinujú zle. Sidecar nad zrkadlovým režimom zdvojnásobuje preposielanie a zrkadlový hostiteľ so zastaraným záznamom sidecar v .wslconfig zvyčajne zlyhá po aktualizácii, nie pred ňou.

Čokoľvek si vyberiete, akceptačný test sú tie isté tri požiadavky vnútri distribúcie: interné meno, verejné meno a surová adresa. Potom ich zopakujte po odpojení a opätovnom pripojení tunela a po wsl --shutdown. Ak zlyhá len interné meno, je to resolver politika; ak zlyhajú interné aj verejné meno spolu s fungujúcou adresou, je to stále resolver politika; ak zlyhá všetko, je to cesta.

Ak zlyhá jeden interný hostiteľ a ostatné fungujú, prestaňte sa pozerať na resolver a hľadajte chýbajúcu trasu pre ten prefix. Ak všetko funguje do ďalšieho opätovného pripojenia, našli ste opravu závislú od stavu pri behu a musí sa znova aplikovať automaticky alebo nahradiť jedným z dvoch mechanizmov vyššie.