WSL2 kurumsal VPN'i devralmıyor ve hatanın kendisi bu

WSL2 kendi sanal ağında çalışır ve ana makinenin VPN yığınını asla devralmaz. resolv.conf'u düzenlemeden önce ad hatalarını yol hatalarından ayırın.

İç wiki Edge'de açılıyor ama dağıtımın içinde git clone zaman aşımına uğruyor. Bu tek gözlem genellikle «VPN, WSL2'yi engelliyor» diye okunur ve sonraki saat /etc/resolv.conf dosyasını düzenlemekle geçer. Daha faydalı okuma, WSL2'nin ana makinenin ağ yoluna hiç sahip olmadığıdır: kendi adaptörü, kendi rotaları ve Windows'un onun için ürettiği bir resolver dosyası olan bir yardımcı VM'de çalışır. Sonraki her şey, bu üçünden hangisinin gerçekten eksik olduğuna bağlıdır.

VM'in kendi yığını, metrikleri ve resolver'ı var

Varsayılan NAT modunda dağıtım sanal bir anahtarın arkasında oturur ve internete ana makine üzerinden ulaşır, ancak ana makinenin adaptörlerini görmez. ip addr özel adresli tek bir arayüz gösterir, ip route o anahtar üzerinden varsayılan rotayı gösterir ve /etc/resolv.conf Windows'un seçtiği bir stub resolver'ı işaret eden üretilmiş bir dosyadır. Windows tarafında bir VPN istemcisi başladığı için bunların hiçbiri değişmez.

Bu yüzden «tarayıcı çalışıyor» çok az şey kanıtlar. Tarayıcı ana makinenin yığınını, tüneli ve ana makinenin resolver politikasını kullanır. Kabuğunuz ise fiziksel bir ağ kartını tesadüfen paylaşan başka bir yığın kullanır. İkisi iyi durumda örtüşür ve tam olarak VPN bir filtre kurduğunda, DNS listesini yeniden yazdığında veya sanal anahtarın alt ağına bir rota eklediğinde ayrışır.

Hangi dünyada olduğunuzu iki test belirler ve bunların dağıtımın içinde çalıştırılması gerekir:

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

Bir adres harfi harfine yanıt verirken adların başarısız olması resolver sorunudur. Adların ve adreslerin birlikte başarısız olması yol sorunudur ve hiçbir resolver düzenlemesi ona dokunmaz. Sırada Windows tarafındaki kanıtlar var: Get-NetAdapter | Get-DnsClientServerAddress ve route print -4 tünelin VM'nizin yaşadığı alt ağı alıp almadığını gösterir.

Birinci efsane: kurumsal DNS sunucuları bunu düzeltir

resolver dosyasını düzenlemek klasik tavsiyedir ve zamanın yaklaşık yarısında doğrudur. Doğru olduğunda belirli bir nedenden doğrudur: üretilen dosya yalnızca genel adları bilen bir resolver'ı işaret eder, bu yüzden intranet.example.internal için sorgu yol düzgün olsa bile yok olarak döner.

VPN'in sunucularını sabitlemek, Windows'un dosyayı yeniden üretmesini durdurmak anlamına gelir, çünkü elle yazdığınız her dosya bir sonraki başlatmada değiştirilir:

[network]
generateResolvConf = false

Bunu /etc/wsl.conf olarak kaydedin, Windows'tan wsl --shutdown çalıştırın, sonra dağıtımı başlatın ve /etc/resolv.conf dosyasını tünelin sunucuları önce, genel bir resolver yalnızca yedek olacak şekilde yazın. Bu, bakım maliyeti olan kalıcı bir değişikliktir: dosya artık ana makineyi izlemez, bu yüzden kurumsal DNS adresleri değiştiğinde dağıtım eskilerini sormaya devam eder. Birinin o dosyanın sahibi olması gerekir.

Arıza daha geniş olduğunda da hiçbir şey yapmaz. curl ile 1.1.1.1 arasında zaman aşımı olursa, tünel istemcisi sanal anahtarı filtreliyor veya VM'nin alt ağını tünele yönlendiriyordur ve doğru bir resolver size yalnızca hâlâ erişilemeyen adlar verir.

