Działający publiczny DNS nie oznacza, że Active Directory da się znaleźć

VPN się łączy, przeglądarka otwiera publiczną witrynę, a laptop nadal nie może zalogować się do domeny. Zwykły wniosek jest taki, że DNS jest w porządku, bo nazwy się rozwiązują. Nie jest, a powodem jest to, że test w przeglądarce ćwiczy tylko jedno zapytanie z łańcucha, którego potrzebuje klient przyłączony do domeny. Odnajdywanie domeny najpierw pyta o rekordy usług, potem o adresy kontrolerów, które te rekordy nazywają, a na końcu o trasę do portów, na których te kontrolery nasłuchują. Publiczna odpowiedź nie zaspokaja żadnego z tych kroków.

Mit: nazwy się rozwiązują, więc DNS jest gotowy

To, że publiczna witryna się rozwiązuje, mówi tylko, że jakiś resolver odpowiedział na jedno zapytanie A lub AAAA o nazwę w strefie publicznej. Active Directory używa tego samego protokołu do innego pytania: gdzie są usługi domeny i którego kontrolera powinien użyć ten klient. Pytanie wyrażają rekordy SRV w strefie nazwanej od domeny, a rekurencyjny publiczny resolver nie ma powodu ich trzymać.

Gdy rekordu brakuje, resolver zwraca odpowiedź negatywną, co jest prawidłową odpowiedzią DNS, a nie awarią. Klient przechodzi wtedy do informacji o kontrolerach z pamięci podręcznej, jeśli je ma, i właśnie dlatego komputer stacjonarny może godzinami wyglądać dobrze, a zawieść po restarcie lub zmianie hasła.

O co naprawdę prosi klient domeny, po kolei

Dla domeny takiej jak corp.example ogólne zapytanie lokalizatora to _ldap._tcp.dc._msdcs.corp.example. Odpowiedzi SRV nazywają kandydatów na kontrolery i ich porty, a potem klient potrzebuje rekordów adresowych dla tych nazw hostów, zanim otworzy połączenie. Odnajdywanie świadome lokacji dodaje zapytania pod subdomeną lokacji, a odpowiedzi decydują, które kontrolery są preferowane, a nie który jest obowiązkowy.

nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example

Śledź łańcuch w tej kolejności, z sieci, w której pojawia się problem. Nazwa hosta, która rozwiązuje się na nieosiągalny adres, to błąd routingu, a nie błąd DNS. Osiągalny kontroler, któremu brakuje rekordów lokalizatora, to błąd DNS, a nie błąd routingu. Oba dają podobne skargi użytkowników i zupełnie różne naprawy.

Dlaczego publiczny resolver odpowiada, a logowanie i tak się psuje

Jeśli adapter daje klientowi publiczny resolver, nazwy publiczne działają, a wewnętrzna przestrzeń nazw nie. Dodanie drugiego publicznego resolvera nie pomaga, bo żaden z nich nie trzyma strefy. Ani zwykła lista „najpierw wewnętrzny, potem publiczny” nie zachowuje się jak reguła dla każdej domeny: negatywna odpowiedź pierwszego serwera jest odpowiedzią legalną, a klient nie ponawia drugiego serwera tylko dlatego, że odpowiedź była pusta.

Oba wewnętrzne resolvery, jeśli utrzymujesz dwa, muszą trzymać przestrzeń nazw AD i być osiągalne z bieżącej sieci klienta. Właśnie to psują projekty z dzielonym tunelem: VPN może nieść podsieć tunelu, podczas gdy wewnętrzny resolver siedzi na prefiksie, którego tunel nie routuje, więc zapytanie wychodzi do resolvera, który nie potrafi na nie odpowiedzieć.

Windows stosuje też zasady rozwiązywania nazw, które mogą kierować określone przestrzenie nazw do określonych serwerów, a adresy DNS pokazywane przez adapter to nie cała historia. Zmiana listy adaptera bez zmiany tej zasady może pozostawić faktyczną konfigurację nietkniętą, i dlatego poprawka, która wygląda na zastosowaną, nie ma żadnego efektu.

Utrzymuj DNS tunelu i jego trasy w zgodzie

Profil VPN, który wypycha resolver, ale nie prefiks, który go zawiera, tworzy resolver nieosiągalny dla klienta; profil, który wypycha prefiks bez resolvera, zostawia klienta pytającego lokalnego. Traktuj tę parę jako jeden element konfiguracji i sprawdzaj oba po każdej zmianie profilu, bo zmieniona kolejność wypychania lub nowa zasada dzielonego tunelu może je rozdzielić.

Sprawdź też, co klient robi z wypchniętym ustawieniem. Niektóre klienty stosują serwer DNS tylko do interfejsu tunelu i zostawiają resolver fizycznego adaptera na miejscu, więc wygrywa ten, którego wskażą metryka interfejsu i pytana nazwa. Jeśli wewnętrzna odpowiedź przychodzi tylko przy wyłączonym adapterze fizycznym, to jest mechanizm do naprawy, a nie rekordy domeny.

Przyjmij z wywołaniem odnajdywania i jedną żywą operacją

Użyteczny test odbiorczy uruchamia zapytanie lokalizatora, a potem wykonuje jedną prawdziwą uwierzytelnioną operację, na przykład otwiera udział oparty na katalogu albo prosi o bilet. Zrób to przed przejściem na VPN i ponownie po nim, na tej samej maszynie, bez restartu pomiędzy. Buforowane dane logowania i już otwarte sesje chętnie sprawią, że zepsuta ścieżka wygląda zdrowo, więc udane logowanie na pulpit nie jest testem.

Zalecenia Microsoftu dla klienta DNS wyznaczają tę samą granicę między rozwiązywaniem wewnętrznej przestrzeni nazw a przekazywaniem publicznych zapytań w górę, i to jest układ, który trzeba zachować przy wprowadzaniu VPN.

Jeśli awaria jest tylko wolna, a nie nieudana, trzymaj opóźnienie osobno od diagnozy. Przekroczenie czasu podczas odnajdywania może pochodzić z nieosiągalnego kontrolera, zablokowanego portu lub resolvera, który odpowiada późno, i żadnego z nich nie dowodzi samo czekanie. Zapisz rzeczywiste zapytanie, jego odpowiedź i próbę połączenia, zanim zmienisz ustawienie resolvera.