WSL2 nu ajunge la subrețeaua VPN: citiți ruta gazdei

Din interiorul distribuției, un ping către un server intern expiră, în timp ce aceeași adresă răspunde din Windows. VPN-ul este conectat și ruta Windows este corectă, deci golul este granița WSL. Parcurgeți calea de la comanda care eșuează înapoi la interfața gazdei. Remedierea nu este un CIDR fix într-un fișier de configurare; este citirea adresei curente și adăugarea ei acolo unde distribuția o poate folosi.

Confirmați unde se oprește calea

Rulați același test pe ambele părți: rezolvați și conectați-vă la o gazdă internă din Windows, apoi repetați în distribuție. Un succes în Windows plus un timeout în distribuție localizează defectul între cele două, nu în clientul VPN sau în serverul intern. Faceți acest lucru înainte de a schimba orice rută, ca ambele rezultate să descrie aceeași destinație.

În interiorul distribuției, ip -4 addr arată un adaptor virtual cu o adresă din intervalul NAT al WSL, iar ip route arată o rută implicită către gateway-ul WSL. Nu există rută pentru prefixul corporativ, pentru că adaptorul de tunel al gazdei nu are un echivalent în distribuție. Gateway-ul implicit duce la NAT-ul WSL, nu la rețeaua corporativă.

Adăugarea rutei corporative fără a adăuga mai întâi o adresă locală pe o legătură accesibilă produce un timeout sau o eroare de rețea inaccesibilă. Adresa este partea care face ruta utilizabilă, așa că citiți-o mai întâi și tratați ruta ca al doilea pas.

Alegeți rețeaua oglindită sau o rută cu script

Rețeaua oglindită oferă distribuției interfețele gazdei însăși, astfel încât tunelul și rutele sale apar fără copiere. Funcția depinde de o versiune recentă Windows și de networkingMode=mirrored în .wslconfig, iar activarea ei schimbă comportamente nelegate, cum ar fi redirecționarea localhost. Tratați-o ca o schimbare de platformă, nu ca o ajustare de rută. Dacă versiunea o acceptă și efectele secundare sunt acceptabile, este cea mai scurtă cale.

Abordarea mai îngustă păstrează NAT-ul implicit și copiază adresa și ruta tunelului în distribuție de fiecare dată când tunelul urcă. Funcționează pe mai multe versiuni, nu schimbă comportamentul localhost și eșuează vizibil când VPN-ul este oprit. Costul este un script mic care trebuie rulat la fiecare conectare.

Alegeți unul și scrieți-l. Amestecarea unei configurații oglindite cu rute manuale produce o distribuție cu două căi către același prefix și fără un proprietar clar pentru niciuna. O singură metodă documentată este mai ușor de depanat decât două pe jumătate configurate.

Extrageți detaliile curente ale tunelului de la gazdă

Potriviți adaptorul după adresa MAC, nu după nume, pentru că numele se schimbă cu clientul VPN și cu ordinea conectării. Listați adaptoarele o dată, notați MAC-ul adaptorului de tunel, apoi interogați adresa și prefixul acestuia. MAC-ul rămâne cu adaptorul virtual între reconectări, în timp ce numele și indexul interfeței nu:

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

Gateway-ul provine din configurația interfeței. Obțineți mai întâi indexul interfeței, apoi citiți următorul salt. Indexul se poate schimba după o repornire sau o resetare a adaptorului, de aceea scriptul ar trebui să îl citească în loc să îl stocheze:

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

Treceți ieșirea prin tr -d '\r' înainte de a o atribui unei variabile. PowerShell termină liniile cu un carriage return, iar fără eliminare ultimul câmp poartă un caracter ascuns care face o comandă de rută să eșueze cu o eroare de analiză confuză.

Aplicați adresa și ruta în interiorul distribuției

Instalați adresa tunelului ca adresă cu prefix pe interfața distribuției, apoi rutați blocul corporativ prin gateway-ul gazdei:

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 aruncă o adresă configurată manual când conexiunea se reia, iar niciun client DHCP nu cere un înlocuitor. Setați metoda pe automat pentru ca fiecare reconectare să reîmprospăteze adresa, apoi ridicați din nou conexiunea. Metoda manuală pare stabilă până la prima reconectare:

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

Rulați ambii pași din hook-ul care pornește VPN-ul, nu dintr-un shell interactiv. Un script care citește adresa, o adaugă, adaugă ruta și înregistrează valorile transformă o reparație manuală recurentă într-una repetabilă, iar jurnalul este primul lucru de citit când prefixul se schimbă.

Fixați numele și demonstrați calea

Kernelul poate redenumi interfața distribuției între eth1 și eth2 după o schimbare de rețea, iar un script scris pentru un nume editează atunci dispozitivul greșit. O regulă udev legată de MAC oferă interfeței o etichetă stabilă:

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

Apoi verificați cu adresa, ruta și o conexiune TCP reală: ip -4 addr show dev vpn, ip route get 172.20.4.10 și o conexiune la un port intern cunoscut. Căutarea rutei ar trebui să numească dispozitivul vpn și adresa sursă pe care ați adăugat-o.

Dacă toate trei trec în interiorul distribuției și conexiunea încă eșuează, pachetul părăsește WSL și este aruncat pe partea Windows. Verificați firewall-ul gazdei și filtrarea clientului VPN înainte de a schimba scriptul, pentru că o altă modificare de rută nu va repara un pachet care ajunge deja la gazdă.