VPN ulanayotganda WSL ish xost nomini nima uchun yo‘qotadi?
Xuddi shu nom Windows-da ishlaydi va tunnel ko‘tarilishi bilanoq WSL ichida muvaffaqiyatsiz bo‘ladi. Resolver qo‘shishdan oldin platformaning DNS rejimi va eskirgan bekor qilishlarni tekshiring.
Windows ichki xostni hech qanday shikoyatsiz hal qiladi, xuddi shu nom esa tunnel ko‘tarilgan lahzada WSL ichida muvaffaqiyatsiz bo‘ladi. Odatiy tuzatish distributivga ommaviy resolver yozishdir, bu oddiy ko‘rishni tiklaydi va ish xost nomini hal qilib bo‘lmaydigan qiladi. Bu bir nosozlikni boshqasiga almashtiradi va aslida buzilgan qatlamni yashiradi. Resolverning biron-bir satrini qo‘shish yoki olib tashlashdan oldin uchta qatlamdan qaysi biri muvaffaqiyatsiz bo‘layotganini aniqlang.
Avval marshrutlash nosozligini istisno qiling
Ikkala tomonda ham xuddi shu to‘liq malakali nomni so‘rang, o‘xshash ikki nomni emas. Bir xil satr uchun Windows-da muvaffaqiyat va WSL-da muvaffaqiyatsizlik ikki hal qilish yo‘lining imzosi, va bu naqshni bunday toza hosil qiladigan boshqa narsa kam. Agar WSL xizmatga uning ma’lum raqamli manzilida ham yetib bora olmasa, marshrutlash yoki filtrlash muammosi ham bor. Bunday holda DNS ishi buni oshkor qilmaydi, va tushdan keyin noto‘g‘ri qatlamga ketadi.
Uchta alomat bu holatlarning ko‘pini qamrab oladi, va har biri boshqa joyga ishora qiladi. Konfiguratsiya faylini ochishdan oldin mos keladigan satrni o‘qing:
| Symptom inside WSL | Likely layer | Where to look |
|---|---|---|
| Private name fails while public browsing works | Resolver path | Tunneling mode and the Windows build |
| A name that worked yesterday fails today | Stale override | Generated resolver file, immutable flag, shell profile |
| The name resolves but the service does not | Routing or filtering | The resolved address and the path to it |
O‘rta satrni odamlar noto‘g‘ri o‘qiydi, chunki uni buzgan o‘zgarish haftalar oldin qilingan va o‘shanda muvaffaqiyatli ko‘ringan. Uchinchi satrni odamlar noto‘g‘ri tashxis qiladi, chunki hal bo‘ladigan nom tarmoq sog‘lom ekanining dalilidek tuyuladi. Ikkala satr ham sizni pastdagi boshqa bo‘limga yuboradi.
DNS tunnellashning eng past versiya chegarasi bor
Microsoft virtualizatsiya kanali orqali DNS so‘rovlarini Windows resolveriga tunnellaydigan WSL tarmoq rejimini hujjatlashtiradi. Qo‘llab-quvvatlanadigan Windows 11 buildlarida u sukut bo‘yicha yoqilgan, shuning uchun bir korporativ tarmoqdagi ikki mashina turlicha ishlaydi. O‘zgaruvchi build raqami, korporativ siyosat emas.
WSL tarmoq qo‘llanmasi o‘sha rejim va uni qo‘llab-quvvatlaydigan versiyalarni tavsiflaydi. Bu funksiya muhim, chunki korporativ DNS siyosati odatda Windows resolverida yashaydi, va Windows yo‘lini meros olgan distributiv siyosatni ham birga oladi. Ommaviy resolverdan so‘raydigan distributivning shaxsiy nomga hech qanday yo‘li yo‘q, o‘z konfiguratsiyasi qanchalik tartibli ko‘rinmasin. Aynan shu mexanizm butun alomatni tushuntiradi va ommaviy resolver bilan aylanib o‘tish nima uchun muvaffaqiyatsiz bo‘lishini tushuntiradi.
Biror narsani tahrirlashdan oldin buildni o‘qing. Yangiroq o‘rnatishdan ko‘chirilgan sozlama eskiroq o‘rnatish uni amalga oshirishiga dalil emas. O‘zgarish yoniga build raqamini yozib qo‘ying, chunki ikki mashina orasidagi farq deyarli har doim versiya, siyosat emas.
Eski bekor qilishlar o‘zlari hal qilgan muammodan uzoq yashaydi
Eski retseptlar hosil qilinadigan resolver fayllarini o‘chirib qo‘yardi, nom serverini qattiq kodlardi yoki faylni o‘zgarmas atribut bilan qulflardi. Bu o‘zgarishlar ularni keltirib chiqargan ulanish muammosi yo‘qolgandan keyin ham uzoq vaqt joyida qoladi, va yangi sozlama hech narsa qilmayotgandek ko‘rinishining sababi odatda shular. Ular distributivni qayta o‘rnatishdan keyin ham shell profili ko‘rinishida saqlanib qoladi, u faylni har kirishda qayta yozadi. Oxirgisini topish eng qiyin, chunki u hamma tekshiradigan fayldan ko‘rinmaydi.
Qo‘lda yozilgan resolver faylini, undagi o‘zgarmas atributni va uni qayta yozadigan ishga tushirish skriptini qidiring. Tahrirlashdan oldin o‘zgarmas bayroqni tekshiring, chunki qulflangan faylga yozish ruxsat muammosidek o‘qiladigan tarzda muvaffaqiyatsiz bo‘ladi. Keyin shell profilini tekshiring, chunki u yerdagi skript sizning tuzatishingizdan keyin bir necha soniya ichida eski tarkibni qaytaradi.
Bekor qilishni olib tashlashning oqibatlari bor, shuning uchun nima olib tashlaganingizni va nima uchunligini yozib qo‘ying. Boshqa maqsad uchun haqiqatan statik resolver kerak bo‘lgan distributiv hosil qilingan fayl qaytganda buziladi.
Ikki fayl, ikki xil rol
Ikki konfiguratsiya fayli turli joylarda yashaydi va turli narsalarni boshqaradi, ularni aralashtirish esa noto‘g‘ri qatlamga qo‘llaniladigan tahrirlarni hosil qiladi. Windows tomonidagi fayl virtual mashina xususiyatlarini belgilaydi, distributiv tomonidagi fayl esa bu distributiv o‘z resolver konfiguratsiyasini qanday qurayotganini belgilaydi. Hech biri ikkinchisini bekor qilmaydi, shuning uchun ikkalasi ham kelishishi kerak.
Bu funksiyani qo‘llab-quvvatlaydigan o‘rnatish uchun Windows tomonidagi parcha qisqa. Bu — o‘sha tomondagi butun o‘zgarish:
[wsl2]
dnsTunneling=trueBu parcha Windows foydalanuvchi profiliga tegishli va bitta distributivga emas, virtual mashinaga qo‘llaniladi. Tunnellash shuningdek distributiv resolver generatsiyasini o‘chirmagan bo‘lishini talab qiladi, shuning uchun distributiv tomonidagi fayl bu xatti-harakatni tinch qoldirishi kerak. Birini ikkinchisisiz o‘zgartirsangiz, rejim indamay hech narsa qilmaydi, va bu tuzatishning buzilgan deb xabar qilinishining eng keng tarqalgan usuli. Ikkala faylni ham bir sessiyada tekshiring, chunki haftalab oraliq bilan qilingan ikki tahrir hech kim ayblay olmaydigan ikki tahrirdir.
Qayta ishga tushiring, keyin ikkala tomondan ham so‘rang
Bu sozlamalar muhit ishga tushganda o‘qiladi, shuning uchun ishlab turgan distributiv ichidagi yangi shell ularni qayta yuklamaydi. Shellni qayta ishga tushirish o‘rniga muhitni o‘chiring, va avval ishlab turgan ishni saqlang, chunki har bir distributiv u bilan birga to‘xtaydi. Faqat shu tashlab ketish o‘zgarishning ta’siri yo‘qligi haqidagi xabarlarning ko‘pini tushuntiradi.
Keyin ikkala tomonga ham xuddi shu savolni bering. Chiqish shuningdek distributiv oxir-oqibat qaysi resolver bilan qolganini ko‘rsatadi:
wsl.exe --shutdown
wsl.exe -e sh -c 'cat /etc/resolv.conf'
wsl.exe -e sh -c 'getent hosts files.corp.example'
wsl.exe -e powershell -Command 'Resolve-DnsName files.corp.example'Birinchi buyruq muhitni tugatadi, ikkinchisi distributiv hozir qaysi resolverdan foydalanayotganini ko‘rsatadi, oxirgi ikkisi esa har bir tomonga bir xil savol beradi. Sozlama holatini emas, javoblarni solishtiring. Ikkala fayl ham to‘g‘ri bo‘lganda ham toza qayta ishga tushirishdan keyin muvaffaqiyatsiz bo‘ladigan so‘rov korporativ resolver siyosatiga ishora qiladi, va bu suhbatning egasi boshqa.