WSL2 nepasiekia VPN potinklio: perskaitykite pagrindinio kompiuterio maršrutą

Iš distribucijos vidaus ping į vidinį serverį baigiasi laiko limitu, o tas pats adresas atsako iš Windows. VPN prijungtas, o Windows maršrutas teisingas, tad spraga yra WSL riba. Pereikite kelią nuo nepavykusios komandos atgal prie pagrindinio kompiuterio sąsajos. Sprendimas nėra fiksuotas CIDR konfigūracijos faile; tai dabartinio adreso perskaitymas ir jo pridėjimas ten, kur distribucija gali jį naudoti.

Patvirtinkite, kur kelias sustoja

Paleiskite tą patį testą abiejose pusėse: išspręskite ir prisijunkite prie vieno vidinio kompiuterio iš Windows, tada pakartokite tai distribucijoje. Sėkmė Windows ir laiko limitas distribucijoje nurodo gedimą tarp jų, o ne VPN kliente ar vidiniame serveryje. Atlikite tai prieš keisdami bet kurį maršrutą, kad abu rezultatai apibūdintų tą pačią paskirties vietą.

Distribucijos viduje ip -4 addr rodo virtualų adapterį su adresu iš WSL NAT diapazono, o ip route rodo numatytąjį maršrutą į WSL šliuzą. Korporatyviniam prefiksui maršruto nėra, nes pagrindinio kompiuterio tunelio adapteris neturi atitikmens distribucijos viduje. Numatytasis šliuzas veda į WSL NAT, o ne į korporatyvinį tinklą.

Korporatyvinio maršruto pridėjimas pirmiau nepridėjus vietinio adreso pasiekiamoje jungtyje sukelia laiko limitą arba tinklo nepasiekiamumo klaidą. Adresas yra ta dalis, kuri daro maršrutą naudingą, todėl pirmiausia jį perskaitykite, o maršrutą laikykite antru žingsniu.

Pasirinkite veidrodinį tinklą arba scenarijaus maršrutą

Veidrodinis tinklas suteikia distribucijai pačias pagrindinio kompiuterio sąsajas, todėl tunelis ir jo maršrutai atsiranda be kopijavimo. Funkcija priklauso nuo naujos Windows versijos ir nuo networkingMode=mirrored faile .wslconfig, o ją įjungus pasikeičia nesusijęs elgesys, pavyzdžiui, localhost persiuntimas. Traktuokite tai kaip platformos pakeitimą, o ne maršruto derinimą. Jei versija ją palaiko ir šalutiniai poveikiai priimtini, tai trumpiausias kelias.

Siauresnis požiūris išlaiko numatytąjį NAT ir kaskart, kai tunelis pakyla, nukopijuoja tunelio adresą ir maršrutą į distribuciją. Jis veikia daugiau versijų, nekeičia localhost elgesio ir matomai nepavyksta, kai VPN išjungtas. Kaina yra mažas scenarijus, kurį reikia paleisti kiekvieno prisijungimo metu.

Pasirinkite vieną ir užsirašykite. Veidrodinės konfigūracijos maišymas su rankiniais maršrutais sukuria distribuciją su dviem keliais į tą patį prefiksą ir be aiškaus savininko nė vienam. Vieną dokumentuotą metodą derinti lengviau nei du pusiau sukonfigūruotus.

Ištraukite dabartinius tunelio duomenis iš pagrindinio kompiuterio

Suderinkite adapterį pagal MAC adresą, o ne pagal pavadinimą, nes pavadinimai keičiasi su VPN klientu ir prisijungimo tvarka. Vieną kartą išvardykite adapterius, užsirašykite tunelio adapterio MAC, tada paklauskite jo adreso ir prefikso. MAC lieka su virtualiu adapteriu tarp prisijungimų, o pavadinimas ir sąsajos indeksas ne:

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

Šliuzas gaunamas iš sąsajos konfigūracijos. Pirmiausia gaukite sąsajos indeksą, tada perskaitykite kitą šuolį. Indeksas gali pasikeisti po perkrovimo ar adapterio atstatymo, todėl scenarijus turėtų jį skaityti, o ne saugoti:

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

Praleiskite išvestį per tr -d '\r' prieš priskirdami ją kintamajam. PowerShell baigia eilutes grįžimo karieta, o be pašalinimo paskutinis laukas turi paslėptą simbolį, dėl kurio maršruto komanda nepavyksta su klaidinančia analizės klaida.

Taikykite adresą ir maršrutą distribucijos viduje

Įdiekite tunelio adresą kaip adresą su prefiksu distribucijos sąsajoje, tada nukreipkite korporatyvinį bloką per pagrindinio kompiuterio šliuzą:

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 atmeta rankiniu būdu sukonfigūruotą adresą, kai ryšys persikrauna, ir joks DHCP klientas neprašo pakaitalo. Nustatykite metodą į automatinį, kad kiekvienas prisijungimas atnaujintų adresą, tada vėl pakelkite ryšį. Rankinis metodas atrodo stabilus iki pirmo prisijungimo:

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

Abu veiksmus vykdykite iš kablio, kuris paleidžia VPN, o ne iš interaktyvios shell. Scenarijus, kuris perskaito adresą, jį prideda, prideda maršrutą ir įrašo reikšmes į žurnalą, paverčia pasikartojantį rankinį taisymą pakartojamu, o žurnalas yra pirmas dalykas, kurį reikia perskaityti, kai pasikeičia prefiksas.

Užfiksuokite pavadinimą ir įrodykite kelią

Branduolys po tinklo perjungimo gali pervadinti distribucijos sąsają tarp eth1 ir eth2, ir pagal pavadinimą parašytas scenarijus tada redaguoja ne tą įrenginį. Prie MAC pririšta udev taisyklė suteikia sąsajai stabilų žymą:

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

Tada patikrinkite adresu, maršrutu ir tikru TCP ryšiu: ip -4 addr show dev vpn, ip route get 172.20.4.10 ir ryšiu į žinomą vidinį prievadą. Maršruto paieška turėtų įvardyti vpn įrenginį ir jūsų pridėtą šaltinio adresą.

Jei visi trys praeina distribucijos viduje, o ryšys vis tiek nepavyksta, paketas palieka WSL ir yra numetamas Windows pusėje. Prieš keisdami scenarijų patikrinkite pagrindinio kompiuterio ugniasienę ir paties VPN kliento filtravimą, nes dar vienas maršruto keitimas nepataisys paketo, kuris jau pasiekia pagrindinį kompiuterį.