WSL2 не наслеђује корпоративни VPN и управо је то грешка

Интерни вики се учитава у Edge-у, а git clone унутар дистрибуције истиче. То једно запажање обично се чита као «VPN блокира WSL2», и следећи сат одлази на уређивање /etc/resolv.conf. Корисније читање је да WSL2 никада није имао мрежну путању домаћина: ради у помоћној VM са сопственим адаптером, сопственим рутама и датотеком resolver-а коју Windows генерише за њега. Све што следи зависи од тога које од тих три ствари вам заиста недостаје.

VM има сопствени стек, метрике и resolver

У подразумеваном NAT режиму, дистрибуција стоји иза виртуелног прекидача и долази до интернета преко домаћина, али не види његове адаптере. ip addr приказује један интерфејс са приватном адресом, ip route приказује подразумевану руту кроз тај прекидач, а /etc/resolv.conf је генерисана датотека која показује на stub resolver који је Windows изабрао. Ништа од тога се не мења зато што је на страни Windows-а покренут VPN клијент.

Зато «прегледач ради» доказује тако мало. Прегледач користи стек домаћина, тунел и resolver политику домаћина. Ваша љуска користи други стек који случајно дели физичку мрежну картицу. Они се слажу у срећном случају и разилазе се тачно када VPN инсталира филтер, препише DNS листу или дода руту за подмрежу виртуелног прекидача.

Два теста одлучују у ком свету сте, и морају се извршити унутар дистрибуције:

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

Неуспех имена док буквална адреса одговара је проблем resolver-а. Неуспех имена и адреса заједно је проблем путање, и никакво уређивање resolver-а га неће дотаћи. Затим следе докази са стране Windows-а: Get-NetAdapter | Get-DnsClientServerAddress и route print -4 показују да ли је тунел заузео подмрежу у којој живи ваша VM.

Први мит: корпоративни DNS сервери то решавају

Уређивање датотеке resolver-а је класичан савет и тачан је око половине времена. Када је тачан, тачан је из конкретног разлога: генерисана датотека показује на resolver који зна само јавна имена, па се упит за intranet.example.internal враћа као непостојећи иако је путања у реду.

Закачињање сервера VPN-а значи зауставити Windows да поново генерише датотеку, јер се свака ручно написана датотека замењује при следећем покретању:

[network]
generateResolvConf = false

Сачувајте то као /etc/wsl.conf, извршите wsl --shutdown из Windows-а, затим покрените дистрибуцију и напишите /etc/resolv.conf са серверима тунела првим и јавним resolver-ом само као резервом. То је трајна промена са трошком одржавања: датотека више не прати домаћина, па када се корпоративне DNS адресе промене дистрибуција наставља да пита старе. Неко мора да буде власник те датотеке.

Такође не ради ништа када је квар шири. Ако curl до 1.1.1.1 истекне, клијент тунела филтрира виртуелни прекидач или усмерава подмрежу VM-а у тунел, и исправан resolver вам даје само имена до којих се још не може стићи.

Други мит: промена метрике остаје

Када се имена решавају али саобраћај излази преко физичког адаптера, полуга су метрике интерфејса. Дајте VPN адаптеру високу цену а WSL прекидачу ниску:

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

Затим запамтите да се у многим верзијама клијента адаптер тунела поново ствара при сваком повезивању и метрика се враћа на подразумевану. Једнократна команда је поправка која тихо истиче, обично током викенда, и тикет се враћа са «прошле недеље је радило». Заказани задатак који покреће догађај VPN-а, или скрипта коју корисник покрене после повезивања, је поштена верзија ове поправке.

Исти рок важи за руте домаћина додате за један тврдоглав префикс. Вредне су као дијагностика, јер кажу да ли је проблем једна дестинација или цела путања, али нису архитектура.

Трећи мит: једна поправка покрива сваку верзију Windows-а

wsl-vpnkit је sidecar образац: мала дистрибуција поседује путању на страни домаћина и прослеђује за друге дистрибуције преко виртуелног сокета, па саобраћај апликација престаје да зависи од филтрираног прекидача. Потребно је да стандардна путања ради, што значи уклонити преписивања networkingMode и dnsTunneling из %UserProfile%\.wslconfig, вратити generateResolvConf = true у свакој радној дистрибуцији и покренути услугу при пријави.

Огледални режим је уграђена алтернатива у Windows-у 11 22H2 и новијем, и то је једно подешавање плус искључивање:

[wsl2]
networkingMode=mirrored

Унутар дистрибуције ip addr затим наводи адаптере домаћина, тунел се може појавити међу њима, и DNS тунелирање прослеђује упите кроз Windows resolver чак и када клијент препише DNS листу. Није универзално: неки драјвери за филтрирање још увек одбацују огледалну путању, а Hyper-V правила заштитног зида могу захтевати изричиту дозволу. Водич за WSL мреже компаније Microsoft је страница коју треба упоредити са својом верзијом пре примене рецепта написаног за новију.

После сваке промене тестирајте три ствари

Изаберите један механизам по машини и запишите га, јер се два лоше комбинују. Sidecar изнад огледалног режима удвостручује прослеђивање, а огледални домаћин са застарелим sidecar записом у .wslconfig обично пада после надоградње, а не пре ње.

Шта год изабрали, тест прихватања су иста три захтева унутар дистрибуције: интерно име, јавно име и сирова адреса. Затим их поновите после искључивања и поновног повезивања тунела, и после wsl --shutdown. Ако пада само интерно име, то је resolver политика; ако интерно и јавно име падају заједно са радном адресом, то је још увек resolver политика; ако пада све, то је путања.

Ако један интерни домаћин пада док остали раде, престаните да гледате у resolver и потражите руту која недостаје за тај префикс. Ако све ради до следећег поновног повезивања, нашли сте поправку која зависи од стања у време извршавања, и она мора аутоматски поново да се примени или да се замени једним од два механизма горе.