WSL2 nu moștenește VPN-ul corporativ, și exact asta este eroarea

Wiki-ul intern se încarcă în Edge, în timp ce git clone din interiorul distribuției expiră. Această singură observație este citită de obicei ca «VPN-ul blochează WSL2», iar următoarea oră se duce pe editarea /etc/resolv.conf. Citirea mai utilă este că WSL2 nu a avut niciodată calea de rețea a gazdei: rulează într-o VM auxiliară cu propriul adaptor, propriile rute și un fișier resolver pe care Windows îl generează pentru el. Tot ce urmează depinde de care dintre cele trei vă lipsește de fapt.

VM-ul are propria stivă, metrici și resolver

În modul NAT implicit, distribuția stă în spatele unui switch virtual și ajunge la internet prin gazdă, dar nu vede adaptoarele acesteia. ip addr arată o interfață cu adresă privată, ip route arată o rută implicită prin acel switch, iar /etc/resolv.conf este un fișier generat care indică un stub resolver ales de Windows. Nimic din toate acestea nu se schimbă pentru că un client VPN a pornit pe partea Windows.

De aceea «browserul funcționează» dovedește atât de puțin. Browserul folosește stiva gazdei, tunelul și politica de resolver a gazdei. Shell-ul dvs. folosește altă stivă care împarte din întâmplare o placă de rețea fizică. Ele sunt de acord în cazul fericit și diverg exact când VPN-ul instalează un filtru, rescrie lista DNS sau adaugă o rută pentru subrețeaua switch-ului virtual.

Două teste decid în ce lume sunteți, și ele trebuie să ruleze în interiorul distribuției:

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

Numele eșuează în timp ce o adresă literală răspunde este o problemă de resolver. Numele și adresele eșuează împreună este o problemă de cale, și nicio editare a resolverului nu o va atinge. Urmează dovezile din partea Windows: Get-NetAdapter | Get-DnsClientServerAddress și route print -4 arată dacă tunelul a revendicat subrețeaua în care trăiește VM-ul dvs.

Primul mit: serverele DNS corporative o rezolvă

Editarea fișierului resolver este sfatul clasic și este corect cam jumătate din timp. Când este corect, este corect dintr-un motiv concret: fișierul generat indică un resolver care cunoaște doar nume publice, așa că o interogare pentru intranet.example.internal revine ca inexistentă chiar dacă calea este în regulă.

Fixarea serverelor VPN înseamnă oprirea Windows de la regenerarea fișierului, pentru că orice fișier scris manual este înlocuit la următoarea pornire:

[network]
generateResolvConf = false

Salvați asta ca /etc/wsl.conf, rulați wsl --shutdown din Windows, apoi porniți distribuția și scrieți /etc/resolv.conf cu serverele tunelului primele și un resolver public doar ca rezervă. Este o schimbare durabilă cu cost de întreținere: fișierul nu mai urmează gazda, așa că atunci când adresele DNS corporative se schimbă distribuția continuă să le întrebe pe cele vechi. Cineva trebuie să dețină acel fișier.

Nu face nimic nici când eșecul este mai larg. Dacă curl către 1.1.1.1 expiră, clientul tunelului filtrează switch-ul virtual sau rutează subrețeaua VM-ului în tunel, iar un resolver corect vă dă doar nume care tot nu pot fi atinse.

Al doilea mit: schimbarea metricii rezistă

Când numele se rezolvă dar traficul iese prin adaptorul fizic, pârghia sunt metricile interfeței. Dați cost mare adaptorului VPN și cost mic switch-ului WSL:

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

Apoi țineți minte că în multe versiuni ale clientului adaptorul tunelului este recreat la fiecare conectare și metrica revine la valoarea implicită. O comandă unică este o reparație care expiră în tăcere, de obicei peste un weekend, iar tichetul revine cu «săptămâna trecută funcționa». O sarcină programată declanșată de evenimentul VPN, sau un script pe care utilizatorul îl rulează după conectare, este versiunea onestă a acestei reparații.

Aceeași expirare se aplică rutelor de gazdă adăugate pentru un prefix încăpățânat. Merită ca diagnostic, pentru că spun dacă problema este o destinație sau întreaga cale, dar nu sunt arhitectură.

Al treilea mit: o reparație acoperă orice versiune Windows

wsl-vpnkit este modelul sidecar: o distribuție mică deține calea pe partea gazdei și redirecționează pentru alte distribuții printr-un socket virtual, astfel încât traficul aplicațiilor nu mai depinde de switch-ul filtrat. Are nevoie ca calea standard să funcționeze, adică să eliminați suprascrierile networkingMode și dnsTunneling din %UserProfile%\.wslconfig, să restaurați generateResolvConf = true în fiecare distribuție funcțională și să porniți serviciul la autentificare.

Modul oglindă este alternativa integrată în Windows 11 22H2 și versiunile mai noi, și este o setare plus o oprire:

[wsl2]
networkingMode=mirrored

În interiorul distribuției ip addr listează apoi adaptoarele gazdei, tunelul poate apărea printre ele, iar tunelarea DNS redirecționează interogările prin resolverul Windows chiar și când clientul rescrie lista DNS. Nu este universal: unii driveri de filtru încă renunță la calea oglindă, iar regulile de firewall Hyper-V pot avea nevoie de o permisiune explicită. Ghidul de rețea WSL al Microsoft este pagina pe care ar trebui să o comparați cu versiunea dvs. înainte de a aplica o rețetă scrisă pentru una mai nouă.

Testați trei lucruri după fiecare schimbare

Alegeți un mecanism pe mașină și notați-l, pentru că cele două se combină prost. Un sidecar peste modul oglindă dublează redirecționarea, iar o gazdă oglindă cu o intrare sidecar învechită în .wslconfig tinde să eșueze după o actualizare, nu înainte.

Orice ați alege, testul de acceptare sunt aceleași trei cereri în interiorul distribuției: un nume intern, un nume public și o adresă brută. Apoi repetați-le după deconectarea și reconectarea tunelului, și după wsl --shutdown. Doar numele intern eșuează înseamnă politică de resolver; numele intern și cel public eșuează împreună cu o adresă funcțională înseamnă tot politică de resolver; totul eșuează înseamnă calea.

Dacă o gazdă internă eșuează în timp ce restul funcționează, opriți-vă din a privi resolverul și căutați o rută lipsă pentru acel prefix. Dacă totul funcționează până la următoarea reconectare, ați găsit o reparație care depinde de starea la execuție, iar ea trebuie reaplicată automat sau înlocuită cu unul dintre cele două mecanisme de mai sus.