Zły serwer DNS w Windows VPN: metryka, kolejność powiązań lub sufiks

Klient Windows może mieć działający tunel, przenosić firmowy resolver i nadal wysyłać nazwy wewnętrzne do domowego routera. O tym, który serwer odpowie, decydują trzy różne mechanizmy, i każdy zawodzi inaczej. Nie trzeba naprawiać wszystkich trzech: objaw mówi, który jest w grze. Drzewo decyzyjne poniżej zajmuje kilka minut i zapobiega zwykłemu wynikowi, w którym zmiana metryki, przestawienie rejestru i reguła NRPT trafiają razem i nikt nie wie, które z nich cokolwiek zrobiło.

Trzy mechanizmy decydują, i zwykle jeden jest błędny

Metryka interfejsu porządkuje adaptery dla danej rodziny adresów. Kolejność powiązań w Tcpip\Linkage to ogólnomaszynowa lista identyfikatorów interfejsów, do której starsze ścieżki kodu nadal zaglądają. Tabela zasad rozwiązywania nazw (NRPT) wiąże przestrzeń nazw z konkretnymi serwerami, a lista sufiksów decyduje, czy krótka nazwa w ogóle jest rozwijana. Są niezależne, dlatego poprawny resolver na adapterze VPN przegrywa z nieaktualną preferencją gdzie indziej.

Żaden z tych mechanizmów nie jest drugą stroną tunelu. Jeśli serwer, który VPN wypycha, nie potrafi rozwiązać nazwy, każde ustawienie po stronie klienta jest tylko dekoracją, więc pierwsza decyzja dotyczy tego, czy sam resolver potrafi odpowiedzieć, gdy zapyta się go wprost.

Decyzja pierwsza: czy wypchnięty resolver w ogóle potrafi odpowiedzieć?

Zapytaj serwer wprost i porównaj ze zwykłym wyszukiwaniem. Różnica między odpowiedziami oddziela problem wyboru od problemu osiągalności, i tutaj jest najszybsze rozgałęzienie:

Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type A

Jeśli pierwsze się udaje, a drugie zawodzi, resolver jest osiągalny i Windows wybiera źle; przejdź do decyzji o przestrzeni nazw i kolejności poniżej. Jeśli pierwsze też zawodzi, nic na kliencie nie pomoże: sprawdź, czy UDP i TCP 53 docierają do serwera przez tunel, czy zapora hosta na serwerze nie wyrzuca puli i czy własne przekaźniki serwera są zdrowe.

Zatrzymaj się na tym rozgałęzieniu. Zastosowanie reguły NRPT do resolvera, do którego nie można dotrzeć, daje ten sam błąd z większą ilością konfiguracji do wycofania i ukrywa rzeczywistą usterkę za regułą, która wygląda autorytatywnie.

Decyzja druga: jedna przestrzeń nazw czy każde zapytanie?

Zakres decyduje o narzędziu. Gdy zawodzą tylko nazwy firmowe, powiąż przestrzeń nazw zamiast przestawiać maszynę: reguła NRPT wysyła ten sufiks do resolvera tunelu i zostawia resztę w spokoju. Gdy dotknięte jest każde wyszukiwanie, problemem jest globalna preferencja adapterów, a metryka jest miejscem, od którego zacząć, bo nie zmienia żadnego ustawienia serwera.

Ustaw metrykę dla każdej rodziny adresów, na obu interfejsach, a potem potwierdź kolejność:

Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6

Zastąp 11 wartością ifIndex adaptera tunelu z wiersza powyżej; jeśli 11 to adapter LAN, ta sama komenda obniża niewłaściwą ścieżkę. Podniesienie adaptera LAN osiąga tę samą kolejność z drugiej strony: netsh int ip set interface interface="Ethernet" metric=15, a dla drugiej rodziny netsh int ipv6 set interface interface="Ethernet" metric=15, bo int ip dotyka tylko IPv4.

