WSL2 erreecht de VPN-Subnetz net: liest d'Host-Route

D'Distributioun sëtzt hannert hirem eegenen NAT a gesäit den Windows-Tunnel ni. Liest déi aktuell Adress an de Prefix vum Host a füügt se dann an WSL dobäi.

Vun der Distributioun aus leeft e Ping op en internen Server an en Timeout, während déi selwecht Adress vun Windows aus äntwert. De VPN ass verbonnen an d'Windows-Route ass richteg, also ass d'Lück d'WSL-Grenz. Gitt de Wee vum gescheiterten Kommando zréck op d'Host-Schnittstell. D'Léisung ass keen fixe CIDR an enger Konfiguratiounsdatei; se besteet doran, déi aktuell Adress ze liesen an se dobäizesetzen, wou d'Distributioun se ka benotzen.

Bestätegt, wou de Wee ophält

Fëllt dee selwechten Test op béide Säiten duerch: léist en internen Host vun Windows aus op a verbënnt Iech, a widderhëlt dat dann an der Distributioun. En Erfolleg an Windows plus en Timeout an der Distributioun lokaliséiert de Fehler tëscht béiden, net am VPN-Client oder am internen Server. Maacht dat, ier Dir eng Route ännert, sou datt déi zwou Resultater déiselwecht Destinatioun beschreiwen.

An der Distributioun weist ip -4 addr en virtuelle Adapter mat enger Adress aus dem WSL-NAT-Beräich, an ip route weist eng Standardroute op de WSL-Gateway. Et gëtt keng Route fir de Betribsprefix, well den Tunneladapter vum Host keen Äquivalent an der Distributioun huet. De Standardgateway féiert op den WSL-NAT, net op de Betribsnetz.

D'Betribsroute dobäisetzen, ouni virdrun eng lokal Adress op enger erreechbarer Verbindung dobäizesetzen, ergëtt en Timeout oder e Fehler vun onerreechbarem Netz. D'Adress ass den Deel, deen d'Route benotzbar mécht, also liest se als éischt a behandelt d'Route als zweeten Schrëtt.

Wielt gespigelt Netzwierk oder eng skriptéiert Route

Gespigelt Netzwierk gëtt der Distributioun dem Host seng eege Schnittstellen, sou datt den Tunnel a seng Routen ouni Kopéiere erschéngen. D'Funktioun hänkt vun engem rezenten Windows-Build an networkingMode=mirrored an .wslconfig of, an hir Aktivéierung ännert onverbonnen Verhalen wéi d'Weiterleede vu localhost. Behandelt et als Plattformännerung, net als Route-Feinastellung. Wann de Build et ënnerstëtzt an d'Nieweneffekter akzeptabel sinn, ass et de kierzten Wee.

De méi enke Virgo huet den Standard-NAT bäi a kopéiert d'Tunneladress an d'Route an d'Distributioun, all Kéier wann den Tunnel eropkënnt. En funktionéiert op méi Builds, ännert d'localhost-Verhalen net, a versot sichtbar, wann de VPN aus ass. De Präis ass e klengt Skript, dat bei all Verbindung misst lafen.

Wielt eng a schreift se op. Eng gespigelt Konfiguratioun mat manuelle Route mëschen ergëtt eng Distributioun mat zwee Weeër op dee selwechte Prefix an ouni kloeren Eegentümer fir jiddwereen. Eng dokumentéiert Method ass méi einfach ze debuggen wéi zwou hallef konfiguréiert.

Huelt déi aktuell Tunneldaten vum Host

Passt den Adapter op d'MAC-Adress un, net op den Numm, well Nimm sech mam VPN-Client an der Verbindungsuerdnung änneren. Lëscht d'Adapter eng Kéier op, notéiert d'MAC vum Tunneladapter, a frot dann seng Adress an de Prefix. D'MAC bleift iwwer Neiverbindungen beim virtuelle Adapter, den Numm an den Interface-Index awer net:

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

De Gateway kënnt aus der Interface-Konfiguratioun. Huelt fir d'éischt den Interface-Index a liest dann den nächsten Hop. Den Index kann sech no engem Neistart oder engem Adapter-Reset änneren, dofir soll d'Skript en liesen an net späicheren:

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

Leet d'Ausgab duerch tr -d '\r', ier Dir se enger Variabel zouweist. PowerShell beendet Zeilen mat engem Carriage Return, an ouni d'Strippe dréit dat lescht Feld en verstoppt Zeechen, dat e Route-Kommando mat engem verwirrenden Parse-Fehler versoe léisst.

Wend d'Adress an d'Route an der Distributioun un

Installéiert d'Tunneladress als prefixqualifizéiert Adress op der Schnittstell vun der Distributioun a routet dann de Betribsblock iwwer de Gateway vum 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 verwërft eng manuell konfiguréiert Adress, wann d'Verbindung zykléiert, an et gëtt keen DHCP-Client, deen en Ersatz freet. Setzt d'Method op automatesch, sou datt all Neiverbindung d'Adress aktualiséiert, a bréngt d'Verbindung duerno erëm erop. Eng manuell Method gesäit stabil aus bis zur éischter Neiverbindung:

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

Fëllt béid Schrëtt aus dem Hook aus, deen de VPN start, net aus enger interaktiver Shell. En Skript, dat d'Adress liest, se dobäisetzt, d'Route dobäisetzt an d'Wäerter logt, mécht eng widderhuelend manuell Reparatur zu enger widderhuelbarer, an de Log ass dat Éischt, wat ee liest, wann de Prefix sech ännert.

Fixéiert den Numm a beweist de Wee

De Kernel kann d'Schnittstell vun der Distributioun no engem Netzwierkwiessel tëscht eth1 an eth2 ëmbenennen, an en Skript, dat op en Numm geschriwwe gouf, ännert dann dat falscht Gerät. Eng udev-Regel, déi un d'MAC gebonnen ass, gëtt der Schnittstell eng stabil Etikett:

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

Verifizéiert duerno mat der Adress, der Route an enger richteger TCP-Verbindung: ip -4 addr show dev vpn, ip route get 172.20.4.10 an eng Verbindung op en bekannten internen Port. D'Route-Sich sollt de vpn-Gerät an d'Quelladress nennen, déi Dir dobäigesat hutt.

Wann all dräi an der Distributioun duerchginn an d'Verbindung nach ëmmer versot, verléisst de Paket WSL a gëtt op der Windows-Säit verworf. Kontrolléiert d'Host-Firewall an dem VPN-Client seng eege Filterung, ier Dir d'Skript ännert, well nach eng Route-Ännerung kee Paket reparéiert, deen den Host schonn erreecht.

Ähnlech Artikelen