WSL2 bereik nie die VPN-subnet nie: lees die gasheerroete

Van binne die verspreiding verstryk 'n ping na 'n interne bediener terwyl dieselfde adres van Windows af antwoord. Die VPN is gekoppel en die Windows-roete is korrek, so die gaping is die WSL-grens. Stap die pad van die mislukte opdrag terug na die gasheerkoppelvlak. Die oplossing is nie 'n vaste CIDR in 'n konfigurasielêer nie; dit is om die huidige adres te lees en by te voeg waar die verspreiding dit kan gebruik.

Bevestig waar die pad stop

Voer dieselfde toets aan beide kante uit: los een interne gasheer vanaf Windows op en koppel daaraan, en herhaal dit dan in die verspreiding. 'n Sukses in Windows plus 'n verstryking in die verspreiding plaas die fout tussen die twee, nie in die VPN-kliënt of die interne bediener nie. Doen dit voordat jy enige roete verander, sodat die twee resultate dieselfde bestemming beskryf.

Binne die verspreiding wys ip -4 addr 'n virtuele adapter met 'n adres uit die WSL NAT-reeks, en ip route wys 'n verstekroete na die WSL-hek. Daar is geen roete vir die korporatiewe voorvoegsel nie, want die gasheer se tonneladapter het geen eweknie binne die verspreiding nie. Die verstekhek lei na die WSL NAT, nie na die korporatiewe netwerk nie.

Om die korporatiewe roete by te voeg sonder om eers 'n plaaslike adres op 'n bereikbare skakel by te voeg, lewer 'n verstryking of 'n netwerk-onbereikbare fout. Die adres is die deel wat die roete bruikbaar maak, so lees dit eerste en behandel die roete as die tweede stap.

Kies spieëlnetwerk of 'n geskripteerde roete

Spieëlnetwerk gee die verspreiding die gasheer se eie koppelvlakke, so die tonnel en sy roetes verskyn sonder om te kopieer. Die kenmerk hang af van 'n onlangse Windows-bou en van networkingMode=mirrored in .wslconfig, en om dit te aktiveer verander onverwante gedrag soos localhost-aanstuur. Behandel dit as 'n platformverandering, nie 'n roete-aanpassing nie. As die bou dit ondersteun en die newe-effekte aanvaarbaar is, is dit die kortste pad.

Die smaller benadering hou die verstek NAT en kopieer die tonneladres en roete in die verspreiding wanneer die tonnel opkom. Dit werk op meer bousels, dit verander nie localhost-gedrag nie, en dit misluk sigbaar wanneer die VPN af is. Die koste is 'n klein skrip wat by elke koppeling moet loop.

Kies een en skryf dit neer. Om 'n spieëlkonfigurasie met handmatige roetes te meng, lewer 'n verspreiding met twee paaie na dieselfde voorvoegsel en geen duidelike eienaar vir enigeen nie. Een gedokumenteerde metode is makliker om te ontfout as twee halfgekonfigureerde metodes.

Haal die huidige tonnelbesonderhede by die gasheer

Pas die adapter by MAC-adres eerder as by naam, want name verander met die VPN-kliënt en die koppelingsorde. Lys die adapters een keer, let op die tonneladapter se MAC en vra dan sy adres en voorvoegsel op. Die MAC bly by die virtuele adapter oor herkoppelings, terwyl die naam en die koppelvlakindeks dit nie doen nie:

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

Die hek kom uit die koppelvlakkonfigurasie. Haal eers die koppelvlakindeks op en lees dan die volgende sprong. Die indeks kan verander na 'n herbegin of 'n adapterherstelling, daarom moet die skrip dit lees eerder as om dit te stoor:

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

Lei die uitvoer deur tr -d '\r' voordat jy dit aan 'n veranderlike toewys. PowerShell beëindig reëls met 'n karretjie-terugkeer, en sonder die strook dra die laaste veld 'n verborge karakter wat 'n roeteopdrag met 'n verwarrende ontledingsfout laat misluk.

Pas die adres en roete binne die verspreiding toe

Installeer die tonneladres as 'n voorvoegselgekwalifiseerde adres op die verspreiding se koppelvlak en roeteer dan die korporatiewe blok deur die gasheer se hek:

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 laat 'n handmatig gekonfigureerde adres val wanneer die verbinding siklus, en geen DHCP-kliënt vra 'n vervanging nie. Stel die metode op outomaties sodat elke herkoppeling die adres verfris, en bring die verbinding dan weer op. 'n Handmatige metode lyk stabiel tot die eerste herkoppeling:

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

Voer albei stappe uit die haak uit wat die VPN begin, nie uit 'n interaktiewe dop nie. 'n Skrip wat die adres lees, dit byvoeg, die roete byvoeg en die waardes log, maak 'n herhalende handmatige herstelling herhaalbaar, en die log is die eerste ding om te lees wanneer die voorvoegsel verander.

Pen die naam vas en bewys die pad

Die kernel kan die verspreiding se koppelvlak tussen eth1 en eth2 hernoem ná 'n netwerkskakelaar, en 'n skrip wat teen 'n naam geskryf is, redigeer dan die verkeerde toestel. 'n udev-reël wat op die MAC gesleutel is, gee die koppelvlak 'n stabiele etiket:

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

Verifieer dan met die adres, die roete en 'n werklike TCP-verbinding: ip -4 addr show dev vpn, ip route get 172.20.4.10 en 'n verbinding na 'n bekende interne poort. Die roete-opsoek behoort die vpn-toestel en die bronadres wat jy bygevoeg het, te noem.

As al drie binne die verspreiding slaag en die verbinding steeds misluk, verlaat die pakkie WSL en word dit aan die Windows-kant laat val. Kontroleer die gasheer se vuurmuur en die VPN-kliënt se eie filtering voordat jy die skrip verander, want nog 'n roetewysiging sal nie 'n pakkie regstel wat reeds die gasheer bereik nie.