Dwa serwery DNS na jednym adapterze nie dzielą przestrzeni nazw

Wymienienie dwóch resolverów na jednym adapterze wygląda jak sposób wysłania jednej domeny do jednego serwera, a innej domeny do drugiego, i nic w liście resolverów tak nie działa. Windows rozwiązuje po nazwie, a decyzja, którego serwera zapytać, pochodzi z obiektów zasad, a nie z uporządkowanej listy adresów. Model mentalny do zastąpienia to kolejka: nie ma pierwszego serwera dla domeny A ani drugiego serwera dla domeny B. Istnieje zestaw reguł dla każdej przestrzeni nazw, który wprost nazywa serwery, i gdy te reguły istnieją, lista adaptera przestaje być interesująca.

Mit: dwa adresy dzielą dwie domeny

Przekonanie przetrwa, bo działa przypadkiem, gdy jeden serwer odpowiada na wszystko, a drugi jest tylko zapasem. Klient pyta pierwszy serwer, ten przekazuje dalej lub wykonuje rekurencję, i odpowiedź nadchodzi; nikt nie zauważa, który resolver faktycznie trzymał strefę. Iluzja pęka w momencie, gdy obie przestrzenie nazw żyją w osobnych prywatnych strefach bez przekazywania między nimi, bo wtedy pierwszy serwer odpowiada autorytatywnie, że nazwa nie istnieje. Odpowiedź negatywna z pierwszego serwera nie uruchamia zapasu, ponieważ klient otrzymał odpowiedź ostateczną, a nie awarię.

Uporządkowana lista nie zna pojęcia domeny, więc nie może wyrazić intencji. Lista naprawdę kontroluje to, którego serwera pytać najpierw, a którego próbować drugi, i obie te odpowiedzi dotyczą każdej nazwy jednakowo.

Czego Windows naprawdę używa do wyboru

Tabela zasad rozwiązywania nazw dopasowuje nazwę do skonfigurowanych przestrzeni nazw i wybiera serwery oraz opcje dla tego dopasowania. Reguły można skonfigurować lokalnie, dostarczyć przez zasady grupy lub podać z profilu VPN, a efektywne zasady to kombinacja, a nie jedna lista. Dlatego pierwsza diagnostyka zawsze dotyczy stanu efektywnego: reguła utworzona lokalnie, która przegrywa z zasadami zarządzanymi, daje laboratorium zachowujące się zupełnie inaczej, niż sugeruje jego konfiguracja. Reguły są też dopasowywane według szczegółowości, więc szeroki wpis przestrzeni nazw może przesłonić wąski w sposób niewidoczny na liście skonfigurowanych elementów. Odczytanie efektywnej kolejności to jedyny sposób, by zobaczyć, która reguła wygrywa.

Get-DnsClientNrptRule
Get-DnsClientNrptPolicy -Effective

Pierwsze polecenie wymienia, co jest skonfigurowane na maszynie; drugie pokazuje, co klient rzeczywiście zastosuje, łącznie z wpisami pochodzącymi z innych miejsc. Jeśli efektywne wyjście zawiera zarządzane przestrzenie nazw, właściciel tych zasad jest właściwym miejscem, by poprosić o zmianę, a nie lokalna lista reguł. Oba polecenia tylko czytają stan, więc uruchomienie ich, zanim ktokolwiek zgodzi się na zmianę, nic nie kosztuje.

Jedna reguła na przestrzeń nazw, zachowaj obiekt

Gdy stan efektywny jest zrozumiały, utwórz jedną regułę na przestrzeń nazw i zachowaj obiekt, który zwraca każde polecenie. Nazwy wyświetlane są etykietami dla ludzi, a unikalny identyfikator w zwróconym obiekcie jest potem pewnym celem usunięcia. Zapisz oba identyfikatory w tej samej notatce o zmianie, która rejestruje przestrzenie nazw i resolvery, ponieważ sesja, która je utworzyła, nie będzie sesją, która sprząta.

