Banaketaren barruan, barne-zerbitzari baterako ping bat iraungitzen da, helbide berak Windowsetik erantzuten duen bitartean. VPN konektatuta dago eta Windowsen ibilbidea zuzena da, beraz hutsunea WSL muga da. Ibili bidea huts egin duen komandotik ostalariaren interfazeraino. Konponbidea ez da konfigurazio-fitxategi bateko CIDR finko bat; uneko helbidea irakurri eta banaketak erabil dezakeen tokian gehitzea da.

Egiaztatu non gelditzen den bidea

Exekutatu proba bera bi aldeetan: ebatz ezazu barne-ostalari bat Windowsetik eta konektatu, gero errepikatu banaketan. Windowsen arrakasta gehi banaketan iraungitze batek hutsa bien artean kokatzen du, ez VPN bezeroan ez barne-zerbitzarian. Egin ezazu ibilbide bat aldatu aurretik, bi emaitzek helmuga bera deskriba dezaten.

Banaketaren barruan, ip -4 addr-k WSL NAT barrutiko helbidea duen adaptagailu birtuala erakusten du, eta ip route-k WSL atebideari begira dagoen ibilbide lehenetsia erakusten du. Ez dago ibilbiderik enpresa-aurrizkirako, ostalariaren tunel-adaptagailuak ez baitu baliokiderik banaketaren barruan. Atebide lehenetsiak WSL NAT-era darama, ez enpresa-sarera.

Enpresa-ibilbidea gehitzeak, lehenago esteka irisgarri batean tokiko helbide bat gehitu gabe, iraungitze bat edo sare-iristezaile errore bat sortzen du. Helbidea da ibilbidea erabilgarri egiten duen zatia, beraz irakurri lehenengo eta hartu ibilbidea bigarren urrats gisa.

Aukeratu islatutako sarea edo script bidezko ibilbidea

Islatutako sareak ostalariaren interfaze propioak ematen dizkio banaketari, beraz tunela eta haren ibilbideak kopiatu gabe agertzen dira. Ezaugarriak Windowsen bertsio berri baten eta .wslconfig fitxategiko networkingMode=mirrored-ren mende dago, eta gaitzeak erlazionatutako ez den portaera aldatzen du, hala nola localhost birbidalketa. Hartu plataforma-aldaketa gisa, ez ibilbide-doikuntza gisa. Bertsioak onartzen badu eta albo-ondorioak onargarriak badira, hori da biderik laburrena.

Ikuspegi estuagoak NAT lehenetsia mantentzen du eta tunelaren helbidea eta ibilbidea banaketara kopiatzen ditu tunela altxatzen den bakoitzean. Bertsio gehiagotan funtzionatzen du, ez du localhost portaera aldatzen, eta modu ikusgarrian huts egiten du VPN jaitsita dagoenean. Kostua konexio bakoitzean exekutatu behar den script txiki bat da.

Aukera ezazu bat eta idatzi. Islatutako konfigurazioa eskuzko ibilbideekin nahasteak aurrizki bererako bi bide eta bakoitzarentzat jabe argirik ez duen banaketa sortzen du. Dokumentatutako metodo bat errazago arazten da erdi konfiguratutako bi baino.

Atera tunelaren uneko xehetasunak ostalaritik

Lotu adaptagailua MAC helbidearen arabera, ez izenaren arabera, izenak VPN bezeroarekin eta konexio-ordenarekin aldatzen baitira. Zerrendatu adaptagailuak behin, idatzi tunel-adaptagailuaren MACa eta gero galdetu haren helbidea eta aurrizkia. MACa adaptagailu birtualarekin geratzen da berrikonexioen artean, baina izena eta interfazearen indizea ez:

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

Atebidea interfazearen konfiguraziotik dator. Eskuratu lehenengo interfazearen indizea eta gero irakurri hurrengo jauzia. Indizea aldatu egin daiteke berrabiarazi edo adaptagailua berrezarri ondoren, horregatik scriptak irakurri behar du, gorde beharrean:

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

Pasa irteera tr -d '\r' bidez aldagai bati esleitu aurretik. PowerShell-ek lerroak orgako itzulerarekin amaitzen ditu, eta kentzen ez bada azken eremuak karaktere ezkutu bat darama, ibilbide-komando bat analisi-errore nahasgarri batekin hutsarazten duena.

Aplikatu helbidea eta ibilbidea banaketaren barruan

Instalatu tunelaren helbidea aurrizkidun helbide gisa banaketaren interfazean, eta gero bideratu enpresa-blokea ostalariaren atebidearen bidez:

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-ek eskuz konfiguratutako helbidea botatzen du konexioa birziklatzen denean, eta DHCP bezero batek ere ez du ordezkorik eskatzen. Ezarri metodoa automatikoa, berrikonexio bakoitzak helbidea freska dezan, eta gero altxatu konexioa berriro. Eskuzko metodoak egonkor dirudi lehen berrikonexiora arte:

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

Exekutatu bi urratsak VPNa abiarazten duen kakoan, ez shell interaktiboan. Helbidea irakurtzen, gehitzen, ibilbidea gehitzen eta balioak erregistratzen dituen script batek errepikatzen den eskuzko konponketa errepikagarri bihurtzen du, eta erregistroa da aurrizkia aldatzean lehenengo irakurri beharrekoa.

Finkatu izena eta frogatu bidea

Kernelak banaketaren interfazearen izena eth1 eta eth2 artean alda dezake sare-aldaketa baten ondoren, eta izen baten aurka idatzitako script batek gailu okerra editatzen du orduan. MACari lotutako udev arau batek etiketa egonkorra ematen dio interfazeari:

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

Gero egiaztatu helbidearekin, ibilbidearekin eta TCP konexio erreal batekin: ip -4 addr show dev vpn, ip route get 172.20.4.10 eta barne-portu ezagun baterako konexioa. Ibilbide-kontsultak vpn gailua eta gehitutako iturburu-helbidea izendatu beharko lituzke.

Hirurek banaketaren barruan gainditzen badute eta konexioak oraindik huts egiten badu, paketea WSLtik irteten da eta Windowseko aldean baztertzen da. Egiaztatu ostalariaren suebakia eta VPN bezeroaren beraren iragazketa scripta aldatu aurretik, beste ibilbide-aldaketa batek ez baitu jada ostalarira iristen ari den paketea konponduko.

Erlazionatutako artikuluak