WSL2 stracił DNS po połączeniu VPN? Dwie przyczyny

Ping po adresie działa w dystrybucji, instalacje pakietów i pobieranie git już nie, a awaria pojawiła się zaraz po podniesieniu tunelu. Przestały rozwiązywać się tylko nazwy, co wskazuje na DNS, a nie na łączność. Ponowna instalacja pakietów to tutaj najpopularniejszy błędny pierwszy krok. WSL2 ma dwa niezależne sposoby wywołania dokładnie tego objawu i wymagają one różnych napraw.

Dlaczego dystrybucja trzyma własny resolver

Klient DNS Windows nie jest używany wewnątrz dystrybucji. WSL2 przy starcie buduje własny plik resolvera, wskazujący na adres stub, który Windows publikuje na przełączniku wirtualnym dla pomocniczej maszyny wirtualnej.

Ten układ jest stabilny przy zwykłych zmianach sieci, bo jest zapisywany raz i wielokrotnie używany. Układ przestaje być poprawny, gdy klient tunelu przepisuje listę adapterów hosta po tym, jak pomocnicza maszyna wirtualna już wystartowała.

Nic wewnątrz dystrybucji nie obserwuje tej zmiany, więc plik nadal wskazuje adres, którego może już nie być na ścieżce. Następne zapytanie wtedy czeka, kończy się przekroczeniem czasu lub dostaje odpowiedź z serwera, który nigdy nie słyszał o strefie wewnętrznej. Od środka resolver po prostu przestaje odpowiadać i wszystkie nazwy zawodzą naraz.

Najpierw zbierz dowody po obu stronach

Zapisz, co widzi dystrybucja, a potem co widzi Windows, zanim zmienisz którąkolwiek z nich. Właśnie oba widoki razem rozróżniają tryby awarii.

Wewnątrz dystrybucji wypisz plik resolvera, tablicę routingu oraz jedno zapytanie wewnętrzne i jedno publiczne:

ip -4 route
cat /etc/resolv.conf
getent hosts intranet.corp.example
getent hosts example.com

W Windows wypisz serwery DNS na adapter oraz tablicę IPv4 z metrykami. Klient VPN zwykle instaluje trasę dla podsieci WSL2, a jej metryka decyduje, czy ten ruch wyjdzie przez tunel, czy zostanie lokalnie.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

Metryka trasy czy nieaktualny plik

Pierwsza awaria to nieaktualny plik. Resolver został zapisany dla stanu adaptera przy starcie, a tunel ten stan zmienił. Jego adres stub może być teraz nieosiągalny albo wskazywać serwer, który nic nie wie o strefie wewnętrznej.

Druga to problem routingu. Gdy VPN dodaje trasę obejmującą podsieć WSL2 z metryką niższą niż trasa łącza hosta, pakiety adresowane do pomocniczej maszyny wirtualnej wchodzą do tunelu. Wtedy przekroczenie czasu dotyczy każdej usługi WSL2, nie tylko DNS.

Test rozstrzygający kosztuje jedną linię. Jeśli adres liczbowy, na przykład publiczny resolver, nadal odpowiada na ping, gdy nazwy zawodzą, ścieżka jest nienaruszona i problemem jest DNS. To przypadek, w którym zmiana resolvera jest uzasadniona, a przypadek, w którym nie jest, też staje się oczywisty. Jeśli test liczbowy również zawiedzie, pomocnicza maszyna wirtualna straciła trasę i żaden plik resolvera tego nie naprawi.

W przypadku routingu usuń automatyczną metrykę z adaptera tunelu i nadaj mu liczbę powyżej trasy łącza WSL2:

Get-NetAdapter | Where-Object InterfaceDescription -Match VPN | Set-NetIPInterface -InterfaceMetric 5500
wsl.exe --shutdown

Wyłączenie ma znaczenie. Zmiana metryki nie przepisuje działającej pomocniczej maszyny wirtualnej, więc dystrybucję trzeba przebudować, zanim zmiana będzie widoczna.

Przejmij plik, świadomie

Jeśli routing jest poprawny i zawodzą tylko nazwy wewnętrzne, winny jest resolver i możesz zatrzymać generator. To świadoma zmiana z kosztem utrzymania, a nie obejście stosowane od niechcenia.

Utwórz /etc/wsl.conf wewnątrz dystrybucji z sekcją sieciową, która wyłącza generowanie, a potem sam napisz plik resolvera, najpierw serwer firmowy, a potem publiczny zapasowy:

[network]
generateResolvConf = false

search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

Kolejność ma znaczenie. Publiczny resolver nie odpowie na nazwę wewnętrzną, a zapas istnieje tylko dla zapytań internetowych. Gdy plik jest twój, nic go nie regeneruje, więc przenoszący się serwer firmowy staje się awarią, którą musisz sam zauważyć.

Sprawdź nazwy, potem pakiety

Zweryfikuj jedną nazwę wewnętrzną i jedną publiczną resolverem systemowym, a potem powtórz operację, która zawiodła. Menedżery pakietów czasem używają własnego resolvera, dlatego działający getent może współistnieć z zepsutą instalacją.

Jeśli automatyzujesz przepisywanie, uczyń je idempotentnym: bez tunelu zachowaj istniejący plik, zamiast zapisywać pustą listę serwerów.

getent hosts intranet.corp.example
resolvectl status | head -20
getent hosts example.com

Działające zapytanie wewnętrzne i działające zapytanie publiczne, od środka dystrybucji, to wynik wart zapisania. Zielona ikona VPN na hoście nie dowodzi żadnego z nich.