VPN bağlandıktan sonra WSL2 DNS’i kaybetti? İki neden

Adresle ping dağıtımın içinde çalışıyor, paket kurulumları ve git çekmeleri çalışmıyor ve arıza tünel kalktıktan hemen sonra ortaya çıktı. Yalnızca adların çözülmesi durdu, bu da DNS’i işaret ediyor, bağlantıyı değil. Paketleri yeniden kurmak burada en yaygın yanlış ilk adımdır. WSL2’nin tam olarak bu belirtiyi üreten iki bağımsız yolu var ve ikisi farklı onarım gerektiriyor.

Dağıtım neden kendi resolver’ını tutuyor

Windows’un DNS istemcisi dağıtımın içinde kullanılmaz. WSL2 başlangıçta kendi resolver dosyasını oluşturur ve Windows’un yardımcı sanal makine için sanal anahtarda yayımladığı stub adresini işaret eder.

Bu düzen olağan ağ değişikliklerinde kararlıdır çünkü bir kez yazılır ve yeniden kullanılır. Düzen, yardımcı sanal makine zaten başladıktan sonra bir tünel istemcisi ana makinenin bağdaştırıcı listesini yeniden yazdığında doğru olmaktan çıkar.

Dağıtımın içinde hiçbir şey bu değişikliği izlemez, bu yüzden dosya artık yolda olmayabilecek bir adresi göstermeye devam eder. Sonraki sorgu o zaman bekler, zaman aşımına uğrar veya iç bölgeyi hiç duymamış bir sunucudan yanıt alır. İçeriden resolver yanıt vermeyi bırakır ve tüm adlar aynı anda başarısız olur.

Önce iki taraftan kanıt toplayın

Herhangi birini değiştirmeden önce dağıtımın ne gördüğünü, sonra Windows’un ne gördüğünü kaydedin. İki görünüm birlikte arıza biçimlerini ayırt eder.

Dağıtımın içinde resolver dosyasını, yönlendirme tablosunu ve bir iç ile bir genel sorguyu yazdırın:

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

Windows’ta bağdaştırıcı başına DNS sunucularını ve metrikleriyle IPv4 tablosunu listeleyin. VPN istemcisi genellikle WSL2 alt ağı için bir rota kurar ve metriği bu trafiğin tünelden çıkıp çıkmayacağını ya da yerel kalıp kalmayacağını belirler.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Rota metriği mi eski dosya mı

İlk arıza eski dosyadır. Resolver başlangıçtaki bağdaştırıcı durumuna göre yazılmıştı ve tünel bu durumu değiştirdi. Stub adresi artık erişilemez olabilir veya iç bölge hakkında hiçbir şey bilmeyen bir sunucuyu adlandırabilir.

İkincisi bir yönlendirme sorunudur. VPN, WSL2 alt ağını kapsayan bir rotayı ana makinenin bağlantı rotasından düşük metrikle eklediğinde, yardımcı sanal makineye adreslenen paketler tünele girer. O zaman yalnızca DNS değil, her WSL2 hizmeti zaman aşımına uğrar.

Ayırt edici test tek satıra mal olur. Genel bir resolver gibi sayısal bir adres, adlar başarısız olurken hâlâ ping’e yanıt veriyorsa yol sağlamdır ve sorun DNS’tir. Bu, resolver değişikliğinin haklı olduğu durumdur ve olmadığı durum da belirginleşir. Sayısal test de başarısız olursa yardımcı sanal makine rotasını kaybetmiştir ve hiçbir resolver dosyası bunu düzeltmez.

Yönlendirme durumu için tünel bağdaştırıcısındaki otomatik metriği kaldırın ve ona WSL2 bağlantı rotasının üstünde bir sayı verin:

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

Kapatma önemlidir. Metriği değiştirmek çalışan yardımcı sanal makineyi yeniden yazmaz, bu yüzden değişiklik görünmeden önce dağıtımın yeniden derlenmesi gerekir.

Dosyayı bilerek devralın

Yönlendirme doğruysa ve yalnızca iç adlar başarısız oluyorsa suçlu resolver’dır ve üreteci durdurabilirsiniz. Bu, bakım maliyeti olan bilinçli bir değişikliktir, gelişigüzel uygulanacak bir geçici çözüm değildir.

Dağıtımın içinde üretimi devre dışı bırakan ağ bölümüyle /etc/wsl.conf dosyasını oluşturun, sonra resolver dosyasını kendiniz yazın, önce kurumsal sunucu ve ardından genel bir yedek:

[network]
generateResolvConf = false

search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

Sıra önemlidir. Genel bir resolver iç adı yanıtlayamaz ve yedek yalnızca internet sorguları için vardır. Dosya bir kez sizin olduğunda hiçbir şey onu yeniden üretmez, bu yüzden taşınan kurumsal resolver sizin fark etmeniz gereken bir kesintiye dönüşür.

Önce adları, sonra paketleri kontrol edin

Sistem resolver’ıyla bir iç ve bir genel adı doğrulayın, sonra başarısız olan işlemi yineleyin. Paket yöneticileri bazen kendi resolver’larını kullanır, bu yüzden çalışan bir getent bozuk bir kurulumla bir arada bulunabilir.

Yeniden yazmayı otomatikleştiriyorsanız idempotent yapın: tünel yokken boş bir sunucu listesi yazmak yerine var olan dosyayı koruyun.

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

Dağıtımın içinden çalışan bir iç sorgu ve çalışan bir genel sorgu, kaydedilmeye değer sonuçtur. Ana makinedeki yeşil VPN simgesi ikisini de kanıtlamaz.