Kolejność powiązań jest ostatnią deską ratunku, a nie pierwszym krokiem. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage zawiera listę Bind identyfikatorów urządzeń, a przeniesienie identyfikatora tunelu na początek naprawdę zmienia to, który adapter jest pytany pierwszy, ale to ogólnomaszynowa wartość rejestru bez zasięgu na przestrzeń nazw. Wyeksportuj ją przed edycją i połącz tunel ponownie, aby kolejność obowiązywała w stanie, którego oczekuje klient.

Dla jednej przestrzeni nazw wybierz węższe narzędzie:

Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServers

Decyzja trzecia: czy poprawka przetrwa ponowne połączenie?

Metryka, która działa do następnego połączenia telefonicznego, nigdy nie została zapisana. L2TP/IPsec i inne profile połączeń są tworzone od nowa przy starcie połączenia, więc zapisana wartość żyje we wpisie książki telefonicznej jako IpInterfaceMetric, a nie tylko na aktywnym interfejsie. Niektóre środowiska skryptują to pole właśnie dlatego; inne wypychają preferencję z polityki zarządzania i zostawiają punkt końcowy w spokoju.

Pamięć podręczna i rejestracja to osobna warstwa. Uruchomienie ich po podniesieniu tunelu poprawia nieaktualne wpisy i rejestruje klienta ponownie, ale żadne z nich nie przestawia adaptera:

ipconfig /registerdns
ipconfig /flushdns

W tej samej warstwie jest wyłącznik. Wyłączenie rejestracji dynamicznej na adapterze fizycznym powstrzymuje klienta przed ogłaszaniem swojego adresu po stronie VPN pod niewłaściwą nazwą, co jest inną naprawą niż odświeżenie powyżej.

IPv6 zasługuje na własny wiersz w decyzji. Jeśli adapter fizyczny ma globalny adres IPv6, podczas gdy tunel przenosi tylko IPv4, Windows może preferować ścieżkę bez tunelu do rozwiązywania nazw. Sprawdź tę rodzinę osobno, bo metryka ustawiona dla IPv4 nic o niej nie mówi:

Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetric

Wyłączenie IPv6 na adapterze LAN usuwa tę ścieżkę i protokół wraz z nią; zmiana metryki na interfejsie IPv6 albo reguła NRPT dla firmowej przestrzeni nazw zachowuje rodzinę i naprawia preferencję. Wybierz węższą, chyba że zdecydowałeś, że to łącze nie powinno mieć IPv6.

Weryfikuj z nazwanym źródłem i utrzymuj jednego właściciela

Weryfikuj narzędziami, które podają, które źródło obowiązuje, a nie tylko czy strona się ładuje:

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type A

Następnie oddziel filtrowanie od wyboru, bo z wnętrza aplikacji wyglądają identycznie. block-outside-dns OpenVPN blokuje port 53 na innych adapterach; nie wybiera resolvera. Jeśli teraz każde zapytanie zawodzi, filtr może blokować jedyny osiągalny serwer; jeśli skonfigurowany resolver jest ignorowany, kolejność lub reguła przestrzeni nazw jest błędna. Zmienianie obu naraz czyni zapytanie zablokowane i zapytanie ignorowane nierozróżnialnymi.

Utrzymuj jednego właściciela polityki DNS: profil VPN, politykę zarządzania albo regułę NRPT, a nie dwie z nich. Zanim to zamkniesz:

• Wypchnięty resolver odpowiada, gdy zostanie nazwany wprost, a zwykłe wyszukiwanie go używa.
• Reguła lub metryka, którą zmieniłeś, obejmuje rodzinę adresów, która rzeczywiście przenosi zapytania.
• Ustawienie przetrwa rozłączenie i ponowne połączenie albo przeniosłeś je do zapisanego profilu.
• Dokładnie jeden mechanizm jest autorytatywny, a pozostałe pozostawiono tak, jak były.

Traktuj kolejność jako stan środowiska, a nie coś, co się kończy. Sprawdź ją ponownie po ponownym połączeniu i po aktualizacji Windows, która dotyka stosu sieciowego, bo każde z nich może znów wysunąć adapter fizyczny do przodu.