WSL2 не наследява корпоративния VPN и точно това е грешката

WSL2 работи в собствена виртуална мрежа и никога не наследява VPN стека на хоста. Разделете отказите на имена от отказите на пътя, преди изобщо да редактирате resolv.conf.

Вътрешното уики се зарежда в Edge, а git clone вътре в дистрибуцията изтича по време. Това единствено наблюдение обикновено се чете като «VPN блокира WSL2» и следващият час отива в редактиране на /etc/resolv.conf. По-полезното четене е, че WSL2 никога не е имал мрежовия път на хоста: той работи в помощна виртуална машина със собствен адаптер, собствени маршрути и файл с resolver, който Windows генерира за него. Всичко следващо зависи от това кое от тези три всъщност ви липсва.

Виртуалната машина има свой стек, метрика и 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 показват дали тунелът е заел подмрежата, в която живее вашата виртуална машина.

Мит първи: корпоративните 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 изтече по време, клиентът на тунела филтрира виртуалния суич или насочва подмрежата на виртуалната машина в тунела и правилният 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

ApproachWhat it actually does
Resolver pinFixes private names only; no effect on path failures
Sidecar distributionForwards traffic over a socket to a helper VM, so the switch's filter no longer matters
Mirrored networkingGives the distribution the host's interface set; also enables DNS tunnelling

wsl-vpnkit е моделът sidecar: малка дистрибуция притежава пътя от страната на хоста и препраща за други дистрибуции през виртуален сокет, така че трафикът на приложенията спира да зависи от филтрирания суич. Нужен е стандартният път да работи, което означава премахване на настройките networkingMode и dnsTunneling от %UserProfile%\.wslconfig, възстановяване на generateResolvConf = true във всяка работеща дистрибуция и стартиране на услугата при вход.

Огледалният режим е вградената алтернатива в Windows 11 22H2 и по-нови и представлява една настройка плюс изключване:

[wsl2]
networkingMode=mirrored

Вътре в дистрибуцията ip addr тогава изброява адаптерите на хоста, тунелът може да се появи сред тях, а DNS тунелирането препраща заявките през resolver на Windows дори когато клиентът пренапише DNS списъка. Това не е универсално: някои филтриращи драйвери все още изхвърлят огледалния път, а правилата на защитната стена на Hyper-V може да се нуждаят от изрично разрешение. Ръководството за мрежи на WSL на Microsoft е страницата, с която да сверявате своята версия, преди да приложите рецепта, написана за по-нова.

Тествайте три неща след всяка промяна

Изберете един механизъм на машина и го запишете, защото двете се комбинират лошо. Sidecar върху огледалния режим удвоява препращането, а огледален хост със застоял sidecar запис в .wslconfig е склонен да се провали след надграждане, а не преди него.

Каквото и да изберете, приемният тест е същите три заявки вътре в дистрибуцията: вътрешно име, публично име и суров адрес. После ги повторете след изключване и повторно свързване на тунела и след wsl --shutdown. Ако само вътрешното име се проваля, това е resolver политика; ако вътрешното и публичното име се провалят заедно при работещ адрес, това все още е resolver политика; ако всичко се проваля, това е пътят.

Ако един вътрешен хост се проваля, докато останалите работят, спрете да гледате resolver и потърсете липсващ маршрут за този префикс. Ако всичко работи до следващото повторно свързване, намерили сте поправка, която зависи от състояние по време на изпълнение, и тя трябва да се прилага автоматично или да се замени с един от двата механизма по-горе.

Подобни статии