Чаму 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'

Першая каманда завяршае асяроддзе, другая паказвае, які рэзалвер дыстрыбутыў цяпер выкарыстоўвае, а апошнія дзве ставяць тое самае пытанне кожнаму боку. Параўноўвайце адказы, а не стан налады. Запыт, які ўсё яшчэ падае пасля чыстага перазапуску пры правільных абодвух файлах, паказвае на карпаратыўную палітыку рэзалвера, і ў гэтай размовы іншы ўладальнік.