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

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