resolv.conf у WSL 2: DNS помирає, коли підключається 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 може вдало спрацювати проти кешованої або буквальної адреси. Потім повторіть після від’єднання й повторного підключення, бо налаштування, яке працює один раз і перегенеровується після відновлення, так і не було виправлено. Збережіть попередній вміст і занотуйте, який компонент володіє шляхом на цій машині, щоб наступна зміна починалася з доказів.