VPN qoşulanda WSL niyə iş host adını itirir?

Windows daxili hostu heç bir şikayət olmadan həll edir, eyni ad isə tunel qalxan kimi WSL daxilində uğursuz olur. Adi düzəliş distributivə ictimai resolver yazmaqdır ki, bu da adi gəzintini bərpa edir və iş host adını həll edilə bilməz hala gətirir. Bu, bir nasazlığı digəri ilə dəyişir və əslində qırılan təbəqəni gizlədir. Hər hansı resolver sətri əlavə etməzdən və ya silməzdən əvvəl üç təbəqədən hansının uğursuz olduğunu müəyyənləşdirin.

Əvvəlcə marşrutlaşdırma nasazlığını istisna edin

Eyni tam kvalifikasiyalı adı hər iki tərəfdə soruşun, bir-birinə oxşayan iki adı yox. Eyni sətir üçün Windows-da uğur və WSL-də uğursuzluq iki həll yolunun imzasıdır və bu naxışı bu qədər təmiz yaradan başqa az şey var. Əgər WSL xidmətə onun məlum rəqəmsal ünvanı ilə də çata bilmirsə, deməli marşrutlaşdırma və ya filtrləmə problemi də var. Bu halda DNS işi bunu aşkar etməyəcək və günorta yanlış təbəqəyə gedəcək.

Üç simptom bu halların çoxunu əhatə edir və hər biri başqa yerə işarə edir. Konfiqurasiya faylını açmazdan əvvəl uyğun sətri oxuyun:

Orta sətir insanların səhv oxuduğu sətirdir, çünki onu qıran dəyişiklik həftələr əvvəl edilib və o vaxt uğurlu görünüb. Üçüncü sətir insanların səhv diaqnoz qoyduğu sətirdir, çünki həll olunan ad şəbəkənin sağlam olmasının sübutu kimi hiss olunur. Hər iki sətir sizi aşağıda başqa bölməyə göndərir.

DNS tunelləşdirməsinin versiya həddi var

Microsoft WSL-də DNS sorğularını virtuallaşdırma kanalı üzərindən Windows resolverinə tunelləşdirən şəbəkə rejimini sənədləşdirir. Dəstəklənən Windows 11 buraxılışlarında bu rejim standart olaraq aktivdir və buna görə eyni korporativ şəbəkədəki iki maşın fərqli davranır. Dəyişən buraxılış nömrəsidir, korporativ siyasət deyil.

WSL şəbəkə təlimatı həmin rejimi və onu dəstəkləyən versiyaları təsvir edir. Bu xüsusiyyət vacibdir, çünki korporativ DNS siyasəti adətən Windows resolverində yaşayır və Windows yolunu miras alan distributiv siyasəti də onunla miras alır. İctimai resolverə sorğu göndərən distributivin xüsusi ada heç bir marşrutu yoxdur, öz konfiqurasiyası nə qədər səliqəli görünsə də. Bu mexanizm bütün simptomu izah edir və ictimai resolver həllinin niyə uğursuz olduğunu izah edir.

Heç nəyi redaktə etməzdən əvvəl buraxılışı oxuyun. Daha yeni quraşdırmadan kopyalanmış parametr köhnə quraşdırmanın onu tətbiq etdiyinə dəlil deyil. Buraxılışı dəyişikliyin yanında qeyd edin, çünki iki maşın arasındakı fərq demək olar ki, həmişə siyasət deyil, versiyadır.

Köhnə üstələmələr həll etdikləri problemdən çox yaşayır

Köhnə reseptlər yaradılmış resolver fayllarını söndürdü, ad serverini sərt kodla yazdı və ya faylı dəyişməz atributla bağladı. Bu dəyişikliklər onları doğuran bağlantı problemi yox olduqdan çox sonra da yerində qalır və adətən yeni parametrin heç nə etməməsinin səbəbi onlardır. Onlar həm də distributivin yenidən quraşdırılmasından sonra hər girişdə faylı yenidən yazan shell profili şəklində qalır. Sonuncunu tapmaq ən çətindir, çünki hamının yoxladığı fayldan görünmür.

Əl ilə yazılmış resolver faylı, onun üzərində dəyişməz atribut və onu yenidən yazan başlanğıc skripti axtarın. Redaktə etməzdən əvvəl dəyişməz bayrağı yoxlayın, çünki bağlı fayla yazma icazə problemi kimi oxunan şəkildə uğursuz olur. Sonra shell profilini yoxlayın, çünki oradakı skript düzəlişinizdən saniyələr sonra köhnə məzmunu bərpa edir.

Üstələmənin silinməsinin nəticələri var, ona görə nəyi və niyə sildiyinizi qeyd edin. Başqa məqsəd üçün həqiqətən statik resolverə ehtiyacı olan distributiv yaradılmış fayl qayıdanda qırılacaq.

İki fayl, iki fərqli rol

İki konfiqurasiya faylı fərqli yerlərdə yaşayır və fərqli şeyləri idarə edir, onları qarışdırmaq isə yanlış təbəqəyə tətbiq olunan redaktələr yaradır. Windows tərəfindəki fayl virtual maşının xassələrini təyin edir, distributiv tərəfindəki fayl isə həmin distributivin öz resolver konfiqurasiyasını necə qurduğunu təyin edir. Heç biri digərini üstələmir, buna görə də hər ikisi razılaşmalıdır.

Xüsusiyyəti dəstəkləyən quraşdırma üçün Windows tərəfindəki fraqment qısadır. O tərəfdəki bütün dəyişiklik budur:

[wsl2]
dnsTunneling=true

Bu fraqment Windows istifadəçi profilində olmalıdır və tək bir distributivə deyil, virtual maşına aiddir. Tunelləşdirmə həmçinin distributivin resolver yaradılmasını söndürməməsini tələb edir, ona görə distributiv tərəfindəki fayl bu davranışa toxunmamalıdır. Birini digəri olmadan dəyişin və rejim səssizcə heç nə etmir; bu düzəlişin pozulmuş kimi bildirilməsinin ən çox yayılmış yoludur. Hər iki faylı eyni sessiyada yoxlayın, çünki həftələrlə araya düşən iki redaktə heç kimin aid edə bilmədiyi iki redaktədir.

Yenidən başladın, sonra hər iki tərəfdən soruşun

Bu parametrlər mühit başlayanda oxunur, ona görə işləyən distributiv daxilində yeni shell onları yenidən yükləməyəcək. Shell-i yenidən başlatmaq əvəzinə mühiti söndürün və əvvəlcə işləyən işi yadda saxlayın, çünki hər distributiv onunla birlikdə dayanır. Yalnız bu buraxma dəyişikliyin heç bir təsiri olmadığına dair hesabatların çoxunu izah edir.

Sonra eyni sualı hər iki tərəfdən verin. Çıxış həm də distributivin faktiki olaraq hansı resolverlə qaldığını göstərir:

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'

Birinci əmr mühiti bitirir, ikincisi distributivin indi hansı resolveri istifadə etdiyini göstərir, son iki əmr isə eyni sualı hər tərəfə verir. Parametrin statusunu deyil, cavabları müqayisə edin. Hər iki fayl düzgün olduğu halda təmiz yenidən başlatmadan sonra da uğursuz olan sorğu korporativ resolver siyasətinə işarə edir və o söhbətin başqa sahibi var.