WSL2 nie dociera do podsieci VPN: odczytaj trasę hosta

Z wnętrza dystrybucji ping do wewnętrznego serwera kończy się przekroczeniem limitu czasu, podczas gdy ten sam adres odpowiada z Windows. VPN jest połączony, a trasa Windows jest poprawna, więc luką jest granica WSL. Przejdź ścieżkę od nieudanego polecenia z powrotem do interfejsu hosta. Rozwiązaniem nie jest stały CIDR w pliku konfiguracyjnym; to odczytanie bieżącego adresu i dodanie go tam, gdzie dystrybucja może go użyć.

Potwierdź, gdzie ścieżka się zatrzymuje

Uruchom ten sam test po obu stronach: rozwiąż i połącz się z jednym wewnętrznym hostem z Windows, a następnie powtórz to w dystrybucji. Sukces w Windows plus przekroczenie limitu czasu w dystrybucji lokalizuje usterkę między nimi, a nie w kliencie VPN ani w wewnętrznym serwerze. Zrób to przed zmianą dowolnej trasy, aby oba wyniki opisywały ten sam cel.

W dystrybucji ip -4 addr pokazuje wirtualny adapter z adresem z zakresu NAT WSL, a ip route pokazuje trasę domyślną do bramy WSL. Nie ma trasy dla prefiksu firmowego, ponieważ adapter tunelu hosta nie ma odpowiednika w dystrybucji. Brama domyślna prowadzi do NAT WSL, a nie do sieci firmowej.

Dodanie trasy firmowej bez uprzedniego dodania adresu lokalnego na osiągalnym łączu daje przekroczenie limitu czasu lub błąd sieci nieosiągalnej. Adres jest tą częścią, która czyni trasę użyteczną, więc odczytaj go najpierw, a trasę traktuj jako drugi krok.

Wybierz sieć lustrzaną albo trasę ze skryptu

Sieć lustrzana daje dystrybucji własne interfejsy hosta, więc tunel i jego trasy pojawiają się bez kopiowania. Funkcja zależy od nowej kompilacji Windows i od networkingMode=mirrored w .wslconfig, a jej włączenie zmienia niezwiązane zachowanie, np. przekazywanie localhost. Traktuj to jako zmianę platformy, a nie dostrajanie trasy. Jeśli kompilacja to obsługuje, a skutki uboczne są akceptowalne, to najkrótsza droga.

Węższe podejście zachowuje domyślny NAT i kopiuje adres oraz trasę tunelu do dystrybucji za każdym razem, gdy tunel się podnosi. Działa na większej liczbie kompilacji, nie zmienia zachowania localhost i zawodzi widocznie, gdy VPN jest wyłączony. Kosztem jest mały skrypt, który trzeba uruchamiać przy każdym połączeniu.

Wybierz jedno i zapisz to. Mieszanie konfiguracji lustrzanej z ręcznymi trasami daje dystrybucję z dwiema drogami do tego samego prefiksu i bez jasnego właściciela żadnej z nich. Jedna udokumentowana metoda jest łatwiejsza do debugowania niż dwie na wpół skonfigurowane.

Pobierz bieżące szczegóły tunelu z hosta

Dopasuj adapter po adresie MAC, a nie po nazwie, ponieważ nazwy zmieniają się z klientem VPN i kolejnością połączeń. Wypisz adaptery raz, zanotuj MAC adaptera tunelu, a następnie zapytaj o jego adres i prefiks. MAC pozostaje przy adapterze wirtualnym między ponownymi połączeniami, natomiast nazwa i indeks interfejsu nie:

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

Brama pochodzi z konfiguracji interfejsu. Najpierw pobierz indeks interfejsu, a potem odczytaj następny skok. Indeks może się zmienić po restarcie lub resecie adaptera, dlatego skrypt powinien go czytać, a nie zapisywać:

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

Przepuść wyjście przez tr -d '\r' przed przypisaniem go do zmiennej. PowerShell kończy wiersze znakiem powrotu karetki, a bez usunięcia ostatnie pole niesie ukryty znak, który powoduje błąd polecenia trasy z mylącym błędem analizy.

Zastosuj adres i trasę w dystrybucji

Zainstaluj adres tunelu jako adres z prefiksem na interfejsie dystrybucji, a następnie skieruj blok firmowy przez bramę hosta:

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 porzuca ręcznie skonfigurowany adres, gdy połączenie się przełączy, i żaden klient DHCP nie prosi o zamiennik. Ustaw metodę na automatyczną, aby każde ponowne połączenie odświeżało adres, a następnie ponownie podnieś połączenie. Metoda ręczna wygląda stabilnie do pierwszego ponownego połączenia:

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

Uruchamiaj oba kroki z hooka, który uruchamia VPN, a nie z interaktywnej powłoki. Skrypt, który odczytuje adres, dodaje go, dodaje trasę i zapisuje wartości w logu, zamienia powtarzającą się ręczną naprawę w powtarzalną, a log jest pierwszą rzeczą do przeczytania, gdy prefiks się zmieni.

Przypnij nazwę i udowodnij ścieżkę

Jądro może zmienić nazwę interfejsu dystrybucji między eth1 a eth2 po przełączeniu sieci, a skrypt napisany pod nazwę edytuje wtedy niewłaściwe urządzenie. Reguła udev powiązana z MAC daje interfejsowi stabilną etykietę:

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

Następnie sprawdź adresem, trasą i prawdziwym połączeniem TCP: ip -4 addr show dev vpn, ip route get 172.20.4.10 i połączeniem do znanego portu wewnętrznego. Wyszukiwanie trasy powinno wskazać urządzenie vpn i dodany przez ciebie adres źródłowy.

Jeśli wszystkie trzy przejdą w dystrybucji, a połączenie nadal zawodzi, pakiet opuszcza WSL i jest odrzucany po stronie Windows. Sprawdź zaporę hosta i własne filtrowanie klienta VPN przed zmianą skryptu, bo kolejna zmiana trasy nie naprawi pakietu, który już dociera do hosta.