VPN bağlandığında WSL çalışma ana makine adını neden kaybeder?

Windows iç ana makineyi hiçbir şikâyet olmadan çözer ve aynı ad tünel kalktığı anda WSL içinde başarısız olur. Alışılmış onarım, dağıtıma genel bir çözümleyici yazmaktır; bu, normal gezinmeyi geri getirir ve çalışma ana makine adını çözülemez hale getirir. Bu, bir arızayı diğeriyle değiştirir ve gerçekte bozulan katmanı gizler. Herhangi bir çözümleyici satırı eklemeden veya kaldırmadan önce üç katmandan hangisinin başarısız olduğunu belirleyin.

Önce yönlendirme arızasını dışlayın

Aynı tam nitelikli adı iki tarafta da sorgulayın, birbirine benzeyen iki adı değil. Aynı dize için Windows'ta başarı ve WSL'de başarısızlık, iki çözümleme yolunun imzasıdır ve bu deseni bu kadar temiz üreten başka az şey vardır. WSL hizmete bilinen sayısal adresinde de ulaşamıyorsa, bir yönlendirme veya filtreleme sorunu da vardır. Bu durumda DNS çalışması bunu ortaya çıkarmaz ve öğleden sonra yanlış katmana gider.

Üç belirti bu durumların çoğunu kapsar ve her biri başka bir yeri işaret eder. Bir yapılandırma dosyası açmadan önce eşleşen satırı okuyun:

Orta satırı insanlar yanlış okur, çünkü onu bozan değişiklik haftalar önce yapılmıştı ve o zaman başarılı görünüyordu. Üçüncü satırı insanlar yanlış teşhis eder, çünkü çözülen bir ad ağın sağlıklı olduğunun kanıtı gibi gelir. Her iki satır da sizi aşağıdaki farklı bölüme gönderir.

DNS tünellemesinin bir sürüm tabanı vardır

Microsoft, DNS isteklerini sanallaştırma kanalı üzerinden Windows çözümleyicisine tünelleyen bir WSL ağ modunu belgeler. Desteklenen Windows 11 derlemelerinde bu mod varsayılan olarak açıktır, bu yüzden aynı kurumsal ağdaki iki makine farklı davranır. Değişken derleme numarasıdır, kurumsal politika değil.

WSL ağ kılavuzu bu modu ve onu destekleyen sürümleri açıklar. Özellik önemlidir çünkü kurumsal DNS politikası genellikle Windows çözümleyicisinde yaşar ve Windows yolunu devralan dağıtım politikayı da devralır. Genel bir çözümleyiciye soran dağıtımın özel bir ada giden hiçbir yolu yoktur, kendi yapılandırması ne kadar düzenli görünürse görünsün. Bu mekanizma tüm belirtiyi açıklar ve genel çözümleyici çözümünün neden başarısız olduğunu da açıklar.

Herhangi bir şeyi düzenlemeden önce derlemeyi okuyun. Daha yeni bir kurulumdan kopyalanan ayar, daha eski bir kurulumun onu uyguladığının kanıtı değildir. Derleme numarasını değişikliğin yanına not edin, çünkü iki makine arasındaki fark neredeyse her zaman sürümdür, politika değil.

Eski geçersiz kılmalar çözdükleri sorundan daha uzun yaşar

Daha eski tarifler üretilen çözümleyici dosyalarını devre dışı bırakıyordu, ad sunucusunu sabit kodluyordu veya dosyayı değişmez bir öznitelikle kilitliyordu. Bu değişiklikler, onlara yol açan bağlantı sorunu ortadan kalktıktan çok sonra da yerinde kalır ve yeni bir ayarın hiçbir şey yapmıyormuş gibi görünmesinin nedeni genellikle bunlardır. Dağıtımın yeniden kurulmasından sonra da her oturum açmada dosyayı yeniden yazan bir shell profili biçiminde hayatta kalırlar. Sonuncusunu bulmak en zordur, çünkü herkesin incelediği dosyadan görünmez.

Elle yazılmış bir çözümleyici dosyası, üzerinde değişmez bir öznitelik ve onu yeniden yazan bir başlangıç betiği arayın. Düzenlemeden önce değişmez bayrağı denetleyin, çünkü kilitli bir dosyaya yazma izin sorunu gibi okunan bir biçimde başarısız olur. Ardından shell profilini denetleyin, çünkü oradaki betik düzeltmenizden saniyeler sonra eski içeriği geri getirir.

Geçersiz kılmayı kaldırmanın sonuçları vardır, bu yüzden neyi kaldırdığınızı ve nedenini not edin. Başka bir amaç için gerçekten statik bir çözümleyiciye ihtiyaç duyan dağıtım, üretilen dosya geri geldiğinde bozulur.

İki dosya, iki farklı rol

İki yapılandırma dosyası farklı yerlerde yaşar ve farklı şeyleri denetler; onları karıştırmak yanlış katmana uygulanan düzenlemeler üretir. Windows tarafındaki dosya sanal makinenin özelliklerini ayarlar, dağıtım tarafındaki dosya ise o dağıtımın kendi çözümleyici yapılandırmasını nasıl kurduğunu ayarlar. Hiçbiri diğerini geçersiz kılmaz, bu yüzden ikisi de anlaşmak zorundadır.

Özelliği destekleyen bir kurulum için Windows tarafındaki parça kısadır. O taraftaki tüm değişiklik budur:

[wsl2]
dnsTunneling=true

Bu parça Windows kullanıcı profiline aittir ve tek bir dağıtıma değil sanal makineye uygulanır. Tünelleme ayrıca dağıtımın çözümleyici üretimini devre dışı bırakmamış olmasını gerektirir, bu yüzden dağıtım tarafındaki dosya bu davranışı kendi hâline bırakmalıdır. Birini diğeri olmadan değiştirin ve mod sessizce hiçbir şey yapmaz; bu onarımın bozuk olarak bildirilmesinin en yaygın yolu budur. İki dosyayı da aynı oturumda denetleyin, çünkü haftalar arayla yapılan iki düzenleme kimsenin atfedemeyeceği iki düzenlemedir.

Yeniden başlatın, sonra iki taraftan da sorgulayın

Bu ayarlar ortam başladığında okunur, bu yüzden çalışan bir dağıtımın içindeki yeni shell bunları yeniden yüklemez. Shell'i yeniden başlatmak yerine ortamı kapatın ve önce çalışan herhangi bir işi kaydedin çünkü her dağıtım onunla birlikte durur. Yalnızca bu atlama, bir değişikliğin etkisi olmadığına dair bildirimlerin çoğunu açıklar.

Sonra aynı soruyu iki taraftan da sorun. Çıktı ayrıca dağıtımın gerçekte hangi çözümleyicide kaldığını da gösterir:

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'

İlk komut ortamı bitirir, ikincisi dağıtımın şu anda hangi çözümleyiciyi kullandığını gösterir ve son ikisi aynı soruyu her tarafa sorar. Ayarın durumunu değil yanıtları karşılaştırın. Her iki dosya doğruyken temiz bir yeniden başlatmadan sonra hâlâ başarısız olan sorgu kurumsal çözümleyici politikasına işaret eder ve o konuşmanın başka bir sahibi vardır.