$svcRule = Add-DnsClientNrptRule -Namespace ".svc.internal.example" -NameServers "10.60.0.53" -DisplayName "VPN lab services" -PassThru
$resRule = Add-DnsClientNrptRule -Namespace ".research.internal.example" -NameServers "10.61.0.53" -DisplayName "VPN lab research" -PassThru
$svcRule | Select-Object Name, Namespace, NameServers
$resRule | Select-Object Name, Namespace, NameServers

Kropka na początku oznacza dopasowanie sufiksu, więc reguła obejmuje app.svc.internal.example i wszystko poniżej. Dwa adresy tutaj należą do własnego planu routingu tego laboratorium; reguła nie tworzy strefy, nie instaluje trasy ani nie autoryzuje aplikacji, która ostatecznie się łączy, a dokumentacja Add-DnsClientNrptRule dokładnie opisuje, który parametr co robi.

Zwróć uwagę, czego te polecenia nie robią: są dla całej maszyny, nie są ograniczone do sesji VPN, i przeżywają zamknięcie okna. Laboratorium, które o tym zapomina, zostawia zasady po zniknięciu tunelu.

Udowodnij, że klient wybrał serwer

Zapytanie konkretnego serwera, czy zna nazwę, dowodzi, że serwer potrafi odpowiedzieć, co nie jest tym samym twierdzeniem, że klient wybrał ten serwer. Test, który ma znaczenie, rozwiązuje prawdziwą nazwę zwykłą ścieżką klienta i następnie potwierdza, który resolver się nią zajął, najlepiej gdy tunel dostarczający trasę jest włączony. Jeśli tunel jest wyłączony, poprawnie ograniczona reguła nadal wskazuje nieosiągalny serwer, a to problem routingu, nie zasad. Przetestuj oba stany, aby można je było później rozróżnić.

Resolve-DnsName app.svc.internal.example
Resolve-DnsName build.research.internal.example
Resolve-DnsName app.svc.internal.example -DnsOnly -NoHostsFile

Uważaj na odpowiedzi z pamięci podręcznej z okresu przed istnieniem reguł i na aplikacje, które całkowicie omijają resolver systemowy własnym szyfrowanym DNS. Sufiksy wyszukiwania to kolejna osobna funkcja: reguła może wybrać resolver dla pełnej nazwy, nie ucząc Windows rozwijania samej nazwy hosta do tej przestrzeni nazw.

Usuń dokładnie to, co utworzyłeś

Sprzątanie to miejsce, w którym laboratorium staje się przestrogą. Usunięcie każdej reguły na maszynie jest szybkie i usuwa zasady, na których polega ktoś inny, więc użyj identyfikatorów zapisanych przy tworzeniu reguł i odczytaj ponownie stan efektywny, aby potwierdzić, że maszyna wróciła tam, gdzie zaczynała. Jeśli sesja, która je utworzyła, już nie istnieje, notatka o zmianie jest jedynym miejscem, w którym identyfikatory istnieją. Dlatego zapisuje się je przed uruchomieniem pierwszego polecenia, a nie po nim.

Remove-DnsClientNrptRule -Name $svcRule.Name -Force
Remove-DnsClientNrptRule -Name $resRule.Name -Force
Get-DnsClientNrptPolicy -Effective

Przy wdrożeniu, a nie laboratorium, kwestia czasu życia liczy się tak samo jak reguła. Profil VPN może nieść reguły przestrzeni nazw i wybrać, czy pozostają po połączeniu; reguła, która pozostaje, gdy resolver jest nieosiągalny, sprawia, że klienci preferują martwy serwer, a reguła ograniczona do połączenia znika wraz z tunelem. Zdecyduj, które z tych zachowań jest potrzebne usłudze, oznacz, kto jest właścicielem reguły, i pozostaw podział uprawnień udokumentowany obok profilu, a nie w czyjejś pamięci o laboratorium.