WSL2 berikt it VPN-subnet net: lês de rûte fan 'e host

De distribúsje sit efter syn eigen NAT en sjocht de Windows-tunnel nea. Lês it aktuele adres en foarheaksel fan 'e host en foegje se dan ta binnen WSL.

Fan binnen de distribúsje rint in ping nei in ynterne tsjinner ôf, wylst itselde adres fan Windows út antwurdet. De VPN is ferbûn en de Windows-rûte is goed, dus it gat is de WSL-grins. Rin it paad fan it mislearre kommando werom nei de host-ynterface. De oplossing is net in fêst CIDR yn in konfiguraasjebestân; it is it aktuele adres lêze en tafoegje dêr't de distribúsje it brûke kin.

Befêstigje wêr't it paad stopt

Rin deselde test oan beide kanten: los ien ynterne host op en ferbyn dy fan Windows út, en werhelje dat dan yn 'e distribúsje. In súkses yn Windows plus in timeout yn 'e distribúsje pleatst de flater tusken de beide, net yn 'e VPN-klient of de ynterne tsjinner. Doch dit foardatst jo in rûte feroarje, sadat de beide resultaten deselde bestimming beskriuwe.

Binnen de distribúsje lit ip -4 addr in firtuele adapter sjen mei in adres út it WSL NAT-berik, en ip route lit in standertrûte nei de WSL-gateway sjen. D'r is gjin rûte foar it bedriuwsfoarheaksel, om't de tunneladapter fan 'e host gjin tsjinhinger binnen de distribúsje hat. De standertgateway liedt nei it WSL NAT, net nei it bedriuwsnetwurk.

It bedriuwsrûte tafoegje sûnder earst in lokaal adres op in berikber keppeling ta te foegjen, jout in timeout of in netwurk net berikber-flater. It adres is it diel dat de rûte brûkber makket, dus lês it earst en behannelje de rûte as de twadde stap.

Kies spegele netwurk of in skriptearre rûte

Spegele netwurk jout de distribúsje de eigen ynterfaces fan 'e host, sadat de tunnel en syn rûtes ferskine sûnder kopiearjen. De funksje hinget ôf fan in resinte Windows-build en fan networkingMode=mirrored yn .wslconfig, en it ynskeakeljen feroaret net besibbe gedrach lykas localhost-oerdracht. Behannelje it as in platfoarmferoaring, net as in rûte-oanpassing. As de build it stipet en de byeffekten binne akseptabel, is it it koartste paad.

De smellere oanpak hâldt de standert NAT en kopiearret it tunneladres en de rûte yn 'e distribúsje eltse kear as de tunnel omheech komt. It wurket op mear builds, it feroaret it localhost-gedrach net, en it mislearret sichtber as de VPN del is. De kosten binne in lyts skript dat by elke ferbining rinne moat.

Kies ien en skriuw it op. It mingen fan in spegele konfiguraasje mei hânmjittige rûtes jout in distribúsje mei twa paden nei itselde foarheaksel en gjin dúdlike eigner foar ien fan beide. Ien dokumintearre metoade is makliker te debuggen as twa heal konfigurearre.

Helje de aktuele tunneldetails fan 'e host

Keppelje de adapter oan 'e MAC-adres ynstee fan 'e namme, om't nammen feroarje mei de VPN-klient en de ferbiningsoarder. List de adapters ien kear, notearje de MAC fan 'e tunneladapter en freegje dan syn adres en foarheaksel op. De MAC bliuwt by de firtuele adapter oer werferbiningen, wylst de namme en de ynterface-yndeks dat net dogge:

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

De gateway komt fan 'e ynterface-konfiguraasje. Helje earst de ynterface-yndeks op en lês dan de folgjende hop. De yndeks kin feroarje nei in werstart of in adapter-reset, dêrom moat it skript him lêze ynstee fan opslaan:

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

Laat de útfoer troch tr -d '\r' gean foardatst dy oan in fariabele tawlist. PowerShell einiget rigels mei in carriage return, en sûnder it strippen draacht it lêste fjild in ferburgen teken dat in rûtekommando mislearje lit mei in betiizjende parse-flater.

Pas it adres en de rûte ta binnen de distribúsje

Ynstallearje it tunneladres as in foarheaksel-kwalifisearre adres op 'e ynterface fan 'e distribúsje en rûte dan it bedriuwsblok troch de gateway fan 'e host:

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 smyt in hânmjittich konfigurearre adres fuort as de ferbining syklus, en gjin DHCP-klient freget om in ferfanging. Set de metoade op automatysk sadat elke werferbining it adres fernijt, en bring de ferbining dan wer omheech. In hânmjittige metoade liket stabyl oant de earste werferbining:

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

Rin beide stappen út 'e hook dy't de VPN start, net út in ynteraktive shell. In skript dat it adres lêst, it tafoeget, de rûte tafoeget en de wearden logt, makket in weromkommende hânmjittige reparaasje werhellber, en it log is it earste dat jo lêze moatte as it foarheaksel feroaret.

Fêstigje de namme en bewize it paad

De kernel kin de ynterface fan 'e distribúsje nei in netwurkskakeling tusken eth1 en eth2 omneame, en in skript skreaun tsjin in namme bewurket dan it ferkearde apparaat. In udev-regel keppele oan 'e MAC jout de ynterface in stabile label:

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

Ferifiearje dan mei it adres, de rûte en in echte TCP-ferbining: ip -4 addr show dev vpn, ip route get 172.20.4.10 en in ferbining nei in bekend yntern poart. It rûte-opsprekken soe it vpn-apparaat en it boarne-adres dat jo tafoege hawwe neame moatte.

As alle trije binnen de distribúsje slagje en de ferbining noch mislearret, ferlit it pakket WSL en wurdt it oan 'e Windows-kant weilitten. Kontrolearje de host-firewall en de eigen filtering fan 'e VPN-klient foardatst it skript feroarje, om't noch in rûte-oanpassing gjin pakket reparearret dat de host al berikt.

Relatearre artikelen