WSL2 nedosáhne na podsíť VPN: přečtěte si trasu hostitele

Distribuce sedí za vlastním NAT a tunel Windows nikdy nevidí. Přečtěte si aktuální adresu a prefix z hostitele a pak je přidejte uvnitř WSL.

Zevnitř distribuce ping na interní server vyprší, zatímco stejná adresa odpovídá z Windows. VPN je připojená a trasa Windows je správná, takže mezera je hranice WSL. Projděte cestu od neúspěšného příkazu zpět k rozhraní hostitele. Oprava není pevný CIDR v konfiguračním souboru; je to přečtení aktuální adresy a její přidání tam, kde ji distribuce může použít.

Potvrďte, kde se cesta zastaví

Spusťte stejný test na obou stranách: přeložte a připojte se k jednomu internímu hostiteli z Windows a pak to zopakujte v distribuci. Úspěch ve Windows plus vypršení v distribuci lokalizuje poruchu mezi nimi, ne v klientu VPN ani v interním serveru. Udělejte to před změnou jakékoli trasy, aby oba výsledky popisovaly stejné cílové místo.

Uvnitř distribuce ip -4 addr ukazuje virtuální adaptér s adresou z rozsahu WSL NAT a ip route ukazuje výchozí trasu k bráně WSL. Pro firemní prefix žádná trasa není, protože tunelový adaptér hostitele nemá uvnitř distribuce protějšek. Výchozí brána vede do WSL NAT, ne do firemní sítě.

Přidání firemní trasy bez předchozího přidání místní adresy na dosažitelném spoji vede k vypršení nebo chybě nedostupné sítě. Adresa je část, která činí trasu použitelnou, takže ji přečtěte nejdřív a trasu berte jako druhý krok.

Zvolte zrcadlovou síť, nebo trasu se skriptem

Zrcadlová síť dává distribuci vlastní rozhraní hostitele, takže tunel a jeho trasy se objeví bez kopírování. Funkce závisí na nedávném sestavení Windows a na networkingMode=mirrored v .wslconfig a její zapnutí mění nesouvisející chování, například přesměrování localhostu. Berte to jako změnu platformy, ne jako úpravu trasy. Pokud to sestavení podporuje a vedlejší efekty jsou přijatelné, je to nejkratší cesta.

Užší přístup zachovává výchozí NAT a kopíruje adresu a trasu tunelu do distribuce pokaždé, když se tunel zvedne. Funguje na více sestaveních, nemění chování localhostu a při vypnuté VPN viditelně selhává. Cenou je malý skript, který se musí spouštět při každém připojení.

Vyberte jednu a zapište ji. Míchání zrcadlové konfigurace s ručními trasami vytváří distribuci se dvěma cestami ke stejnému prefixu a bez jasného vlastníka ani jedné. Jeden zdokumentovaný postup se ladí snadněji než dva napůl nakonfigurované.

Vytáhněte aktuální údaje o tunelu z hostitele

Párujte adaptér podle MAC adresy, ne podle názvu, protože názvy se mění s klientem VPN a pořadím připojení. Vypište adaptéry jednou, poznamenejte si MAC tunelového adaptéru a pak zjistěte jeho adresu a prefix. MAC zůstává u virtuálního adaptéru i mezi připojeními, kdežto název a index rozhraní ne:

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

Brána pochází z konfigurace rozhraní. Nejprve získejte index rozhraní a pak přečtěte další skok. Index se může změnit po restartu nebo resetu adaptéru, a proto ho skript má číst, ne ukládat:

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

Prožeňte výstup přes tr -d '\r', než ho přiřadíte proměnné. PowerShell ukončuje řádky návratem vozíku, a bez odstranění nese poslední pole skrytý znak, který způsobí selhání příkazu trasy se zavádějící chybou analýzy.

Použijte adresu a trasu uvnitř distribuce

Nainstalujte adresu tunelu jako adresu s prefixem na rozhraní distribuce a pak směrujte firemní blok přes bránu hostitele:

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 zahodí ručně nakonfigurovanou adresu, když se spojení obnoví, a žádný klient DHCP nepožádá o náhradu. Nastavte metodu na automatickou, aby každé opětovné připojení adresu obnovilo, a pak spojení znovu zvedněte. Ruční metoda vypadá stabilně až do prvního opětovného připojení:

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

Spouštějte oba kroky z háku, který spouští VPN, ne z interaktivní shellu. Skript, který adresu přečte, přidá ji, přidá trasu a zapíše hodnoty do logu, mění opakovanou ruční opravu v opakovatelnou, a log je první věc, kterou je třeba přečíst, když se prefix změní.

Připněte název a dokažte cestu

Jádro může po přepnutí sítě přejmenovat rozhraní distribuce mezi eth1 a eth2, a skript napsaný na název pak upraví špatné zařízení. Pravidlo udev vázané na MAC dává rozhraní stabilní označení:

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

Pak ověřte adresou, trasou a skutečným TCP spojením: ip -4 addr show dev vpn, ip route get 172.20.4.10 a spojením na známý interní port. Vyhledání trasy by mělo uvést zařízení vpn a zdrojovou adresu, kterou jste přidali.

Pokud všechny tři projdou uvnitř distribuce a spojení stále selhává, paket opouští WSL a je zahozen na straně Windows. Zkontrolujte firewall hostitele a vlastní filtrování klienta VPN, než změníte skript, protože další úprava trasy neopraví paket, který už k hostiteli dorazil.

Související články