WSL2 nuk arrin në nënrrjetin VPN: lexoni rrugën e hostit

Nga brenda shpërndarjes, një ping drejt një serveri të brendshëm skadon, ndërsa e njëjta adresë përgjigjet nga Windows. VPN është i lidhur dhe rruga e Windows është e saktë, pra hendeku është kufiri i WSL. Përshkoni rrugën nga komanda që dështon përsëri te ndërfaqja e hostit. Rregullimi nuk është një CIDR fiks në një skedar konfigurimi; është leximi i adresës aktuale dhe shtimi i saj atje ku shpërndarja mund ta përdorë.

Konfirmoni ku ndalon rruga

Kryeni të njëjtin test në të dyja anët: zgjidhni dhe lidhuni me një host të brendshëm nga Windows, pastaj përsëriteni në shpërndarje. Një sukses në Windows plus një skadim në shpërndarje e lokalizon defektin midis të dyjave, jo në klientin VPN ose në serverin e brendshëm. Bëjeni këtë përpara se të ndryshoni ndonjë rrugë, që të dy rezultatet të përshkruajnë të njëjtin destinacion.

Brenda shpërndarjes, ip -4 addr tregon një përshtatës virtual me një adresë nga diapazoni NAT i WSL, dhe ip route tregon një rrugë të paracaktuar drejt portës së WSL. Nuk ka rrugë për prefiksin korporativ, sepse përshtatësi i tunelit të hostit nuk ka homolog brenda shpërndarjes. Porta e paracaktuar çon në NAT-in e WSL, jo në rrjetin korporativ.

Shtimi i rrugës korporative pa shtuar më parë një adresë lokale në një lidhje të arritshme prodhon një skadim ose një gabim rrjeti të paarritshëm. Adresa është pjesa që e bën rrugën të përdorshme, prandaj lexojeni së pari dhe trajtojeni rrugën si hapin e dytë.

Zgjidhni rrjet të pasqyruar ose rrugë me skript

Rrjeti i pasqyruar i jep shpërndarjes ndërfaqet e vetë hostit, kështu që tuneli dhe rrugët e tij shfaqen pa kopjuar. Funksioni varet nga një ndërtim i ri i Windows dhe nga networkingMode=mirrored në .wslconfig, dhe aktivizimi i tij ndryshon sjellje të palidhura si përcjellja e localhost. Trajtojeni si ndryshim platforme, jo si rregullim rruge. Nëse ndërtimi e mbështet dhe efektet anësore janë të pranueshme, është rruga më e shkurtër.

Qasja më e ngushtë mban NAT-in e paracaktuar dhe kopjon adresën dhe rrugën e tunelit në shpërndarje sa herë që tuneli ngrihet. Funksionon në më shumë ndërtime, nuk ndryshon sjelljen e localhost dhe dështon dukshëm kur VPN është i fikur. Kostoja është një skript i vogël që duhet ekzekutuar në çdo lidhje.

Zgjidhni një dhe shkruajeni. Përzierja e një konfigurimi të pasqyruar me rrugë manuale prodhon një shpërndarje me dy shtigje drejt të njëjtit prefiks dhe pa pronar të qartë për asnjërën. Një metodë e dokumentuar është më e lehtë për t'u korrigjuar se dy gjysmë të konfiguruara.

Merrni detajet aktuale të tunelit nga hosti

Përputhni përshtatësin sipas adresës MAC dhe jo sipas emrit, sepse emrat ndryshojnë me klientin VPN dhe rendin e lidhjes. Listoni përshtatësit një herë, shënoni MAC-in e përshtatësit të tunelit, pastaj kërkoni adresën dhe prefiksin e tij. MAC-i mbetet me përshtatësin virtual midis rilidhjeve, ndërsa emri dhe indeksi i ndërfaqes nuk mbeten:

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

Porta vjen nga konfigurimi i ndërfaqes. Merrni së pari indeksin e ndërfaqes, pastaj lexoni hopin e radhës. Indeksi mund të ndryshojë pas një rindezjeje ose rivendosjeje të përshtatësit, prandaj skripti duhet ta lexojë dhe jo ta ruajë:

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

Kalojani daljen përmes tr -d '\r' përpara se t'ia caktoni një ndryshoreje. PowerShell i përfundon rreshtat me carriage return, dhe pa heqjen fusha e fundit mbart një karakter të fshehur që e bën një komandë rruge të dështojë me një gabim analize konfuz.

Aplikoni adresën dhe rrugën brenda shpërndarjes

Instaloni adresën e tunelit si adresë me prefiks në ndërfaqen e shpërndarjes, pastaj drejtoni bllokun korporativ përmes portës së hostit:

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 hedh një adresë të konfiguruar me dorë kur lidhja riciklohet, dhe asnjë klient DHCP nuk kërkon zëvendësues. Vendoseni metodën në automatike që çdo rilidhje të rifreskojë adresën, pastaj ngrini përsëri lidhjen. Metoda manuale duket e qëndrueshme deri në rilidhjen e parë:

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

Kryeni të dy hapat nga hook-u që nis VPN-in, jo nga një shell interaktiv. Një skript që lexon adresën, e shton, shton rrugën dhe regjistron vlerat e kthen një riparim manual të përsëritur në të përsëritshëm, dhe regjistri është gjëja e parë që lexohet kur prefiksi ndryshon.

Fiksoni emrin dhe provoni rrugën

Kerneli mund ta riemërtojë ndërfaqen e shpërndarjes midis eth1 dhe eth2 pas një ndryshimi rrjeti, dhe një skript i shkruar për një emër atëherë redakton pajisjen e gabuar. Një rregull udev i lidhur me MAC-in i jep ndërfaqes një etiketë të qëndrueshme:

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

Pastaj verifikoni me adresën, rrugën dhe një lidhje reale TCP: ip -4 addr show dev vpn, ip route get 172.20.4.10 dhe një lidhje me një port të brendshëm të njohur. Kërkimi i rrugës duhet të emërtojë pajisjen vpn dhe adresën burimore që keni shtuar.

Nëse të treja kalojnë brenda shpërndarjes dhe lidhja vazhdon të dështojë, paketa po largohet nga WSL dhe po hidhet në anën e Windows. Kontrolloni firewall-in e hostit dhe filtrimin e vetë klientit VPN përpara se të ndryshoni skriptin, sepse një redaktim tjetër rruge nuk do të rregullojë një paketë që tashmë po arrin te hosti.