WSL2 korporativ VPN-i miras almır və problem də elə bundadır

Daxili wiki Edge-də açılır, distro daxilində isə git clone vaxt aşımına düşür. Bu tək müşahidə adətən «VPN WSL2-ni bloklayır» kimi oxunur və növbəti saat /etc/resolv.conf redaktəsinə gedir. Daha faydalı oxunuş budur: WSL2 host-un şəbəkə yoluna heç vaxt sahib olmayıb, çünki o, öz adapteri, öz marşrutları və Windows-un onun üçün yaratdığı resolver faylı olan köməkçi VM-də işləyir. Bundan sonrakı hər şey bu üçündən hansının əslində çatışmadığından asılıdır.

VM-in öz yığını, metrikası və resolver-i var

Standart NAT rejimində distro virtual kommutatorun arxasında oturur və internetə host vasitəsilə çıxır, amma host-un adapterlərini görmür. ip addr şəxsi ünvanlı bir interfeys göstərir, ip route həmin kommutatordan keçən standart marşrut göstərir, /etc/resolv.conf isə Windows-un seçdiyi stub resolver-ə işarə edən yaradılmış fayldır. Windows tərəfində VPN müştərisi işə düşdüyü üçün bunların heç biri dəyişmir.

Buna görə «brauzer işləyir» çox az şey sübut edir. Brauzer host yığınından, tuneldən və host-un resolver siyasətindən istifadə edir. Sizin shell-iniz isə fiziki şəbəkə kartını təsadüfən paylaşan fərqli yığından istifadə edir. Onlar yaxşı halda uyğun gəlir və VPN filtr quraşdıranda, DNS siyahısını yenidən yazanda və ya virtual kommutatorun subnetinə marşrut əlavə edəndə məhz o zaman ayrılır.

Hansı dünyada olduğunuzu iki test həll edir və onlar distro daxilində işləməlidir:

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

Adların uğursuz olub hərfi ünvanın cavab verməsi resolver problemidir. Adlar və ünvanlar birlikdə uğursuz olursa, bu yol problemidir və heç bir resolver redaktəsi ona toxunmaz. Sonra Windows tərəfindən sübutlar gəlir: Get-NetAdapter | Get-DnsClientServerAddress və route print -4 tunelin VM-inizin yaşadığı subneti tutub-tutmadığını göstərir.

Birinci mif: korporativ DNS serverləri bunu düzəldir

Resolver faylını redaktə etmək klassik məsləhətdir və təxminən yarısında doğrudur. Doğru olduqda konkret səbəbdən doğrudur: yaradılmış fayl yalnız public adları bilən resolver-ə işarə edir, ona görə intranet.example.internal üçün sorğu yol qaydasında olsa da mövcud deyil kimi qayıdır.

VPN-in serverlərini bərkitmək Windows-un faylı yenidən yaratmasını dayandırmaq deməkdir, çünki əl ilə yazdığınız hər fayl növbəti başlanğıcda əvəz olunur:

[network]
generateResolvConf = false

Bunu /etc/wsl.conf kimi saxlayın, Windows-dan wsl --shutdown işlədin, sonra distronu başladın və /etc/resolv.conf faylını əvvəlcə tunelin serverləri, yalnız ehtiyat kimi bir public resolver ilə yazın. Bu, xidmət xərci olan davamlı dəyişiklikdir: fayl artıq host-u izləmir, ona görə korporativ DNS ünvanları dəyişəndə distro köhnələri soruşmağa davam edir. Kiminsə o fayla sahib olması lazımdır.

Uğursuzluq daha geniş olduqda da heç nə etmir. Əgər curl 1.1.1.1 ünvanına vaxt aşımına düşürsə, tunel müştərisi virtual kommutatoru filtrləyir və ya VM-in subnetini tunelə yönləndirir və düzgün resolver sizə sadəcə çatmaq mümkün olmayan adlar verir.

İkinci mif: metrika dəyişikliyi qalır

