WSL2 ei jõua VPN-i alamvõrku: lugege hosti marsruuti

Distributsiooni seest lõpeb ping sisemisele serverile aegumisega, samal ajal kui sama aadress vastab Windowsist. VPN on ühendatud ja Windowsi marsruut on õige, seega on lünk WSL-i piir. Käige tee läbi ebaõnnestunud käsust tagasi hosti liideseni. Lahendus ei ole fikseeritud CIDR konfiguratsioonifailis; see on praeguse aadressi lugemine ja selle lisamine sinna, kus distributsioon saab seda kasutada.

Kinnitage, kus tee peatub

Käivitage sama test mõlemal pool: lahendage ja ühenduge Windowsist ühe sisemise hostiga, seejärel korrake seda distributsioonis. Õnnestumine Windowsis pluss aegumine distributsioonis paigutab tõrke nende vahele, mitte VPN-i kliendisse ega sisemisse serverisse. Tehke seda enne mis tahes marsruudi muutmist, et mõlemad tulemused kirjeldaksid sama sihtkohta.

Distributsiooni sees näitab ip -4 addr virtuaalset adapterit, mille aadress on WSL-i NAT-i vahemikust, ja ip route näitab vaikimisi marsruuti WSL-i lüüsini. Ettevõtte prefiksi jaoks marsruuti ei ole, sest hosti tunneliladapteril puudub distributsiooni sees vaste. Vaikimisi lüüs viib WSL-i NAT-i, mitte ettevõtte võrku.

Ettevõtte marsruudi lisamine ilma, et enne lisataks kohalik aadress kättesaadavale lingile, annab aegumise või võrgu kättesaamatuse vea. Aadress on see osa, mis muudab marsruudi kasutatavaks, seega lugege see enne ja käsitlege marsruuti teise sammuna.

Valige peegeldatud võrk või skriptitud marsruut

Peegeldatud võrk annab distributsioonile hosti enda liidesed, nii et tunnel ja selle marsruudid ilmuvad ilma kopeerimiseta. Funktsioon sõltub uuemast Windowsi buildist ja networkingMode=mirrored-st .wslconfig failis, ning selle lubamine muudab mitteseotud käitumist, näiteks localhosti edastamist. Käsitlege seda platvormi muudatusena, mitte marsruudi häälestusena. Kui build seda toetab ja kõrvalmõjud on vastuvõetavad, on see lühim tee.

Kitsam lähenemine hoiab vaikimisi NAT-i ja kopeerib tunneli aadressi ja marsruudi distributsiooni alati, kui tunnel tõuseb. See töötab rohkematel buildidel, ei muuda localhosti käitumist ja ebaõnnestub nähtavalt, kui VPN on maas. Hinnaks on väike skript, mida tuleb käivitada iga ühenduse korral.

Valige üks ja kirjutage see üles. Peegeldatud konfiguratsiooni segamine käsitsi marsruutidega annab distributsiooni, millel on sama prefiksi juurde kaks teed ja kummalgi pole selget omanikku. Üht dokumenteeritud meetodit on lihtsam siluda kui kahte pooleldi seadistatut.

Tõmmake hostist praegused tunneli andmed

Sobitage adapterit MAC-aadressi, mitte nime järgi, sest nimed muutuvad koos VPN-i kliendi ja ühenduse järjekorraga. Loetlege adapterid üks kord, märkige tunneliadapteri MAC ja seejärel küsige selle aadressi ja prefiksit. MAC jääb virtuaaladapteriga ühenduste vahel, nimi ja liidese indeks mitte:

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

Lüüs tuleb liidese konfiguratsioonist. Hankige esmalt liidese indeks ja lugege seejärel järgmine hüpe. Indeks võib muutuda pärast taaskäivitust või adapteri lähtestamist, mistõttu peaks skript seda lugema, mitte salvestama:

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

Suunake väljund läbi tr -d '\r' enne, kui omistate selle muutujale. PowerShell lõpetab read reavahetuse märgiga ja ilma eemaldamiseta kannab viimane väli peidetud märki, mis paneb marsruudikäsu ebaõnnestuma segase parsitõrkega.

Rakendage aadress ja marsruut distributsiooni sees

Installige tunneli aadress prefiksiga aadressina distributsiooni liidesele ja suunake seejärel ettevõtte plokk hosti lüüsi kaudu:

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 viskab käsitsi konfigureeritud aadressi ära, kui ühendus tsükliliselt taastub, ja ükski DHCP-klient ei küsi asendust. Seadke meetod automaatseks, et iga uus ühendus värskendaks aadressi, ja seejärel tõstke ühendus uuesti üles. Käsitsi meetod tundub stabiilne kuni esimese uue ühenduseni:

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

Käivitage mõlemad sammud VPN-i käivitavast konksust, mitte interaktiivsest kestast. Skript, mis loeb aadressi, lisab selle, lisab marsruudi ja logib väärtused, muudab korduva käsitsi paranduse korratavaks, ja logi on esimene asi, mida lugeda, kui prefiks muutub.

Kinnitage nimi ja tõestage tee

Kernel võib pärast võrguvahetust distributsiooni liidese nime eth1 ja eth2 vahel muuta ning nime järgi kirjutatud skript muudab siis vale seadet. MAC-iga seotud udev reegel annab liidesele stabiilse sildi:

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

Seejärel kontrollige aadressi, marsruudi ja tegeliku TCP-ühendusega: ip -4 addr show dev vpn, ip route get 172.20.4.10 ja ühendus tuntud sisemise pordiga. Marsruudi otsing peaks nimetama vpn seadet ja lisatud lähteaadressi.

Kui kõik kolm läbivad distributsiooni sees ja ühendus ikka ebaõnnestub, väljub pakett WSL-ist ja visatakse Windowsi poolel ära. Kontrollige hosti tulemüüri ja VPN-i kliendi enda filtreerimist enne skripti muutmist, sest veel üks marsruudi muudatus ei paranda paketti, mis juba hostini jõuab.