Зошто 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'

Првата команда ја завршува околината, втората покажува кој резолвер дистрибуцијата го користи сега, а последните две го поставуваат истото прашање на секоја страна. Споредете ги одговорите, а не состојбата на поставката. Барање што сѐ уште не успева по чисто рестартирање со двете датотеки точни покажува на корпоративната политика за резолвер, и тој разговор има друг сопственик.