WSL2 nesasniedz VPN apakštīklu: izlasiet resursdatora maršrutu

No distribūcijas iekšpuses ping uz iekšēju serveri beidzas ar taimautu, kamēr tā pati adrese atbild no Windows. VPN ir savienots un Windows maršruts ir pareizs, tāpēc plaisa ir WSL robeža. Izstaigājiet ceļu no neveiksmīgās komandas atpakaļ uz resursdatora saskarni. Labojums nav fiksēts CIDR konfigurācijas failā; tas ir pašreizējās adreses nolasīšana un pievienošana tur, kur distribūcija to var izmantot.

Apstipriniet, kur ceļš apstājas

Palaidiet to pašu testu abās pusēs: atrisiniet un savienojieties ar vienu iekšēju resursdatoru no Windows, pēc tam atkārtojiet to distribūcijā. Panākumi Windows un taimauts distribūcijā lokalizē kļūmi starp abiem, nevis VPN klientā vai iekšējā serverī. Dariet to pirms jebkura maršruta maiņas, lai abi rezultāti aprakstītu vienu un to pašu galamērķi.

Distribūcijas iekšienē ip -4 addr parāda virtuālo adapteri ar adresi no WSL NAT diapazona, un ip route parāda noklusējuma maršrutu uz WSL vārteju. Korporatīvajam prefiksam maršruta nav, jo resursdatora tuneļa adapterim distribūcijas iekšienē nav atbilsmes. Noklusējuma vārteja ved uz WSL NAT, nevis uz korporatīvo tīklu.

Korporatīvā maršruta pievienošana, vispirms nepievienojot lokālo adresi sasniedzamā savienojumā, rada taimautu vai tīkla nesasniedzamības kļūdu. Adrese ir tā daļa, kas padara maršrutu lietojamu, tāpēc vispirms izlasiet to un maršrutu uzskatiet par otro soli.

Izvēlieties spoguļoto tīklu vai skripta maršrutu

Spoguļotais tīkls distribūcijai dod paša resursdatora saskarnes, tāpēc tunelis un tā maršruti parādās bez kopēšanas. Funkcija ir atkarīga no jaunas Windows būves un no networkingMode=mirrored failā .wslconfig, un tās iespējošana maina nesaistītu uzvedību, piemēram, localhost pāradresāciju. Uztveriet to kā platformas maiņu, nevis maršruta precizējumu. Ja būve to atbalsta un blakusefekti ir pieņemami, tas ir īsākais ceļš.

Šaurākā pieeja saglabā noklusējuma NAT un katru reizi, kad tunelis paceļas, iekopē tuneļa adresi un maršrutu distribūcijā. Tā darbojas vairāk būvēs, nemaina localhost uzvedību un redzami neizdodas, kad VPN ir izslēgts. Cena ir mazs skripts, kas jāpalaiž pie katra savienojuma.

Izvēlieties vienu un pierakstiet to. Spoguļotās konfigurācijas jaukšana ar manuāliem maršrutiem rada distribūciju ar diviem ceļiem uz vienu un to pašu prefiksu un bez skaidra īpašnieka nevienam. Vienu dokumentētu metodi ir vieglāk atkļūdot nekā divas puslīdz konfigurētas.

Izvelciet pašreizējās tuneļa detaļas no resursdatora

Saskaņojiet adapteri pēc MAC adreses, nevis pēc nosaukuma, jo nosaukumi mainās līdz ar VPN klientu un savienojuma secību. Vienreiz uzskaitiet adapterus, pierakstiet tuneļa adaptera MAC, pēc tam vaicājiet tā adresi un prefiksu. MAC paliek ar virtuālo adapteri starp atkārtotiem savienojumiem, bet nosaukums un saskarnes indekss ne:

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

Vārteja nāk no saskarnes konfigurācijas. Vispirms iegūstiet saskarnes indeksu, pēc tam izlasiet nākamo lēcienu. Indekss var mainīties pēc pārstartēšanas vai adaptera atiestatīšanas, tāpēc skriptam tas jālasa, nevis jāglabā:

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

Izlaidiet izvadi caur tr -d '\r' pirms piešķirat to mainīgajam. PowerShell beidz rindas ar rindas atgriešanu, un bez noņemšanas pēdējais lauks nes slēptu rakstzīmi, kas liek maršruta komandai neizdoties ar mulsinošu parsēšanas kļūdu.

Piemērojiet adresi un maršrutu distribūcijas iekšienē

Instalējiet tuneļa adresi kā adresi ar prefiksu distribūcijas saskarnē, pēc tam maršrutējiet korporatīvo bloku caur resursdatora vārteju:

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 izmet manuāli konfigurētu adresi, kad savienojums pārstartējas, un neviens DHCP klients neprasa aizstājēju. Iestatiet metodi uz automātisku, lai katrs atkārtotais savienojums atjaunotu adresi, pēc tam atkal paceliet savienojumu. Manuālā metode šķiet stabila līdz pirmajam atkārtotajam savienojumam:

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

Izpildiet abus soļus no āķa, kas palaiž VPN, nevis no interaktīvas čaulas. Skripts, kas nolasa adresi, pievieno to, pievieno maršrutu un ieraksta vērtības žurnālā, pārvērš atkārtotu manuālu labojumu atkārtojamā, un žurnāls ir pirmais, kas jālasa, kad prefikss mainās.

Nofiksējiet nosaukumu un pierādiet ceļu

Kodols pēc tīkla pārslēgšanas var pārdēvēt distribūcijas saskarni starp eth1 un eth2, un skripts, kas rakstīts pret nosaukumu, tad rediģē nepareizo ierīci. udev noteikums, kas piesaistīts MAC, piešķir saskarnei stabilu apzīmējumu:

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

Pēc tam pārbaudiet ar adresi, maršrutu un īstu TCP savienojumu: ip -4 addr show dev vpn, ip route get 172.20.4.10 un savienojumu ar zināmu iekšējo portu. Maršruta meklējumam jānosauc vpn ierīce un jūsu pievienotā avota adrese.

Ja visi trīs iztur distribūcijas iekšienē un savienojums joprojām neizdodas, pakete atstāj WSL un tiek nomesta Windows pusē. Pirms skripta maiņas pārbaudiet resursdatora ugunsmūri un paša VPN klienta filtrēšanu, jo vēl viena maršruta rediģēšana nesalabos paketi, kas jau sasniedz resursdatoru.