VPN ulangandan keyin WSL2 DNS ni yo’qotdimi? Ikki sabab

Eskirgan resolver fayli va raqobatchi marshrut metrikasi WSL2 ichida bir xil belgini keltirib chiqaradi. Ikkala tomonni yozib oling, keyin haqiqatan buzilganini tuzating.

Manzil bo’yicha ping distributiv ichida ishlaydi, paket o’rnatish va git yuklash ishlamaydi, nosozlik esa tunnel ko’tarilgandan keyin darhol paydo bo’ldi. Faqat nomlar yechilishdan to’xtadi, bu DNS ga ishora qiladi, ulanishga emas. Paketlarni qayta o’rnatish bu yerda eng mashhur noto’g’ri birinchi qadam. WSL2 da aynan shu belgini keltirib chiqaradigan ikki mustaqil yo’l bor va ular har xil ta’mirlashni talab qiladi.

Nega distributiv o’z resolverini saqlaydi

Windows ning DNS mijozi distributiv ichida ishlatilmaydi. WSL2 ishga tushishda o’z resolver faylini quradi va u Windows yordamchi virtual mashina uchun virtual kommutatorda e’lon qiladigan stub manzilga ishora qiladi.

Bu tartib oddiy tarmoq o’zgarishlarida barqaror, chunki u bir marta yoziladi va qayta ishlatiladi. Tartib yordamchi virtual mashina allaqachon ishga tushganidan keyin tunnel mijozi xostning adapterlar ro’yxatini qayta yozganda to’g’ri bo’lishdan to’xtaydi.

Distributiv ichida hech narsa bu o’zgarishni kuzatmaydi, shuning uchun fayl endi yo’lda bo’lmasligi mumkin bo’lgan manzilga ishora qilishda davom etadi. Keyingi qidiruv keyin kutadi, vaqti tugaydi yoki ichki zona haqida hech qachon eshitmagan serverdan javob oladi. Ichkaridan resolver shunchaki javob berishni to’xtatadi va barcha nomlar bir vaqtda ishlamaydi.

Avval ikkala tomondan dalil to’plang

Biror narsani o’zgartirishdan oldin distributiv nima ko’rishini, keyin Windows nima ko’rishini yozib oling. Aynan ikki ko’rinish birgalikda nosozlik turlarini ajratadi.

Distributiv ichida resolver faylini, marshrut jadvalini va bitta ichki hamda bitta ommaviy qidiruvni chop eting:

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

Windows da har bir adapter bo’yicha DNS serverlarini va metrikalar bilan IPv4 jadvalini sanab chiqing. VPN mijozi odatda WSL2 quyi tarmog’i uchun marshrut o’rnatadi va uning metrikasi bu trafik tunneldan chiqishini yoki mahalliy qolishini hal qiladi.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Marshrut metrikasi yoki eskirgan fayl

Birinchi nosozlik eskirgan fayl. Resolver ishga tushish paytida adapter holati uchun yozilgan edi va tunnel bu holatni o’zgartirdi. Uning stub manzili endi yetib bo’lmaydigan bo’lishi mumkin yoki ichki zona haqida hech narsa bilmaydigan serverni nomlashi mumkin.

Ikkinchisi marshrutlash muammosi. VPN WSL2 quyi tarmog’ini qamrab oluvchi marshrutni xostning bog’lanish marshrutidan past metrika bilan qo’shganda, yordamchi virtual mashinaga manzillangan paketlar tunnelga kiradi. Shunda faqat DNS emas, har bir WSL2 xizmatining vaqti tugaydi.

Ajratuvchi sinov bir qatorga tushadi. Agar ommaviy resolver kabi raqamli manzil nomlar ishlamayotganda ham ping ga javob bersa, yo’l butun va muammo DNS da. Bu resolver o’zgartirish oqlanadigan holat, oqlanmaydigan holat ham ayon bo’ladi. Agar raqamli sinov ham ishlamasa, yordamchi virtual mashina marshrutini yo’qotgan va hech bir resolver fayli buni tuzatmaydi.

Marshrutlash holati uchun tunnel adapteridan avtomatik metrikni olib tashlang va unga WSL2 bog’lanish marshrutidan yuqori raqam bering:

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

O’chirish muhim. Metrikni o’zgartirish ishlab turgan yordamchi virtual mashinani qayta yozmaydi, shuning uchun o’zgarish ko’rinishidan oldin distributivni qayta qurish kerak.

Faylni ataylab o’z qo’lingizga oling

Agar marshrutlash to’g’ri bo’lsa va faqat ichki nomlar ishlamasa, ayb resolverda va siz generatorni to’xtatishingiz mumkin. Bu texnik xizmat xarajati bilan ataylab qilingan o’zgarish, beparvolik bilan qo’llanadigan vaqtinchalik yechim emas.

Distributiv ichida generatsiyani o’chiradigan tarmoq bo’limi bilan /etc/wsl.conf yarating, keyin resolver faylini o’zingiz yozing, avval korporativ server va keyin ommaviy zaxira:

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

Tartib muhim. Ommaviy resolver ichki nomga javob bera olmaydi va zaxira faqat internet qidiruvlari uchun mavjud. Fayl sizniki bo’lgandan keyin hech narsa uni qayta yaratmaydi, shuning uchun ko’chib yuruvchi korporativ resolver o’zingiz sezishingiz kerak bo’lgan uzilishga aylanadi.

Avval nomlarni, keyin paketlarni tekshiring

Tizim resolveri bilan bitta ichki va bitta ommaviy nomni tekshirib, keyin ishlamagan amalni takrorlang. Paket menejerlari ba’zan o’z resolveridan foydalanadi, shuning uchun ishlaydigan getent buzilgan o’rnatish bilan birga bo’lishi mumkin.

Qayta yozishni avtomatlashtirsangiz, uni idempotent qiling: tunnel bo’lmasa, bo’sh server ro’yxatini yozish o’rniga mavjud faylni saqlang.

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

Distributiv ichidan ishlaydigan ichki qidiruv va ishlaydigan ommaviy qidiruv yozib olishga arziydigan natija. Xostdagi yashil VPN belgisi ikkalasini ham isbotlamaydi.

O'xshash maqolalar