WSL2 изгуби DNS след свързване с VPN? Две причини

Остарял resolver файл и конкурираща се метрика на маршрут дават същия симптом вътре в WSL2. Запишете двете страни, после поправете това, което наистина е счупено.

Ping по адрес работи вътре в дистрибуцията, инсталирането на пакети и git изтеглянията не, а отказът се появи веднага след вдигането на тунела. Спряха да се решават само имената, което сочи към DNS, а не към свързаност. Преинсталирането на пакети е най-популярният грешен първи ход тук. WSL2 има два независими начина да даде точно този симптом и те изискват различни поправки.

Защо дистрибуцията държи собствен resolver

DNS клиентът на Windows не се използва вътре в дистрибуцията. WSL2 изгражда свой собствен resolver файл при стартиране, сочещ към stub адрес, който Windows публикува на виртуалния комутатор за помощната виртуална машина.

Тази схема е стабилна при обикновени мрежови промени, защото се записва веднъж и се използва повторно. Схемата спира да е вярна, когато клиент на тунел презапише списъка с адаптери на хоста, след като помощната виртуална машина вече е стартирала.

Нищо вътре в дистрибуцията не следи за промяната, затова файлът продължава да сочи към адрес, който може вече да не е на пътя. Следващото търсене тогава чака, изтича по време или получава отговор от сървър, който никога не е чувал за вътрешната зона. Отвътре resolver просто спира да отговаря и всички имена се провалят наведнъж.

Първо съберете доказателства от двете страни

Запишете какво вижда дистрибуцията, после какво вижда Windows, преди да промените нещо. Именно двете гледни точки заедно различават режимите на отказ.

Вътре в дистрибуцията отпечатайте resolver файла, таблицата за маршрутизация и едно вътрешно и едно публично търсене:

ip -4 route
cat /etc/resolv.conf
getent hosts intranet.corp.example
getent hosts example.com

В Windows избройте DNS сървърите по адаптер и таблицата IPv4 с метрики. Клиентът на VPN обикновено инсталира маршрут за подмрежата на WSL2 и неговата метрика решава дали този трафик излиза през тунела, или остава локален.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Метрика на маршрут или остарял файл

Първият отказ е остарелият файл. Resolver беше записан за състоянието на адаптера при стартиране, а тунелът промени това състояние. Неговият stub адрес може вече да е недостъпен или да сочи към сървър, който не знае нищо за вътрешната зона.

Вторият е проблем с маршрутизацията. Когато VPN добави маршрут, покриващ подмрежата на WSL2, с метрика по-ниска от маршрута на връзката на хоста, пакетите, адресирани до помощната виртуална машина, влизат в тунела. Тогава изтича по време всяка услуга на WSL2, не само DNS.

Разграничаващият тест струва един ред. Ако цифров адрес като публичен resolver все още отговаря на ping, докато имената се провалят, пътят е цял и проблемът е в DNS. Това е случаят, в който промяна на resolver е оправдана, а случаят, в който не е, също става очевиден. Ако цифровият тест също се провали, помощната виртуална машина е загубила маршрута си и никакъв resolver файл няма да го поправи.

За случая с маршрутизация отхвърлете автоматичната метрика на адаптера на тунела и му дайте число над маршрута на връзката WSL2:

Get-NetAdapter | Where-Object InterfaceDescription -Match VPN | Set-NetIPInterface -InterfaceMetric 5500
wsl.exe --shutdown

Изключването има значение. Промяната на метриката не презаписва работещата помощна виртуална машина, затова дистрибуцията трябва да се изгради наново, преди промяната да стане видима.

Поемете файла, съзнателно

Ако маршрутизацията е вярна и се провалят само вътрешните имена, resolver е виновен и можете да спрете генератора. Това е съзнателна промяна с цена за поддръжка, а не заобиколно решение, което се прилага между другото.

Създайте /etc/wsl.conf вътре в дистрибуцията с мрежовата секция, която изключва генерирането, после напишете resolver файла сами, корпоративен сървър първо и публичен резервен второ:

[network]
generateResolvConf = false
search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

Редът има значение. Публичният resolver не може да отговори на вътрешно име, а резервният съществува само за интернет търсения. Щом файлът е ваш, нищо не го регенерира, затова корпоративен resolver, който се мести, се превръща в прекъсване, което сами трябва да забележите.

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

Проверете едно вътрешно и едно публично име със системния resolver, после повторете операцията, която се провали. Мениджърите на пакети понякога използват собствен resolver, затова работещ getent може да съществува при счупена инсталация.

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

getent hosts intranet.corp.example
resolvectl status | head -20
getent hosts example.com

Работещо вътрешно търсене и работещо публично търсене, отвътре в дистрибуцията, е резултатът, който си струва да се запише. Зелена икона на VPN на хоста не доказва нито едното.

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