WSL2 korporativ VPN-ni meros olmaydi va xato aynan shunda

Ichki wiki Edge da ochiladi, lekin distributiv ichida git clone vaqt tugab qoladi. Bu yagona kuzatuv odatda «VPN WSL2 ni bloklayapti» deb o'qiladi va keyingi soat /etc/resolv.conf ni tahrirlashga ketadi. Foydaliroq o'qish shundan iboratki, WSL2 da hostning tarmoq yo'li boshidan bo'lmagan: u o'z adapteri, o'z marshrutlari va Windows unga yaratadigan resolver fayli bo'lgan yordamchi VM da ishlaydi. Keyingi hamma narsa shu uchtadan qaysi biri sizga haqiqatan yetishmasligiga bog'liq.

VM ning o'z steki, metrikalari va resolveri bor

Standart NAT rejimida distributiv virtual kommutator orqasida o'tiradi va internetga host orqali chiqadi, lekin hostning adapterlarini ko'rmaydi. ip addr xususiy manzilli bitta interfeysni ko'rsatadi, ip route shu kommutator orqali standart marshrutni ko'rsatadi, /etc/resolv.conf esa Windows tanlagan stub resolverga ishora qiluvchi yaratilgan fayl. Windows tomonida VPN klienti ishga tushgani tufayli bulardan hech biri o'zgarmaydi.

Shuning uchun «brauzer ishlaydi» juda kam narsani isbotlaydi. Brauzer host steki, tunnel va hostning resolver siyosatidan foydalanadi. Sizning shellingiz esa jismoniy tarmoq kartasini tasodifan bo'lishadigan boshqa stekdan foydalanadi. Ular yaxshi holatda mos keladi va VPN filtr o'rnatganda, DNS ro'yxatini qayta yozganda yoki virtual kommutator subnetiga marshrut qo'shganda aynan o'shanda ajraladi.

Qaysi dunyoda ekaningizni ikkita test hal qiladi va ular distributiv ichida bajarilishi kerak:

getent hosts example.com
curl -sS -m 8 -o /dev/null -w "%{http_code}\n" 1.1.1.1
ip route
cat /etc/resolv.conf

Harfiy manzil javob berayotganda nomlar muvaffaqiyatsiz bo'lishi resolver muammosi. Nomlar va manzillar birga muvaffaqiyatsiz bo'lishi yo'l muammosi va hech qanday resolver tahriri unga tegmaydi. Keyin Windows tomonidan dalillar keladi: Get-NetAdapter | Get-DnsClientServerAddress va route print -4 tunnel VM ingiz yashaydigan subnetni egallaganini ko'rsatadi.

Birinchi afsona: korporativ DNS serverlari buni tuzatadi

Resolver faylini tahrirlash klassik maslahat va u taxminan yarim holatda to'g'ri. To'g'ri bo'lganda aniq sabab bor: yaratilgan fayl faqat ommaviy nomlarni biladigan resolverga ishora qiladi, shuning uchun intranet.example.internal uchun so'rov yo'l joyida bo'lsa ham mavjud emas deb qaytadi.

VPN serverlarini qadash Windows ni faylni qayta yaratishdan to'xtatishni bildiradi, chunki qo'lda yozilgan har qanday fayl keyingi ishga tushishda almashtiriladi:

[network]
generateResolvConf = false

Buni /etc/wsl.conf sifatida saqlang, Windows dan wsl --shutdown ni ishga tushiring, keyin distributivni ishga tushiring va /etc/resolv.conf ni tunnel serverlari birinchi, ommaviy resolver faqat zaxira sifatida yozing. Bu xizmat ko'rsatish xarajati bo'lgan doimiy o'zgarish: fayl endi hostni kuzatmaydi, shuning uchun korporativ DNS manzillari o'zgarganda distributiv eski manzillarni so'rayveradi. Kimdir o'sha faylning egasi bo'lishi kerak.

Muammo kengroq bo'lganda ham hech narsa qilmaydi. Agar curl dan 1.1.1.1 ga vaqt tugasa, tunnel klienti virtual kommutatorni filtrlayapti yoki VM subnetini tunnelga yo'naltiryapti va to'g'ri resolver sizga hali yetib bo'lmaydigan nomlarnigina beradi.

Ikkinchi afsona: metrika o'zgarishi saqlanib qoladi

