Почему 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'

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