Защо WSL губи името на работния хост, когато се свърже VPN?

Windows разрешава вътрешното име на хоста без оплаквания, а същото име се проваля в WSL в момента, в който тунелът се вдигне. Обичайното решение е да се запише публичен резолвер в дистрибуцията, което възстановява нормалното сърфиране и прави името на работния хост неразрешимо. Така се разменя един отказ за друг и се скрива слоят, който всъщност се е счупил. Преди да добавите или премахнете който и да е ред за резолвер, установете кой от трите слоя се проваля.

Първо изключете проблем с маршрутизацията

Заявете идентичното напълно квалифицирано име от двете страни, а не две имена, които си приличат. Успех в Windows и отказ в WSL за същия низ е отпечатъкът на два пътя за разрешаване и малко друго дава тази картина толкова чисто. Ако WSL също не може да достигне услугата на известния ѝ числов адрес, има и проблем с маршрутизацията или филтрирането. В такъв случай работата по DNS няма да го разкрие и следобедът отива в грешния слой.

Три симптома покриват повечето от тези случаи и всеки сочи към различно място. Прочетете съответстващия ред, преди да отворите конфигурационен файл:

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

Тунелирането на DNS има долна граница на версията

Microsoft документира мрежов режим на WSL, който тунелира DNS заявки до резолвера на Windows през канал за виртуализация. В поддържаните сборки на Windows 11 той е включен по подразбиране и затова две машини в една и съща корпоративна мрежа се държат различно. Променливата е номерът на сборката, не корпоративната политика.

Ръководството за мрежи на WSL описва този режим и версиите, които го поддържат. Функцията е важна, защото корпоративната политика за DNS обикновено живее в резолвера на Windows и дистрибуция, която наследява пътя на Windows, наследява и политиката. Дистрибуция, която пита публичен резолвер, няма маршрут до частно име, колкото и спретната да изглежда собствената ѝ конфигурация. Този механизъм обяснява целия симптом и обяснява защо заобиколното решение с публичен резолвер се проваля.

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

Старите замени надживяват проблема, който са решили

По-стари рецепти изключваха генерираните файлове за резолвер, твърдо задаваха сървър за имена или заключваха файла с атрибут за неизменност. Тези промени остават на място дълго след като проблемът със свързаността, който ги е предизвикал, е изчезнал, и обикновено те са причината по-нова настройка да изглежда, че не прави нищо. Те също преживяват преинсталиране на дистрибуцията под формата на профил за shell, който пренаписва файла при всяко влизане. Последното се намира най-трудно, защото е невидимо от файла, който всички преглеждат.

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

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

Два файла, две различни роли

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

За инсталация, която поддържа функцията, фрагментът от страна на Windows е кратък. Това е цялата промяна от тази страна:

[wsl2]
dnsTunneling=true

Този фрагмент принадлежи в потребителския профил на Windows и се отнася за виртуалната машина, а не за отделна дистрибуция. Тунелирането също изисква дистрибуцията да не е изключила генерирането на резолвер, така че файлът от страна на дистрибуцията трябва да остави това поведение на мира. Променете едното без другото и режимът тихо не прави нищо, което е най-честият начин тази поправка да бъде докладвана като счупена. Проверете и двата файла в една сесия, защото две редакции, направени седмици една от друга, са две редакции, които никой не може да припише.

Рестартирайте, после питайте от двете страни

Тези настройки се четат при стартиране на средата, така че нов shell в работеща дистрибуция няма да ги презареди. Изключете средата, вместо да рестартирате shell, и първо запазете работещата работа, защото всяка дистрибуция спира с нея. Само това пропускане обяснява повечето доклади за промяна без ефект.

След това задайте същия въпрос от двете страни. Изходът също показва с кой резолвер дистрибуцията в действителност е останала:

wsl.exe --shutdown
wsl.exe -e sh -c 'cat /etc/resolv.conf'
wsl.exe -e sh -c 'getent hosts files.corp.example'
wsl.exe -e powershell -Command 'Resolve-DnsName files.corp.example'

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