Nomlar hal bo'lib, lekin trafik jismoniy adapterdan chiqsa, interfeys metrikalari richag bo'ladi. VPN adapteriga yuqori xarajat, WSL kommutatoriga past xarajat bering:

Get-NetAdapter | Where-Object InterfaceDescription -Match "AnyConnect" | Set-NetIPInterface -InterfaceMetric 4000
Get-NetIPInterface -InterfaceAlias "vEthernet (WSL)" | Set-NetIPInterface -InterfaceMetric 1

Keyin esda tuting, ko'p klient buildlarida tunnel adapteri har bir ulanishda qayta yaratiladi va metrika o'z standartiga qaytadi. Bir martalik buyruq jimgina tugaydigan tuzatish, odatda dam olish kunlarida, va chipta «o'tgan hafta ishlayotgan edi» bilan qaytadi. VPN hodisasi bilan ishga tushadigan rejalashtirilgan vazifa yoki foydalanuvchi ulangandan keyin ishga tushiradigan skript bu tuzatishning halol ko'rinishi.

Xuddi shu muddat bitta qaysar prefiks uchun qo'shilgan host marshrutlariga ham tegishli. Diagnostika sifatida ular qimmatli, chunki muammo bitta manzilmi yoki butun yo'lmi — buni aytadi, lekin ular arxitektura emas.

Uchinchi afsona: bitta tuzatish har bir Windows buildini qamrab oladi

wsl-vpnkit sidecar naqshidir: kichik distributiv host tomonidagi yo'lni egallaydi va boshqa distributivlar uchun virtual soket orqali uzatadi, shuning uchun ilova trafigi filtrlangan kommutatorga bog'liq bo'lishni to'xtatadi. Standart yo'l ishlashi kerak, ya'ni networkingMode va dnsTunneling qayta yozishlarini %UserProfile%\.wslconfig dan olib tashlash, har bir ishlaydigan distributivda generateResolvConf = true ni tiklash va xizmatni kirishda ishga tushirish.

Oynali rejim Windows 11 22H2 va undan keyingi versiyalarda ichki muqobil bo'lib, u bitta sozlama va bitta o'chirishdir:

[wsl2]
networkingMode=mirrored

Distributiv ichida ip addr keyin host adapterlarini sanaydi, tunnel ular orasida ko'rinishi mumkin va DNS tunnellash klient DNS ro'yxatini qayta yozganda ham so'rovlarni Windows resolveri orqali uzatadi. Bu universal emas: ba'zi filtr drayverlari oynali yo'lni hali ham tashlab yuboradi va Hyper-V xavfsizlik devori qoidalariga ochiq ruxsat kerak bo'lishi mumkin. Microsoft ning WSL tarmoq qo'llanmasi yangiroq uchun yozilgan retseptni qo'llashdan oldin o'z buildingiz bilan solishtirishingiz kerak bo'lgan sahifa.

Har bir o'zgarishdan keyin uchta narsani sinab ko'ring

Har bir mashina uchun bitta mexanizm tanlang va yozib qo'ying, chunki ikkalasi yomon birlashadi. Oynali rejim ustidagi sidecar uzatishni ikki barobar oshiradi va .wslconfig da eskirgan sidecar yozuvi bo'lgan oynali host yangilanishdan keyin muvaffaqiyatsiz bo'ladi, oldin emas.

Nima tanlagan bo'lsangiz ham, qabul sinovi distributiv ichidagi o'sha uchta so'rov: ichki nom, ommaviy nom va xom manzil. Keyin tunnelni uzib qayta ulagandan so'ng va wsl --shutdown dan keyin ularni takrorlang. Faqat ichki nom muvaffaqiyatsiz bo'lsa resolver siyosati; ichki va ommaviy nomlar birga muvaffaqiyatsiz bo'lib manzil ishlasa ham resolver siyosati; hammasi muvaffaqiyatsiz bo'lsa yo'l.

Agar bitta ichki host muvaffaqiyatsiz bo'lib qolganlari ishlasa, resolverga qarashni to'xtating va o'sha prefiks uchun yo'qolgan marshrutni qidiring. Hammasi keyingi qayta ulanishgacha ishlasa, siz ishlash vaqti holatiga bog'liq tuzatish topdingiz va uni avtomatik qayta qo'llash yoki yuqoridagi ikki mexanizmdan biri bilan almashtirish kerak.