WSL2 nie dziedziczy firmowego VPN i właśnie to jest błąd

Wewnętrzna wiki wczytuje się w Edge, a git clone wewnątrz dystrybucji kończy się przekroczeniem czasu. Ta jedna obserwacja jest zwykle czytana jako «VPN blokuje WSL2», a następna godzina idzie na edycję /etc/resolv.conf. Użyteczniejsze odczytanie jest takie, że WSL2 nigdy nie miał ścieżki sieciowej hosta: działa w pomocniczej VM z własnym adapterem, własnymi trasami i plikiem resolvera, który Windows dla niego generuje. Wszystko dalej zależy od tego, którego z tych trzech naprawdę brakuje.

VM ma własny stos, metryki i resolver

W domyślnym trybie NAT dystrybucja stoi za przełącznikiem wirtualnym i dociera do internetu przez hosta, ale nie widzi jego adapterów. ip addr pokazuje jeden interfejs z adresem prywatnym, ip route pokazuje trasę domyślną przez ten przełącznik, a /etc/resolv.conf to wygenerowany plik wskazujący na stub resolver wybrany przez Windows. Nic z tego nie zmienia się dlatego, że po stronie Windows uruchomił się klient VPN.

Dlatego «przeglądarka działa» dowodzi tak niewiele. Przeglądarka używa stosu hosta, tunelu i polityki resolvera hosta. Twoja powłoka używa innego stosu, który przypadkiem dzieli fizyczną kartę sieciową. Zgadzają się w szczęśliwym przypadku i rozchodzą dokładnie wtedy, gdy VPN instaluje filtr, przepisuje listę DNS lub dodaje trasę do podsieci przełącznika wirtualnego.

Dwa testy rozstrzygają, w którym świecie jesteś, i muszą zostać uruchomione wewnątrz dystrybucji:

getent hosts example.com
curl -sS -m 8 -o /dev/null -w "%{http_code}\n" 1.1.1.1
ip route
cat /etc/resolv.conf

Awaria nazw, gdy odpowiada adres dosłowny, to problem resolvera. Awaria nazw i adresów jednocześnie to problem ścieżki, którego żadna edycja resolvera nie dotknie. Potem przychodzą dowody po stronie Windows: Get-NetAdapter | Get-DnsClientServerAddress i route print -4 pokazują, czy tunel przejął podsieć, w której mieszka twoja VM.

Mit pierwszy: firmowe serwery DNS to naprawiają

Edycja pliku resolvera to klasyczna rada i jest słuszna mniej więcej w połowie przypadków. Gdy jest słuszna, ma konkretny powód: wygenerowany plik wskazuje resolver, który zna tylko nazwy publiczne, więc zapytanie o intranet.example.internal wraca jako nieistniejące, choć ścieżka jest w porządku.

Przypięcie serwerów VPN oznacza powstrzymanie Windows przed ponownym generowaniem pliku, bo każdy plik napisany ręcznie jest zastępowany przy następnym starcie:

[network]
generateResolvConf = false

Zapisz to jako /etc/wsl.conf, uruchom wsl --shutdown z Windows, potem uruchom dystrybucję i wpisz /etc/resolv.conf z serwerami tunelu najpierw, a publiczny resolver tylko jako zapas. To trwała zmiana z kosztem utrzymania: plik nie podąża już za hostem, więc gdy firmowe adresy DNS się zmienią, dystrybucja nadal pyta o stare. Ktoś musi być właścicielem tego pliku.

Nie robi też nic, gdy awaria jest szersza. Jeśli curl do 1.1.1.1 kończy się przekroczeniem czasu, klient tunelu filtruje przełącznik wirtualny albo kieruje podsieć VM do tunelu, a poprawny resolver daje tylko nazwy, do których nadal nie można dotrzeć.

Mit drugi: zmiana metryki się utrzymuje

