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 на хосце не даказвае ні таго, ні другога.

Падобныя артыкулы