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

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