WSL2 ei tavoita VPN-aliverkkoa: lue isäntäkoneen reitti

Jakelun sisältä ping sisäiseen palvelimeen päättyy aikakatkaisuun, kun sama osoite vastaa Windowsista. VPN on yhdistetty ja Windowsin reitti on oikein, joten aukko on WSL:n raja. Käy polku epäonnistuneesta komennosta takaisin isännän liitäntään. Korjaus ei ole kiinteä CIDR asetustiedostossa; se on nykyisen osoitteen lukeminen ja lisääminen sinne, missä jakelu voi käyttää sitä.

Varmista, mihin polku pysähtyy

Suorita sama testi molemmilla puolilla: ratkaise ja yhdistä yhteen sisäiseen isäntään Windowsista ja toista se sitten jakelussa. Onnistuminen Windowsissa ja aikakatkaisu jakelussa paikantaa vian näiden väliin, ei VPN-asiakkaaseen tai sisäiseen palvelimeen. Tee tämä ennen minkään reitin muuttamista, jotta molemmat tulokset kuvaavat samaa kohdetta.

Jakelun sisällä ip -4 addr näyttää virtuaalisen sovittimen, jonka osoite on WSL NAT -alueelta, ja ip route näyttää oletusreitin WSL-yhdyskäytävään. Yrityksen etuliitteelle ei ole reittiä, koska isännän tunnelisovittimella ei ole vastinetta jakelun sisällä. Oletusyhdyskäytävä johtaa WSL NAT:iin, ei yritysverkkoon.

Yritysreitin lisääminen ilman, että ensin lisätään paikallinen osoite saavutettavalle linkille, tuottaa aikakatkaisun tai verkkoon yhdistämättömän virheen. Osoite on se osa, joka tekee reitistä käyttökelpoisen, joten lue se ensin ja käsittele reittiä toisena vaiheena.

Valitse peilattu verkko tai skriptattu reitti

Peilattu verkko antaa jakelulle isännän omat liitännät, joten tunneli ja sen reitit ilmestyvät ilman kopiointia. Ominaisuus riippuu tuoreesta Windowsin koontiversiosta ja .wslconfig-tiedoston networkingMode=mirrored-asetuksesta, ja sen käyttöönotto muuttaa riippumatonta toimintaa, kuten localhostin välitystä. Käsittele sitä alustan muutoksena, ei reitin hienosäätönä. Jos koontiversio tukee sitä ja sivuvaikutukset ovat hyväksyttäviä, se on lyhin polku.

Kapeampi lähestymistapa säilyttää oletus-NAT:n ja kopioi tunnelin osoitteen ja reitin jakeluun aina, kun tunneli nousee. Se toimii useammissa koontiversioissa, ei muuta localhostin toimintaa ja epäonnistuu näkyvästi, kun VPN on alhaalla. Hinta on pieni skripti, joka täytyy ajaa jokaisella yhteydellä.

Valitse yksi ja kirjoita se muistiin. Peilatun kokoonpanon sekoittaminen manuaalisiin reitteihin tuottaa jakelun, jolla on kaksi polkua samaan etuliitteeseen eikä kummallekaan selvää omistajaa. Yhtä dokumentoitua menetelmää on helpompi vianmäärittää kuin kahta puoliksi konfiguroitua.

Hae tunnelin nykyiset tiedot isännältä

Sovita sovitin MAC-osoitteen, älä nimen perusteella, koska nimet muuttuvat VPN-asiakkaan ja yhteysjärjestyksen mukana. Listaa sovittimet kerran, kirjaa tunnelisovittimen MAC ja kysy sitten sen osoite ja etuliite. MAC pysyy virtuaalisovittimessa uudelleenyhdistysten yli, mutta nimi ja liitännän indeksi eivät:

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

Yhdyskäytävä tulee liitännän kokoonpanosta. Hae ensin liitännän indeksi ja lue sitten seuraava hyppy. Indeksi voi muuttua uudelleenkäynnistyksen tai sovittimen nollauksen jälkeen, minkä vuoksi skriptin pitää lukea se tallentamisen sijaan:

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

Ohjaa tuloste tr -d '\r'-komennon läpi ennen kuin annat sen muuttujalle. PowerShell päättää rivit vaununpalautuksella, ja ilman poistoa viimeinen kenttä kantaa piilotetun merkin, joka saa reittikomennon epäonnistumaan hämmentävällä jäsennysvirheellä.

Käytä osoite ja reitti jakelun sisällä

Asenna tunnelin osoite etuliitteellisenä osoitteena jakelun liitännälle ja reititä sitten yrityslohko isännän yhdyskäytävän kautta:

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 pudottaa manuaalisesti määritetyn osoitteen, kun yhteys kiertää, eikä mikään DHCP-asiakas pyydä korvaavaa. Aseta menetelmä automaattiseksi, jotta jokainen uudelleenyhdistys päivittää osoitteen, ja nosta yhteys sitten uudelleen. Manuaalinen menetelmä näyttää vakaalta ensimmäiseen uudelleenyhdistykseen asti:

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

Aja molemmat vaiheet VPN:n käynnistävästä koukusta, älä interaktiivisesta kuoresta. Skripti, joka lukee osoitteen, lisää sen, lisää reitin ja kirjaa arvot lokiin, muuttaa toistuvan manuaalisen korjauksen toistettavaksi, ja loki on ensimmäinen asia, joka kannattaa lukea, kun etuliite muuttuu.

Kiinnitä nimi ja todista polku

Ydin voi nimetä jakelun liitännän uudelleen eth1:n ja eth2:n välillä verkon vaihdon jälkeen, ja nimeen kirjoitettu skripti muokkaa silloin väärää laitetta. MAC-osoitteeseen sidottu udev-sääntö antaa liitännälle vakaan tunnisteen:

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

Vahvista sitten osoitteella, reitillä ja oikealla TCP-yhteydellä: ip -4 addr show dev vpn, ip route get 172.20.4.10 ja yhteys tunnettuun sisäiseen porttiin. Reittihakuun pitäisi tulla vpn-laite ja lisäämäsi lähdeosoite.

Jos kaikki kolme menevät läpi jakelun sisällä ja yhteys epäonnistuu silti, paketti lähtee WSL:stä ja pudotetaan Windowsin puolella. Tarkista isännän palomuuri ja VPN-asiakkaan oma suodatus ennen skriptin muuttamista, sillä vielä yksi reittimuutos ei korjaa pakettia, joka saapuu jo isännälle.