WSL2 го загуби DNS по поврзувањето со VPN? Две причини

Застарена resolver-датотека и конкурентна метрика на рута го даваат истиот симптом во WSL2. Запишете ги двете страни, потоа поправете ја онаа што навистина е расипана.

Ping по адреса работи во дистрибуцијата, инсталирањето пакети и 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-икона на домаќинот не докажува ниту едно од двете.

Поврзани статии