WSL2 потерял DNS после подключения VPN? Две причины

Устаревший файл resolver и конкурирующая метрика маршрута дают одинаковый симптом внутри WSL2. Зафиксируйте обе стороны, а затем исправьте ту, что действительно сломана.

Пинг по адресу работает внутри дистрибутива, установка пакетов и загрузки git нет, а сбой появился сразу после поднятия туннеля. Перестали разрешаться только имена, что указывает на DNS, а не на связность. Переустановка пакетов самый популярный неверный первый шаг здесь. У WSL2 есть два независимых способа дать ровно такой симптом, и они требуют разных исправлений.

Почему дистрибутив держит собственный resolver

DNS-клиент Windows не используется внутри дистрибутива. WSL2 при запуске собирает собственный файл resolver, указывающий на stub-адрес, который Windows публикует на виртуальном коммутаторе для вспомогательной виртуальной машины.

Эта схема стабильна при обычных изменениях сети, потому что записывается один раз и используется повторно. Схема перестаёт быть верной, когда клиент туннеля перезаписывает список адаптеров хоста после того, как вспомогательная виртуальная машина уже запущена.

Ничто внутри дистрибутива не следит за изменением, поэтому файл продолжает указывать на адрес, которого может уже не быть на пути. Следующий запрос тогда ждёт, завершается по таймауту или получает ответ от сервера, который никогда не слышал о внутренней зоне. Изнутри resolver просто перестаёт отвечать, и все имена падают одновременно.

Сначала соберите доказательства с обеих сторон

Зафиксируйте, что видит дистрибутив, а затем что видит Windows, прежде чем менять любое из этого. Именно два вида вместе различают режимы отказа.

Внутри дистрибутива выведите файл resolver, таблицу маршрутизации и один внутренний и один публичный запрос:

ip -4 route
cat /etc/resolv.conf
getent hosts intranet.corp.example
getent hosts example.com

В Windows перечислите DNS-серверы по адаптерам и таблицу IPv4 с метриками. Клиент VPN обычно устанавливает маршрут для подсети WSL2, и его метрика решает, уйдёт ли этот трафик через туннель или останется локальным.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Метрика маршрута или устаревший файл

Первый сбой устаревший файл. Resolver был написан для состояния адаптера при запуске, а туннель это состояние изменил. Его stub-адрес теперь может быть недоступен или указывать на сервер, который ничего не знает о внутренней зоне.

Второй проблема маршрутизации. Когда VPN добавляет маршрут, покрывающий подсеть WSL2, с метрикой ниже маршрута связи хоста, пакеты, адресованные вспомогательной виртуальной машине, попадают в туннель. Тогда истекает время ожидания у каждой службы WSL2, а не только у DNS.

Различающий тест стоит одной строки. Если числовой адрес, например публичный resolver, всё ещё отвечает на ping, пока имена падают, путь цел и проблема в DNS. Это тот случай, когда изменение resolver оправдано, и случай, когда нет, тоже становится очевидным. Если числовой тест тоже не проходит, вспомогательная виртуальная машина потеряла маршрут, и никакой файл resolver это не исправит.

Для случая маршрутизации снимите автоматическую метрику с адаптера туннеля и задайте ему число выше маршрута связи WSL2:

Get-NetAdapter | Where-Object InterfaceDescription -Match VPN | Set-NetIPInterface -InterfaceMetric 5500
wsl.exe --shutdown

Выключение важно. Изменение метрики не перезаписывает работающую вспомогательную виртуальную машину, поэтому дистрибутив нужно пересобрать, прежде чем изменение станет видимым.

Возьмите файл на себя, осознанно

Если маршрутизация верна и падают только внутренние имена, виноват resolver, и вы можете остановить генератор. Это осознанное изменение с затратами на обслуживание, а не обходной путь, который применяют небрежно.

Создайте /etc/wsl.conf внутри дистрибутива с сетевой секцией, отключающей генерацию, затем сами напишите файл resolver: сначала корпоративный сервер, затем публичный резервный:

[network]
generateResolvConf = false
search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

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

Проверьте имена, затем пакеты

Проверьте одно внутреннее и одно публичное имя системным resolver, затем повторите операцию, которая не прошла. Менеджеры пакетов иногда используют собственный resolver, поэтому работающий getent может сосуществовать со сломанной установкой.

Если вы автоматизируете перезапись, сделайте её идемпотентной: без туннеля сохраняйте существующий файл вместо записи пустого списка серверов.

getent hosts intranet.corp.example
resolvectl status | head -20
getent hosts example.com

Работающий внутренний запрос и работающий публичный запрос изнутри дистрибутива это результат, который стоит зафиксировать. Зелёный значок VPN на хосте не доказывает ни того, ни другого.

Похожие статьи