WSL2 ne atingas la VPN-subreton: legu la gastigan itineron

De interne de la distribuaĵo, ping al interna servilo finiĝas per tempolimo, dum la sama adreso respondas el Windows. La VPN estas konektita kaj la Windows-itinero estas ĝusta, do la breĉo estas la limo de WSL. Trapasu la vojon de la malsukcesa komando reen al la gastiga interfaco. La solvo ne estas fiksa CIDR en agorda dosiero; ĝi estas legi la nunan adreson kaj aldoni ĝin tie, kie la distribuaĵo povas uzi ĝin.

Konfirmu, kie la vojo haltas

Rulu la saman teston ambaŭflanke: solvu kaj konektiĝu al unu interna gastiganto el Windows, poste ripetu tion en la distribuaĵo. Sukceso en Windows plus tempolimo en la distribuaĵo lokas la fiaskon inter ili, ne en la VPN-kliento aŭ la interna servilo. Faru tion antaŭ ol ŝanĝi iun ajn itineron, por ke la du rezultoj priskribu la saman celon.

Ene de la distribuaĵo, ip -4 addr montras virtualan adaptilon kun adreso el la WSL NAT-gamo, kaj ip route montras defaŭltan itineron al la WSL-pordego. Ne estas itinero por la entreprena prefikso, ĉar la tunela adaptilo de la gastiganto ne havas pandanton ene de la distribuaĵo. La defaŭlta pordego kondukas al la WSL NAT, ne al la entreprena reto.

Aldoni la entreprenan itineron sen unue aldoni lokan adreson sur atingebla ligo produktas tempolimon aŭ ret-malatingeblan eraron. La adreso estas la parto, kiu igas la itineron uzebla, do legu ĝin unue kaj traktu la itineron kiel la duan paŝon.

Elektu spegulitan retadon aŭ skriptan itineron

Spegulita retado donas al la distribuaĵo la proprajn interfacojn de la gastiganto, do la tunelo kaj ĝiaj itineroj aperas sen kopiado. La funkcio dependas de freŝa Windows-konstruo kaj de networkingMode=mirrored en .wslconfig, kaj ĝia ŝaltado ŝanĝas ne rilatajn kondutojn kiel localhost-plusendadon. Traktu ĝin kiel platforman ŝanĝon, ne kiel itineran agordon. Se la konstruo subtenas ĝin kaj la kromefikoj akcepteblas, ĝi estas la plej mallonga vojo.

La pli mallarĝa aliro konservas la defaŭltan NAT kaj kopias la tunelan adreson kaj itineron en la distribuaĵon ĉiufoje, kiam la tunelo ekfunkcias. Ĝi funkcias sur pli da konstruoj, ĝi ne ŝanĝas la konduton de localhost, kaj ĝi videble fiaskas, kiam la VPN estas malŝaltita. La kosto estas malgranda skripto, kiu devas ruliĝi ĉe ĉiu konekto.

Elektu unu kaj skribu ĝin. Miksi spegulitan agordon kun permanaj itineroj produktas distribuaĵon kun du vojoj al la sama prefikso kaj sen klara posedanto por iu ajn. Unu dokumentita metodo estas pli facile sencimigi ol du duone agorditaj.

Elprenu la nunajn tunelajn detalojn el la gastiganto

Kongruigu la adaptilon laŭ MAC-adreso anstataŭ laŭ nomo, ĉar nomoj ŝanĝiĝas kun la VPN-kliento kaj la konekta ordo. Listigu la adaptilojn unufoje, notu la MAC de la tunela adaptilo, poste demandu ĝian adreson kaj prefikson. La MAC restas kun la virtuala adaptilo tra rekonektoj, dum la nomo kaj la interfaca indekso ne:

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

La pordego venas el la interfaca agordo. Prenu unue la interfacan indekson, poste legu la sekvan salteton. La indekso povas ŝanĝiĝi post restartigo aŭ adaptila restarigo, tial la skripto devas legi ĝin anstataŭ konservi ĝin:

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

Trapasu la eligon tra tr -d '\r' antaŭ ol atribui ĝin al variablo. PowerShell finas liniojn per kariga reveno, kaj sen la forigo la lasta kampo portas kaŝitan signon, kiu igas itineran komandon fiaski per konfuza analiza eraro.

Apliku la adreson kaj itineron ene de la distribuaĵo

Instalu la tunelan adreson kiel prefikse kvalifikitan adreson sur la interfaco de la distribuaĵo, poste enkursigu la entreprenan blokon tra la pordego de la gastiganto:

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 forĵetas permane agorditan adreson, kiam la konekto ciklas, kaj neniu DHCP-kliento petas anstataŭaĵon. Agordu la metodon al aŭtomata, por ke ĉiu rekonekto refreŝigu la adreson, poste relevu la konekton. Perman metodo aspektas stabila ĝis la unua rekonekto:

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

Rulu ambaŭ paŝojn el la hoko, kiu startigas la VPN, ne el interaga ŝelo. Skripto, kiu legas la adreson, aldonas ĝin, aldonas la itineron kaj registras la valorojn, transformas ripetiĝantan permanan riparon en ripeteblan, kaj la protokolo estas la unua afero legenda, kiam la prefikso ŝanĝiĝas.

Fiksu la nomon kaj pruvu la vojon

La kerno povas renomi la interfacon de la distribuaĵo inter eth1 kaj eth2 post reta ŝanĝo, kaj skripto verkita laŭ nomo tiam redaktas la malĝustan aparaton. udev-regulo ligita al la MAC donas al la interfaco stabilan etikedon:

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

Poste kontrolu per la adreso, la itinero kaj reala TCP-konekto: ip -4 addr show dev vpn, ip route get 172.20.4.10 kaj konekto al konata interna pordo. La itinera serĉo devus nomi la vpn-aparaton kaj la fontan adreson, kiun vi aldonis.

Se ĉiuj tri pasas ene de la distribuaĵo kaj la konekto ankoraŭ fiaskas, la paketo forlasas WSL kaj estas forĵetata ĉe la Windows-flanko. Kontrolu la gastigan fajroŝirmilon kaj la propran filtradon de la VPN-kliento antaŭ ol ŝanĝi la skripton, ĉar plia itinera redakto ne riparos paketon, kiu jam atingas la gastiganton.