Adlar həll olunur, amma trafik fiziki adapterdən çıxırsa, interfeys metrikaları rıçaqdır. VPN adapterinə yüksək xərc, WSL kommutatoruna aşağı xərc verin:

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

Sonra yadda saxlayın ki, bir çox müştəri buraxılışında tunel adapteri hər qoşulmada yenidən yaradılır və metrika standart dəyərinə qayıdır. Birtərəfli əmr səssizcə bitən düzəlişdir, adətən həftə sonu ərzində, və bilet «keçən həftə işləyirdi» ilə qayıdır. VPN hadisəsi ilə işə düşən planlaşdırılmış tapşırıq və ya istifadəçinin qoşulduqdan sonra işlətdiyi skript bu düzəlişin dürüst versiyasıdır.

Eyni bitmə müddəti bir inadkar prefiks üçün əlavə edilən host marşrutlarına da aiddir. Onlar diaqnostika kimi dəyərlidir, çünki problemin bir təyinat, yoxsa bütün yol olduğunu deyir, amma arxitektura deyillər.

Üçüncü mif: bir düzəliş hər Windows buraxılışını əhatə edir

wsl-vpnkit sidecar nümunəsidir: kiçik bir distro host tərəfindəki yola sahib olur və digər distrolar üçün virtual soket üzərindən yönləndirir, beləliklə tətbiq trafiki filtrlənmiş kommutatordan asılı olmağı dayandırır. Standart yolun işləməsi lazımdır, yəni networkingMode və dnsTunneling üstələmələrini %UserProfile%\.wslconfig faylından silmək, hər işlək distroda generateResolvConf = true bərpa etmək və xidməti girişdə başlatmaq.

Güzgülənmiş rejim Windows 11 22H2 və sonrakılarda daxili alternativdir və bir parametr üstəgəl bir söndürmədir:

[wsl2]
networkingMode=mirrored

Distro daxilində ip addr daha sonra host adapterlərini sadalayır, tunel onların arasında görünə bilər və DNS tunelləməsi müştəri DNS siyahısını yenidən yazanda belə sorğuları Windows resolver-i vasitəsilə ötürür. Bu universal deyil: bəzi filtr sürücüləri hələ də güzgülənmiş yolu atır və Hyper-V firewall qaydaları açıq icazə tələb edə bilər. Microsoft-un WSL şəbəkə təlimatı daha yeni buraxılış üçün yazılmış resept tətbiq etməzdən əvvəl öz buraxılışınızla tutuşdurmalı səhifədir.

Hər dəyişiklikdən sonra üç şeyi yoxlayın

Hər maşın üçün bir mexanizm seçin və yazın, çünki ikisi pis birləşir. Güzgülənmiş rejimin üstündə sidecar yönləndirməni ikiqat artırır və .wslconfig faylında köhnəlmiş sidecar qeydi olan güzgülənmiş host yüksəltmədən əvvəl deyil, sonra uğursuz olmağa meyllidir.

Nə seçmisinizsə, qəbul testi distro daxilində eyni üç sorğudur: daxili ad, public ad və xam ünvan. Sonra tuneli ayırıb yenidən qoşduqdan və wsl --shutdown əmrindən sonra onları təkrarlayın. Yalnız daxili adın uğursuz olması resolver siyasəti deməkdir; daxili və public adların birlikdə uğursuz olması, ünvan işləyirsə, yenə resolver siyasəti deməkdir; hər şeyin uğursuz olması yol deməkdir.

Bir daxili host uğursuz olub qalanı işləyirsə, resolver-ə baxmağı dayandırın və həmin prefiks üçün çatışmayan marşrut axtarın. Hər şey növbəti yenidən qoşulmaya qədər işləyirsə, iş vaxtı vəziyyətindən asılı olan düzəliş tapmısınız və o, avtomatik yenidən tətbiq olunmalı və ya yuxarıdakı iki mexanizmdən biri ilə əvəz olunmalıdır.