resolv.conf в WSL 2: DNS умира, когато VPN се свърже

WSL пресъздава resolv.conf от Windows адаптерите, които вижда, така че резолверът на VPN може никога да не пристигне. Спрете генерирането, после проверете корпоративно име.

Сърфирането в дистрибуцията работи, а първото вътрешно име на хост се проваля в момента, в който тунелът се вдигне. Рефлексът е да се добави публичен резолвер, което връща интернета и прави корпоративното име недостъпно до края на деня. В WSL 2 /etc/resolv.conf е генериран изход, а не конфигурация, и точно този механизъм си струва да се разбере. Поправката не е по-добър резолвер, а собственост върху файла.

Файлът се генерира, а не се конфигурира

WSL 2 записва файла при стартиране от Windows адаптерите, които вижда в този момент, и отпечатва коментар в началото, който го казва. Когато VPN клиент добави или презапише адаптер след това, дистрибуцията не е задължително да прегенерира нещо и файлът продължава да описва мрежа, която вече не съществува.

Втори режим на отказ е по-тих: WSL може да копира сървъри само от някои адаптери. Ако физическият адаптер вече има IPv6 резолвер, IPv4 сървърите, които доставя VPN адаптерът, може да бъдат изхвърлени вместо добавени, и файлът изглежда пълен, докато пропуска точно този, който отговаря за вътрешните имена.

Сравнете изгледа от Windows с изгледа от Linux

Прочетете двете страни преди редакция. В дистрибуцията вижте какво съдържа файлът и дали е обикновен файл или връзка. В Windows изброите резолвера за всеки адаптер, включително този, който VPN е създал:

ls -l /etc/resolv.conf
cat /etc/resolv.conf
Get-DnsClientServerAddress -AddressFamily IPv4
Get-NetAdapter | Where-Object Status -eq 'Up'

Когато VPN адаптерът показва корпоративните сървъри, а Linux показва нещо друго, разминаването е в генерирането, а не в достъпността. Сравнете списъка с адаптери заедно с адресите, защото липсващ адаптер обяснява липсващ сървър. Това разграничение решава дали поправяте WSL, или защитна стена, и двете нямат нищо общо.

Изключете генерирането и напишете свой файл

Една документирана настройка спира WSL да презаписва файла и тя се намира в /etc/wsl.conf. Добавете секция за мрежа в този файл:

[network]
generateResolvConf = false

След това прекратете дистрибуцията от Windows с wsl --shutdown и я стартирайте отново. Ако пътят е символна връзка, а не обикновен файл, премахнете връзката преди да напишете собственото си съдържание, защото записът през връзката може да пресъздаде генерираната цел при следващия старт. От този момент файлът е ваш и нищо не го презаписва.

nameserver 172.28.4.10
nameserver 172.28.4.11
search site.corp.example
options timeout:1 attempts:2 rotate

Без домейн за търсене, неквалифицирано име на хост се допълва с публичния корен и се връща като „няма такъв домейн“. timeout спира мъртъв първи сървър да блокира всяка заявка, attempts ограничава колко опита харчи една заявка, а rotate разпределя повторенията вместо винаги да започва отгоре. Компромисът е, че файлът вече не следва VPN, чийто адрес на резолвера се мени между сесиите.

Справете се с резолвер, който се мести, после проверете

Някои клиенти дават резолвер, специфичен за сесията, така че статичен файл се чупи при следващата връзка. Два подхода са защитими. Пишете файла от малък скрипт, когато адресът се промени, или оставете генерирането включено и се уверете, че адаптерът, от който WSL копира, носи корпоративния сървър. Вторият не изисква кука и се проваля, когато генерирането пропусне VPN адаптера; и двата все още изискват конфликтът с IPv6 да бъде решен първо.

Windows прилага и свои политики за имена, като списък за търсене на суфикси или политика за резолюция за конкретни домейни, и копирането на адреси на адаптери не възпроизвежда тези правила. Ако име се резолвва в Windows, но не в дистрибуцията със същия сървър, сравнете обработката на суфиксите, преди да обвинявате тунела.

Тествайте с име, а не с пакет: getent hosts sensor-access0.corp.example минава през стека на резолвера, докато ping може да успее срещу кеширан или буквален адрес. После повторете след прекъсване и повторно свързване, защото настройка, която работи веднъж и се прегенерира при възобновяване, никога не е била поправена. Запазете предишното съдържание и отбележете кой компонент притежава пътя на тази машина, така че следващата промяна да започне с доказателства.

Подобни статии