Dlaczego WSL traci nazwę hosta roboczego, gdy łączy się VPN?

Windows rozwiązuje wewnętrzny host bez żadnych skarg, a ta sama nazwa zawodzi w WSL w momencie, gdy tunel się podnosi. Zwykła naprawa polega na wpisaniu publicznego resolvera do dystrybucji, co przywraca normalne przeglądanie i czyni nazwę hosta roboczego nierozwiązywalną. To zamienia jeden błąd na drugi i ukrywa warstwę, która naprawdę się zepsuła. Zanim dodasz lub usuniesz dowolny wiersz resolvera, ustal, która z trzech warstw zawodzi.

Najpierw wyklucz błąd routingu

Odpytaj tę samą pełną nazwę kwalifikowaną po obu stronach, a nie dwie podobne nazwy. Sukces w Windows i błąd w WSL dla tego samego ciągu to sygnatura dwóch ścieżek rozwiązywania, a niewiele innych rzeczy daje ten wzorzec tak czysto. Jeśli WSL nie dociera do usługi także pod jej znanym adresem numerycznym, występuje również problem routingu lub filtrowania. W takim przypadku praca nad DNS tego nie ujawni, a popołudnie pójdzie na niewłaściwą warstwę.

Trzy objawy obejmują większość takich przypadków, a każdy wskazuje gdzie indziej. Przeczytaj pasujący wiersz, zanim otworzysz plik konfiguracyjny:

Środkowy wiersz jest tym, który ludzie czytają źle, ponieważ zmiana, która go zepsuła, została wprowadzona tygodnie wcześniej i wtedy wyglądała na udaną. Trzeci wiersz jest tym, który ludzie diagnozują źle, ponieważ nazwa, która się rozwiązuje, wydaje się dowodem, że sieć jest zdrowa. Oba wiersze kierują cię do innej sekcji poniżej.

Tunelowanie DNS ma dolną granicę wersji

Microsoft dokumentuje tryb sieciowy WSL, który tuneluje żądania DNS do resolvera Windows przez kanał wirtualizacji. W obsługiwanych kompilacjach Windows 11 jest włączony domyślnie i dlatego dwie maszyny w tej samej sieci firmowej zachowują się różnie. Zmienną jest numer kompilacji, a nie polityka firmy.

Przewodnik po sieciach WSL opisuje ten tryb i wersje, które go obsługują. Funkcja ma znaczenie, ponieważ firmowa polityka DNS zwykle mieszka w resolverze Windows, a dystrybucja, która dziedziczy ścieżkę Windows, dziedziczy też politykę. Dystrybucja odpytująca publiczny resolver nie ma żadnej trasy do nazwy prywatnej, choćby jej własna konfiguracja wyglądała najschludniej. Ten mechanizm wyjaśnia cały objaw i wyjaśnia, dlaczego obejście z publicznym resolverem zawodzi.

Przeczytaj kompilację, zanim cokolwiek edytujesz. Ustawienie skopiowane z nowszej instalacji nie jest dowodem, że starsza je implementuje. Zapisz numer kompilacji obok zmiany, ponieważ różnica między dwiema maszynami prawie zawsze jest wersją, a nie polityką.

Stare nadpisania przeżywają problem, który rozwiązały

Starsze przepisy wyłączały generowane pliki resolvera, zakodowały na stałe serwer nazw lub zablokowały plik atrybutem niezmienności. Te zmiany pozostają na miejscu długo po tym, jak problem z łącznością, który je wywołał, zniknął, i zwykle to one są powodem, dla którego nowsze ustawienie wydaje się nic nie robić. Przeżywają też reinstalację dystrybucji w postaci profilu powłoki, który przepisuje plik przy każdym logowaniu. Ostatni jest najtrudniejszy do znalezienia, ponieważ jest niewidoczny z pliku, który wszyscy sprawdzają.

Szukaj ręcznie napisanego pliku resolvera, atrybutu niezmienności na nim i skryptu startowego, który go przepisuje. Sprawdź flagę niezmienności przed edycją, ponieważ zapis do zablokowanego pliku kończy się w sposób, który czyta się jak problem z uprawnieniami. Następnie sprawdź profil powłoki, ponieważ skrypt tam przywraca starą zawartość w kilka sekund po twojej poprawce.

Usunięcie nadpisania ma konsekwencje, więc zapisz, co usunąłeś i dlaczego. Dystrybucja, która naprawdę potrzebuje statycznego resolvera do innego celu, zepsuje się, gdy wygenerowany plik wróci.

Dwa pliki, dwie różne role

Oba pliki konfiguracyjne mieszkają w różnych miejscach i kontrolują różne rzeczy, a mylenie ich daje zmiany zastosowane do niewłaściwej warstwy. Plik po stronie Windows ustawia właściwości maszyny wirtualnej, natomiast plik po stronie dystrybucji ustawia, jak ta dystrybucja buduje własną konfigurację resolvera. Żaden nie nadpisuje drugiego, dlatego oba muszą się zgadzać.

Dla instalacji, która obsługuje tę funkcję, fragment po stronie Windows jest krótki. To cała zmiana po tej stronie:

[wsl2]
dnsTunneling=true

Ten fragment należy do profilu użytkownika Windows i dotyczy maszyny wirtualnej, a nie jednej dystrybucji. Tunelowanie wymaga też, aby dystrybucja nie wyłączyła generowania resolvera, więc plik po stronie dystrybucji musi zostawić to zachowanie w spokoju. Zmień jedno bez drugiego, a tryb po cichu nic nie robi, i to jest najczęstszy sposób zgłaszania tej naprawy jako zepsutej. Sprawdź oba pliki w tej samej sesji, ponieważ dwie zmiany wykonane w odstępie tygodni to dwie zmiany, których nikt nie może przypisać.

Uruchom ponownie, a potem odpytaj z obu stron

Te ustawienia są czytane przy starcie środowiska, więc nowa powłoka w działającej dystrybucji ich nie przeładuje. Wyłącz środowisko zamiast restartować powłokę i najpierw zapisz ewentualną uruchomioną pracę, ponieważ każda dystrybucja zatrzymuje się razem z nim. Samo to przeoczenie wyjaśnia większość zgłoszeń o braku efektu zmiany.

Następnie zadaj to samo pytanie z obu stron. Wynik pokazuje też, z jakim resolverem dystrybucja faktycznie została:

wsl.exe --shutdown
wsl.exe -e sh -c 'cat /etc/resolv.conf'
wsl.exe -e sh -c 'getent hosts files.corp.example'
wsl.exe -e powershell -Command 'Resolve-DnsName files.corp.example'

Pierwsze polecenie kończy środowisko, drugie pokazuje, jakiego resolvera dystrybucja używa teraz, a ostatnie dwa zadają to samo pytanie każdej stronie. Porównuj odpowiedzi, a nie stan ustawienia. Zapytanie, które nadal zawodzi po czystym restarcie przy obu poprawnych plikach, wskazuje na firmową politykę resolvera, a ta rozmowa ma innego właściciela.