A WSL2 nem éri el a VPN alhálózatot: olvassa ki a gazda útvonalát

A disztribúció belsejéből egy belső kiszolgálóra küldött ping időtúllépéssel ér véget, miközben ugyanaz a cím a Windowsból válaszol. A VPN csatlakozva van, és a Windows útvonala helyes, tehát a rés a WSL határa. Járja végig az utat a sikertelen parancstól vissza a gazda interfészéig. A javítás nem egy rögzített CIDR a konfigurációs fájlban; hanem az aktuális cím kiolvasása és hozzáadása ott, ahol a disztribúció használni tudja.

Erősítse meg, hol áll meg az útvonal

Futtassa ugyanazt a tesztet mindkét oldalon: oldjon fel és csatlakozzon egy belső gazdához a Windowsból, majd ismételje meg a disztribúcióban. A Windowsbeli siker és a disztribúcióbeli időtúllépés a kettő közé helyezi a hibát, nem a VPN kliensbe vagy a belső kiszolgálóba. Tegye ezt bármely útvonal módosítása előtt, hogy a két eredmény ugyanazt a célt írja le.

A disztribúció belsejében a ip -4 addr egy virtuális adaptert mutat a WSL NAT tartományából származó címmel, a ip route pedig egy alapértelmezett útvonalat a WSL átjáró felé. A vállalati előtaghoz nincs útvonal, mert a gazda alagútadapterének nincs megfelelője a disztribúcióban. Az alapértelmezett átjáró a WSL NAT-hoz vezet, nem a vállalati hálózathoz.

A vállalati útvonal hozzáadása anélkül, hogy előbb egy elérhető kapcsolaton helyi címet adnánk hozzá, időtúllépést vagy elérhetetlen hálózat hibát eredményez. A cím az a rész, amely használhatóvá teszi az útvonalat, ezért először azt olvassa ki, és az útvonalat tekintse második lépésnek.

Válasszon tükrözött hálózatot vagy szkriptelt útvonalat

A tükrözött hálózat a gazda saját interfészeit adja a disztribúciónak, így az alagút és útvonalai másolás nélkül jelennek meg. A funkció friss Windows buildtől és a .wslconfig fájlban lévő networkingMode=mirrored beállítástól függ, és engedélyezése független viselkedést változtat meg, például a localhost továbbítását. Kezelje platformváltásként, nem útvonal-hangolásként. Ha a build támogatja, és a mellékhatások elfogadhatók, ez a legrövidebb út.

A szűkebb megközelítés megtartja az alapértelmezett NAT-ot, és minden alkalommal átmásolja az alagút címét és útvonalát a disztribúcióba, amikor az alagút feljön. Több builden működik, nem változtatja meg a localhost viselkedését, és láthatóan meghibásodik, amikor a VPN le van kapcsolva. Az ára egy kis szkript, amelyet minden kapcsolatnál futtatni kell.

Válasszon egyet, és írja le. A tükrözött konfiguráció kézi útvonalakkal való keverése olyan disztribúciót ad, amelynek két útja van ugyanahhoz az előtaghoz, és egyiknek sincs világos gazdája. Egy dokumentált módszert könnyebb hibakeresni, mint két félkonfiguráltat.

Húzza ki az aktuális alagútadatokat a gazdából

Az adaptert MAC-cím alapján párosítsa, ne név szerint, mert a nevek a VPN klienssel és a kapcsolódási sorrenddel változnak. Listázza az adaptereket egyszer, jegyezze fel az alagútadapter MAC-címét, majd kérdezze le a címét és előtagját. A MAC az újracsatlakozások között a virtuális adapterrel marad, a név és az interfészindex viszont nem:

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

Az átjáró az interfész konfigurációjából származik. Először kérje le az interfészindexet, majd olvassa ki a következő ugrást. Az index újraindítás vagy adapter-visszaállítás után megváltozhat, ezért a szkriptnek olvasnia kell, nem tárolnia:

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

Vezesse át a kimenetet a tr -d '\r' parancson, mielőtt változóhoz rendeli. A PowerShell sorokat kocsivissza karakterrel zár, és a levágás nélkül az utolsó mező rejtett karaktert hordoz, amelytől egy útvonalparancs zavaró elemzési hibával elbukik.

Alkalmazza a címet és az útvonalat a disztribúcióban

Telepítse az alagút címét előtaggal ellátott címként a disztribúció interfészére, majd irányítsa a vállalati blokkot a gazda átjáróján keresztül:

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

A NetworkManager eldobja a kézzel beállított címet, amikor a kapcsolat ciklikusan újraindul, és egyetlen DHCP kliens sem kér helyettesítőt. Állítsa a módszert automatikusra, hogy minden újracsatlakozás frissítse a címet, majd hozza fel újra a kapcsolatot. A kézi módszer az első újracsatlakozásig tűnik stabilnak:

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

Mindkét lépést a VPN-t indító hookból futtassa, ne interaktív héjból. Az a szkript, amely kiolvassa a címet, hozzáadja, hozzáadja az útvonalat és naplózza az értékeket, ismétlődő kézi javításból ismételhetőt csinál, és a napló az első, amit az előtag változásakor el kell olvasni.

Rögzítse a nevet, és bizonyítsa az utat

A kernel hálózatváltás után átnevezheti a disztribúció interfészét eth1 és eth2 között, és a névre írt szkript ilyenkor a rossz eszközt szerkeszti. A MAC-hez kötött udev szabály stabil címkét ad az interfésznek:

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

Ezután ellenőrizze a címmel, az útvonallal és valódi TCP-kapcsolattal: ip -4 addr show dev vpn, ip route get 172.20.4.10 és egy ismert belső porthoz való kapcsolódás. Az útvonal-keresésnek meg kell neveznie a vpn eszközt és a hozzáadott forráscímet.

Ha mindhárom átmegy a disztribúcióban, és a kapcsolat továbbra is meghiúsul, a csomag elhagyja a WSL-t, és a Windows oldalán eldobódik. Ellenőrizze a gazda tűzfalát és a VPN kliens saját szűrését a szkript módosítása előtt, mert egy újabb útvonal-módosítás nem javítja meg azt a csomagot, amely már eléri a gazdát.