WSL2 VPN alt ağına ulaşamıyor: ana makinenin rotasını okuyun

Dağıtım kendi NAT'ının arkasında oturur ve Windows tünelini hiç görmez. Geçerli adresi ve öneki ana makineden okuyun, ardından bunları WSL içine ekleyin.

Dağıtımın içinden dahili bir sunucuya ping zaman aşımına uğrarken aynı adres Windows'tan yanıt veriyor. VPN bağlı ve Windows rotası doğru, yani boşluk WSL sınırı. Yolu başarısız komuttan ana makinenin arayüzüne kadar izleyin. Düzeltme, yapılandırma dosyasındaki sabit bir CIDR değil; geçerli adresi okuyup dağıtımın kullanabileceği yere eklemektir.

Yolun nerede durduğunu doğrulayın

Aynı testi iki tarafta da çalıştırın: Windows'tan bir dahili ana makineyi çözümleyip bağlanın, sonra bunu dağıtımda yineleyin. Windows'taki başarı artı dağıtımdaki zaman aşımı, arızayı ikisinin arasına yerleştirir, VPN istemcisine veya dahili sunucuya değil. Herhangi bir rotayı değiştirmeden önce bunu yapın, böylece iki sonuç aynı hedefi tanımlasın.

Dağıtımın içinde ip -4 addr WSL NAT aralığından bir adrese sahip sanal bağdaştırıcıyı gösterir ve ip route WSL ağ geçidine işaret eden varsayılan rotayı gösterir. Kurumsal önek için rota yoktur, çünkü ana makinenin tünel bağdaştırıcısının dağıtım içinde bir karşılığı yoktur. Varsayılan ağ geçidi WSL NAT'a gider, kurumsal ağa değil.

Kurumsal rotayı önce erişilebilir bir bağlantı üzerinde yerel adres eklemeden eklemek zaman aşımına veya ağa ulaşılamıyor hatasına yol açar. Rotayı kullanılabilir kılan kısım adrestir, bu yüzden önce onu okuyun ve rotayı ikinci adım olarak ele alın.

Yansıtılmış ağı veya betikli rotayı seçin

Yansıtılmış ağ, dağıtıma ana makinenin kendi arayüzlerini verir, böylece tünel ve rotaları kopyalamadan görünür. Özellik yeni bir Windows derlemesine ve .wslconfig içindeki networkingMode=mirrored ayarına bağlıdır ve etkinleştirilmesi localhost yönlendirmesi gibi ilgisiz davranışları değiştirir. Bunu rota ince ayarı değil, platform değişikliği olarak görün. Derleme destekliyorsa ve yan etkiler kabul edilebilirse en kısa yoldur.

Daha dar yaklaşım varsayılan NAT'ı korur ve tünel her açıldığında tünelin adresini ve rotasını dağıtıma kopyalar. Daha fazla derlemede çalışır, localhost davranışını değiştirmez ve VPN kapalıyken görünür şekilde başarısız olur. Bedeli her bağlantıda çalıştırılması gereken küçük bir betiktir.

Birini seçin ve yazın. Yansıtılmış bir yapılandırmayı elle yazılmış rotalarla karıştırmak, aynı öneke iki yolu olan ve hiçbirinin sahibi belirsiz bir dağıtım üretir. Belgelenmiş tek bir yöntemin hata ayıklaması, yarı yapılandırılmış iki yöntemden daha kolaydır.

Geçerli tünel ayrıntılarını ana makineden alın

Bağdaştırıcıyı adla değil MAC adresiyle eşleştirin, çünkü adlar VPN istemcisiyle ve bağlantı sırasıyla değişir. Bağdaştırıcıları bir kez listeleyin, tünel bağdaştırıcısının MAC'ini not edin, sonra adresini ve önekini sorun. MAC yeniden bağlanmalar arasında sanal bağdaştırıcıda kalır, ad ve arayüz dizini kalmaz:

powershell.exe 'Get-NetAdapter | Where-Object { $_.MacAddress -eq "3C-52-82-0A-1B-7C" } | Get-NetIPAddress -AddressFamily IPv4 | Select-Object IPAddress, PrefixLength'

Ağ geçidi arayüz yapılandırmasından gelir. Önce arayüz dizinini alın, sonra sonraki atlamayı okuyun. Dizin yeniden başlatma veya bağdaştırıcı sıfırlamasından sonra değişebilir, bu yüzden betik onu saklamak yerine okumalıdır:

powershell.exe '(Get-NetAdapter | Where-Object { $_.MacAddress -eq "3C-52-82-0A-1B-7C" }).InterfaceIndex'
powershell.exe '(Get-NetIPConfiguration -InterfaceIndex 27).IPv4DefaultGateway.NextHop'

Çıktıyı bir değişkene atamadan önce tr -d '\r' üzerinden geçirin. PowerShell satırları satır başı karakteriyle bitirir ve bu kaldırılmazsa son alan, rota komutunun kafa karıştırıcı bir ayrıştırma hatasıyla başarısız olmasına yol açan gizli bir karakter taşır.

Adresi ve rotayı dağıtımın içinde uygulayın

Tünelin adresini dağıtımın arayüzüne önekli adres olarak kurun, ardından kurumsal bloğu ana makinenin ağ geçidi üzerinden yönlendirin:

sudo ip addr add 172.20.14.37/22 dev vpn
sudo ip route add 172.20.0.0/16 via 172.20.12.1 dev vpn

NetworkManager, bağlantı döngüye girdiğinde elle yapılandırılmış adresi bırakır ve hiçbir DHCP istemcisi yedek istemez. Yöntemi otomatiğe ayarlayın ki her yeniden bağlanma adresi yenilesin, sonra bağlantıyı yeniden yükseltin. Elle yöntem ilk yeniden bağlanmaya kadar kararlı görünür:

nmcli con show vpn
sudo nmcli con mod vpn ipv4.method auto
sudo nmcli con up vpn

İki adımı da VPN'i başlatan kancadan çalıştırın, etkileşimli kabuktan değil. Adresi okuyan, ekleyen, rotayı ekleyen ve değerleri günlüğe yazan bir betik, yinelenen elle onarımı yinelenebilir hale getirir ve önek değiştiğinde ilk okunacak şey günlüktür.

Adı sabitleyin ve yolu kanıtlayın

Çekirdek, ağ değişiminden sonra dağıtımın arayüz adını eth1 ile eth2 arasında değiştirebilir ve ada göre yazılmış bir betik o zaman yanlış aygıtı düzenler. MAC'e bağlı bir udev kuralı arayüze kararlı bir etiket verir:

SUBSYSTEM=="net", ACTION=="add", ATTRS{address}=="3c:52:82:0a:1b:7c", NAME="vpn"

Sonra adres, rota ve gerçek bir TCP bağlantısıyla doğrulayın: ip -4 addr show dev vpn, ip route get 172.20.4.10 ve bilinen bir dahili bağlantı noktasına bağlantı. Rota araması vpn aygıtını ve eklediğiniz kaynak adresini adlandırmalıdır.

Üçü de dağıtımın içinde geçer ve bağlantı yine başarısız olursa, paket WSL'den çıkıyor ve Windows tarafında düşürülüyor. Betiği değiştirmeden önce ana makinenin güvenlik duvarını ve VPN istemcisinin kendi filtrelemesini denetleyin, çünkü bir rota düzenlemesi daha ana makineye zaten ulaşan bir paketi düzeltmez.

İlgili makaleler