WSL2 ne heredas la entreprenan VPN, kaj ĝuste tio estas la cimo

La interna vikio ŝarĝiĝas en Edge, dum git clone ene de la distribuaĵo finiĝas per tempolimo. Tiu sola observado kutime legiĝas kiel «la VPN blokas WSL2», kaj la sekva horo iras al redaktado de /etc/resolv.conf. La pli utila legado estas, ke WSL2 neniam havis la retan vojon de la gastiganto: ĝi funkcias en utila VM kun propra adaptilo, propraj itineroj kaj resolver-dosiero, kiun Windows generas por ĝi. Ĉio sekva dependas de tio, kiu el tiuj tri vere mankas al vi.

La VM havas sian propran stakon, metrikojn kaj resolveron

En la defaŭlta NAT-reĝimo, la distribuaĵo staras malantaŭ virtuala ŝaltilo kaj atingas la interreton tra la gastiganto, sed ĝi ne vidas la adaptilojn de la gastiganto. ip addr montras unu interfacon kun privata adreso, ip route montras defaŭltan itineron tra tiu ŝaltilo, kaj /etc/resolv.conf estas generita dosiero montranta al stub-resolver, kiun Windows elektis. Nenio el tio ŝanĝiĝas ĉar VPN-kliento ekfunkciis ĉe la Windows-flanko.

Tial «la retumilo funkcias» pruvas tiel malmulte. La retumilo uzas la stakon de la gastiganto, la tunelon kaj la resolver-politikon de la gastiganto. Via ŝelo uzas alian stakon, kiu hazarde dividas fizikan retkarton. Ili kongruas en la feliĉa kazo kaj diverĝas ĝuste kiam la VPN instalas filtrilon, reverkas la DNS-liston aŭ aldonas itineron por la subreto de la virtuala ŝaltilo.

Du testoj decidas, en kiu mondo vi estas, kaj ili devas kuri ene de la distribuaĵo:

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

Nomoj fiaskantaj dum laŭvorta adreso respondas estas resolver-problemo. Nomoj kaj adresoj fiaskantaj kune estas vojo-problemo, kaj nenia resolver-redaktado tuŝos ĝin. Sekve venas pruvoj de la Windows-flanko: Get-NetAdapter | Get-DnsClientServerAddress kaj route print -4 montras, ĉu la tunelo okupis la subreton, en kiu loĝas via VM.

Mito unu: la entreprenaj DNS-serviloj solvas ĝin

Redakti la resolver-dosieron estas la klasika konsilo, kaj ĝi pravas proksimume duonon de la tempo. Kiam ĝi pravas, ĝi pravas pro specifa kaŭzo: la generita dosiero montras al resolver, kiu konas nur publikajn nomojn, do peto pri intranet.example.internal revenas kiel neekzistanta eĉ kiam la vojo estas en ordo.

Fiksi la servilojn de la VPN signifas haltigi Windows de regeneri la dosieron, ĉar ajna dosiero, kiun vi skribas permane, estas anstataŭigata ĉe la sekva komenco:

[network]
generateResolvConf = false

Konservu tion kiel /etc/wsl.conf, rulu wsl --shutdown el Windows, poste startigu la distribuaĵon kaj skribu /etc/resolv.conf kun la serviloj de la tunelo unue kaj publika resolver nur kiel rezervo. Ĝi estas daŭra ŝanĝo kun prizorga kosto: la dosiero ne plu sekvas la gastiganton, do kiam la entreprenaj DNS-adresoj ŝanĝiĝas, la distribuaĵo daŭre demandas la malnovajn. Iu devas posedi tiun dosieron.

Ĝi ankaŭ faras nenion, kiam la fiasko estas pli vasta. Se curl al 1.1.1.1 finiĝas per tempolimo, la tunelkliento filtradas la virtualan ŝaltilon aŭ enkursigas la subreton de la VM en la tunelon, kaj ĝusta resolver simple donas al vi nomojn, kiujn ankoraŭ ne eblas atingi.