Gdy nazwy się rozwiązują, ale ruch wychodzi przez fizyczny adapter, dźwignią są metryki interfejsu. Daj adapterowi VPN wysoki koszt, a przełącznikowi WSL niski:

Get-NetAdapter | Where-Object InterfaceDescription -Match "AnyConnect" | Set-NetIPInterface -InterfaceMetric 4000
Get-NetIPInterface -InterfaceAlias "vEthernet (WSL)" | Set-NetIPInterface -InterfaceMetric 1

Pamiętaj potem, że w wielu kompilacjach klienta adapter tunelu jest tworzony od nowa przy każdym połączeniu i metryka wraca do domyślnej. Jednorazowe polecenie to poprawka, która po cichu wygasa, zwykle w weekend, a zgłoszenie wraca z «w zeszłym tygodniu działało». Zaplanowane zadanie uruchamiane przez zdarzenie VPN albo skrypt uruchamiany przez użytkownika po połączeniu to uczciwa wersja tej poprawki.

Ten sam termin dotyczy tras hosta dodanych dla jednego upartego prefiksu. Są warte uwagi jako diagnostyka, bo mówią, czy problem dotyczy jednego celu, czy całej ścieżki, ale nie są architekturą.

Mit trzeci: jedna poprawka obejmuje każdą kompilację Windows

wsl-vpnkit to wzorzec sidecar: mała dystrybucja posiada ścieżkę po stronie hosta i przekazuje za inne dystrybucje przez gniazdo wirtualne, więc ruch aplikacji przestaje zależeć od filtrowanego przełącznika. Wymaga działającej ścieżki standardowej, czyli usunięcia nadpisań networkingMode i dnsTunneling z %UserProfile%\.wslconfig, przywrócenia generateResolvConf = true w każdej działającej dystrybucji i uruchomienia usługi przy logowaniu.

Tryb lustrzany to wbudowana alternatywa w Windows 11 22H2 i nowszych, i to jedno ustawienie plus jedno wyłączenie:

[wsl2]
networkingMode=mirrored

Wewnątrz dystrybucji ip addr wymienia wtedy adaptery hosta, tunel może się wśród nich pojawić, a tunelowanie DNS przekazuje zapytania przez resolver Windows nawet gdy klient przepisuje listę DNS. To nie jest uniwersalne: niektóre sterowniki filtrów nadal odrzucają ścieżkę lustrzaną, a reguły zapory Hyper-V mogą wymagać wyraźnego zezwolenia. Przewodnik po sieciach WSL firmy Microsoft to strona, którą warto porównać z własną kompilacją przed zastosowaniem przepisu napisanego dla nowszej.

Po każdej zmianie przetestuj trzy rzeczy

Wybierz jeden mechanizm na maszynę i zapisz go, bo oba źle się łączą. Sidecar na trybie lustrzanym podwaja przekazywanie, a lustrzany host z nieaktualnym wpisem sidecar w .wslconfig zwykle zawodzi po aktualizacji, a nie przed nią.

Cokolwiek wybrałeś, test akceptacyjny to te same trzy żądania wewnątrz dystrybucji: nazwa wewnętrzna, nazwa publiczna i surowy adres. Powtórz je potem po odłączeniu i ponownym podłączeniu tunelu oraz po wsl --shutdown. Jeśli zawodzi tylko nazwa wewnętrzna, to polityka resolvera; jeśli nazwa wewnętrzna i publiczna zawodzą razem przy działającym adresie, to nadal polityka resolvera; jeśli zawodzi wszystko, to ścieżka.

Jeśli jeden wewnętrzny host zawodzi, a reszta działa, przestań patrzeć na resolver i poszukaj brakującej trasy dla tego prefiksu. Jeśli wszystko działa do następnego ponownego połączenia, znalazłeś poprawkę zależną od stanu wykonania i trzeba ją stosować automatycznie ponownie albo zastąpić jednym z dwóch mechanizmów powyżej.