VPN qoşulandan sonra WSL2 DNS-i itirdi? İki səbəb

Ünvana görə ping distributiv daxilində işləyir, paket quraşdırmaları və git çəkmələri işləmir, nasazlıq isə tunel qalxdıqdan dərhal sonra göründü. Yalnız adların həlli dayandı, bu da DNS-ə işarə edir, bağlantıya yox. Paketlərin yenidən quraşdırılması burada ən məşhur səhv ilk addımdır. WSL2-də məhz bu simptomu yaradan iki müstəqil yol var və onlar fərqli təmir tələb edir.

Niyə distributiv öz resolver-ini saxlayır

Windows DNS müştərisi distributiv daxilində istifadə olunmur. WSL2 başlanğıcda öz resolver faylını qurur və o, Windows-un köməkçi VM üçün virtual svitçdə yayımladığı stub ünvana işarə edir.

Bu quruluş adi şəbəkə dəyişikliklərində sabitdir, çünki bir dəfə yazılır və təkrar istifadə olunur. Quruluş, tunel müştərisi köməkçi VM artıq başladıqdan sonra host adapter siyahısını yenidən yazdıqda doğru olmaqdan çıxır.

Distributiv daxilində heç nə dəyişikliyi izləmir, ona görə fayl artıq yolda olmaya biləcək ünvana işarə etməyə davam edir. Sonrakı axtarış sonra gözləyir, vaxtı bitir və ya daxili zonanı heç vaxt eşitməmiş serverdən cavab alır. İçəridən resolver sadəcə cavab verməyi dayandırır və bütün adlar bir anda uğursuz olur.

Əvvəlcə hər iki tərəfdən sübut toplayın

Distributivin gördüyünü, sonra Windows-un gördüyünü qeyd edin, hər hansı birini dəyişməzdən əvvəl. İki görünüş birlikdə nasazlıq rejimlərini fərqləndirir.

Distributiv daxilində resolver faylını, marşrut cədvəlini və bir daxili, bir də ictimai axtarışı çap edin:

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

Windows-da hər adapter üzrə DNS serverlərini və metrikləri ilə IPv4 cədvəlini sadalayın. VPN müştərisi adətən WSL2 alt şəbəkəsi üçün marşrut quraşdırır və onun metriki bu trafikin tuneldən çıxıb-çıxmadığını və ya lokal qaldığını müəyyən edir.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Marşrut metriki yoxsa köhnəlmiş fayl

Birinci nasazlıq köhnəlmiş fayldır. Resolver adapterin başlanğıc vəziyyəti üçün yazılmışdı və tunel o vəziyyəti dəyişdi. Onun stub ünvanı artıq əlçatmaz ola bilər, ya da daxili zona haqqında heç nə bilməyən serverə işarə edə bilər.

İkincisi marşrut problemidir. VPN WSL2 alt şəbəkəsini əhatə edən marşrutu host keçid marşrutundan aşağı metrikə malik əlavə etdikdə, köməkçi VM-ə ünvanlanmış paketlər tunelə daxil olur. Onda yalnız DNS deyil, hər WSL2 xidməti vaxt aşımına uğrayır.

Fərqləndirici test bir sətirə başa gəlir. Əgər ictimai resolver kimi rəqəmli ünvan adlar uğursuz olduğu halda ping-ə hələ cavab verirsə, yol salamatdır və problem DNS-dir. Bu, resolver dəyişikliyinin əsaslandığı haldır və əsaslandırmadığı hal da aydın olur. Rəqəmli test də uğursuz olarsa, köməkçi VM marşrutunu itirib və heç bir resolver faylı bunu düzəltməyəcək.

Marşrut halı üçün tunel adapterində avtomatik metriki ləğv edin və ona WSL2 keçid marşrutundan yuxarı bir rəqəm verin:

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

Söndürmə vacibdir. Metrikin dəyişdirilməsi işləyən köməkçi VM-i yenidən yazmır, ona görə dəyişiklik görünməzdən əvvəl distributiv yenidən qurulmalıdır.

Faylı qəsdən öz əlinizə alın

Əgər marşrutlaşdırma doğrudursa və yalnız daxili adlar uğursuz olursa, günah resolver-dədir və generatoru dayandıra bilərsiniz. Bu, texniki xidmət xərci olan qəsdən edilmiş dəyişiklikdir, təsadüfən tətbiq olunacaq müvəqqəti həll deyil.

Distributiv daxilində generasiyanı söndürən şəbəkə bölməsi ilə /etc/wsl.conf faylını yaradın, sonra resolver faylını özünüz yazın, əvvəl korporativ server, sonra ictimai ehtiyat:

[network]
generateResolvConf = false

search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

Sıra vacibdir. İctimai resolver daxili ada cavab verə bilməz və ehtiyat yalnız internet axtarışları üçündür. Fayl sizin olduqdan sonra onu heç nə yenidən yaratmır, ona görə də yerini dəyişən korporativ server özünüz fərq etməli olduğunuz kəsintiyə çevrilir.

Əvvəl adları, sonra paketləri yoxlayın

Sistem resolver-i ilə bir daxili və bir ictimai adı yoxlayın, sonra uğursuz olan əməliyyatı təkrarlayın. Paket menecerləri bəzən öz resolver-lərini istifadə edir, buna görə işləyən getent xarab quraşdırma ilə yanaşı mövcud ola bilər.

Yenidən yazmanı avtomatlaşdırırsınızsa, onu idempotent edin: tunel yoxdursa, boş server siyahısı yazmaq əvəzinə mövcud faylı saxlayın.

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

Distributiv daxilindən işləyən daxili axtarış və işləyən ictimai axtarış qeydə dəyər nəticədir. Host-dakı yaşıl VPN ikonu heç birini sübut etmir.