Mito du: la metrika ŝanĝo restas

Kiam nomoj solviĝas sed trafiko eliras tra la fizika adaptilo, la interfacaj metrikoj estas la levilo. Donu altan koston al la VPN-adaptilo kaj malaltan al la WSL-ŝaltilo:

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

Poste memoru, ke en multaj klientaj versioj la tunela adaptilo estas rekreiata ĉe ĉiu konekto kaj la metriko revenas al sia defaŭlto. Unufoja komando estas riparo, kiu silente eksvalidiĝas, kutime dum semajnfino, kaj la bileto revenas kun «ĝi funkciis pasintsemajne». Planita tasko ŝaltita de la VPN-evento, aŭ skripto, kiun la uzanto rulas post konekto, estas la honesta versio de tiu riparo.

La sama eksvalidiĝo validas por gastigantaj itineroj aldonitaj por unu obstina prefikso. Ili valoras kiel diagnozo, ĉar ili diras al vi, ĉu la problemo estas unu celloko aŭ la tuta vojo, sed ili ne estas arkitekturo.

Mito tri: unu riparo kovras ĉiun Windows-version

wsl-vpnkit estas la sidecar-ŝablono: malgranda distribuaĵo posedas la vojon ĉe la gastiganta flanko kaj plusendas por aliaj distribuaĵoj tra virtuala soketo, do apliktrafiko ĉesas dependi de la filtrita ŝaltilo. Ĝi bezonas, ke la norma vojo funkciu, kio signifas forigi la superregadojn networkingMode kaj dnsTunneling el %UserProfile%\.wslconfig, restarigi generateResolvConf = true en ĉiu funkcianta distribuaĵo kaj startigi la servon ĉe ensaluto.

La spegula reĝimo estas la enkonstruita alternativo en Windows 11 22H2 kaj pli novaj, kaj ĝi estas unu agordo plus malŝalto:

[wsl2]
networkingMode=mirrored

Ene de la distribuaĵo ip addr tiam listigas la adaptilojn de la gastiganto, la tunelo povas aperi inter ili, kaj DNS-tunelado plusendas serĉojn tra la Windows-resolver eĉ kiam la kliento reverkas la DNS-liston. Ĝi ne estas universala: iuj filtraj peliloj ankoraŭ forĵetas la spegulan vojon, kaj Hyper-V-fajroŝirmilaj reguloj povas bezoni eksplicitan permeson. La WSL-retgvidilo de Microsoft estas la paĝo, kiun kontroli kontraŭ via versio antaŭ ol apliki recepton skribitan por pli nova.

Testu tri aferojn post ĉiu ŝanĝo

Elektu unu mekanismon por maŝino kaj skribu ĝin, ĉar la du kombiniĝas malbone. Sidecar sur la spegula reĝimo duobligas la plusendadon, kaj spegula gastiganto kun malaktuala sidecar-enskribo en .wslconfig emas fiaski post ĝisdatigo, ne antaŭ ĝi.

Kion ajn vi elektis, la akcepta testo estas la samaj tri petoj ene de la distribuaĵo: interna nomo, publika nomo kaj kruda adreso. Poste ripetu ilin post malkonekto kaj rekonekto de la tunelo, kaj post wsl --shutdown. Nur la interna nomo fiaskanta signifas resolver-politikon; internaj kaj publikaj nomoj fiaskantaj kune kun funkcianta adreso ankoraŭ signifas resolver-politikon; ĉio fiaskanta signifas la vojon.

Se unu interna gastiganto fiaskas dum la resto funkcias, ĉesu rigardi la resolveron kaj serĉu mankantan itineron por tiu prefikso. Se ĉio funkcias ĝis la sekva rekonekto, vi trovis riparadon, kiu dependas de stata tempo de funkciado, kaj ĝi devas esti reaplikata aŭtomate aŭ anstataŭigata per unu el la du mekanismoj supre.