İkinci efsane: metrik değişikliği kalıcıdır

Adlar çözülüyor ama trafik fiziksel adaptörden çıkıyorsa kaldıraç arayüz metrikleridir. VPN adaptörüne yüksek maliyet, WSL anahtarına düşük maliyet verin:

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

Sonra birçok istemci derlemesinde tünel adaptörünün her bağlantıda yeniden oluşturulduğunu ve metriğin varsayılana döndüğünü unutmayın. Tek seferlik bir komut sessizce sona eren bir onarımdır, genellikle bir hafta sonu boyunca, ve bilet «geçen hafta çalışıyordu» ile geri gelir. VPN olayıyla tetiklenen zamanlanmış bir görev veya kullanıcının bağlandıktan sonra çalıştırdığı bir betik, bu onarımın dürüst sürümüdür.

Aynı son kullanma tarihi, tek bir inatçı önek için eklenen ana makine rotaları için de geçerlidir. Teşhis olarak değerlidirler, çünkü sorunun tek bir hedef mi yoksa tüm yol mu olduğunu söylerler, ama bir mimari değildirler.

Üçüncü efsane: tek onarım her Windows derlemesini kapsar

ApproachWhat it actually does
Resolver pinFixes private names only; no effect on path failures
Sidecar distributionForwards traffic over a socket to a helper VM, so the switch's filter no longer matters
Mirrored networkingGives the distribution the host's interface set; also enables DNS tunnelling

wsl-vpnkit sidecar desenidir: küçük bir dağıtım ana makine tarafındaki yolu sahiplenir ve diğer dağıtımlar için sanal bir soket üzerinden iletir, böylece uygulama trafiği filtrelenmiş anahtara bağımlı olmaktan çıkar. Standart yolun çalışması gerekir, yani networkingMode ve dnsTunneling geçersiz kılmalarını %UserProfile%\.wslconfig dosyasından kaldırıp, her çalışan dağıtımda generateResolvConf = true ayarını geri yükleyip hizmeti oturum açılışında başlatmak gerekir.

Yansıtmalı mod, Windows 11 22H2 ve sonrasındaki yerleşik alternatiftir ve tek bir ayar artı bir kapatmadır:

[wsl2]
networkingMode=mirrored

Dağıtımın içinde ip addr ardından ana makinenin adaptörlerini listeler, tünel bunların arasında görünebilir ve DNS tünelleme, istemci DNS listesini yeniden yazsa bile aramaları Windows resolver'ı üzerinden iletir. Evrensel değildir: bazı filtre sürücüleri yansıtmalı yolu hâlâ düşürür ve Hyper-V güvenlik duvarı kuralları açık bir izin gerektirebilir. Microsoft'un WSL ağ kılavuzu, daha yeni bir sürüm için yazılmış bir tarifi uygulamadan önce kendi derlemenizle karşılaştırmanız gereken sayfadır.

Her değişiklikten sonra üç şeyi test edin

Makine başına bir mekanizma seçin ve yazın, çünkü ikisi kötü birleşir. Yansıtmalı modun üzerine bir sidecar iletimi ikiye katlar ve .wslconfig içinde eski bir sidecar girdisi olan yansıtmalı ana makine yükseltmeden sonra başarısız olma eğilimindedir, önce değil.

Ne seçerseniz seçin, kabul testi dağıtımın içindeki aynı üç istektir: bir iç ad, bir genel ad ve bir ham adres. Sonra tüneli kesip yeniden bağladıktan sonra ve wsl --shutdown sonrasında bunları yineleyin. Yalnızca iç adın başarısız olması resolver politikasıdır; iç ve genel adların bir adres çalışırken birlikte başarısız olması hâlâ resolver politikasıdır; her şeyin başarısız olması yoldur.

Bir iç ana makine başarısız olup geri kalanı çalışıyorsa resolver'a bakmayı bırakın ve o önek için eksik bir rota arayın. Her şey bir sonraki yeniden bağlantıya kadar çalışıyorsa çalışma zamanı durumuna bağlı bir onarım buldunuz ve bunun otomatik olarak yeniden uygulanması veya yukarıdaki iki mekanizmadan biriyle değiştirilmesi gerekir.

İlgili makaleler