Przechwytywanie Split-DNS: powiedz, gdzie wykonano każdą obserwację

Dwie osoby diagnozują ten sam problem Split-DNS i otrzymują różne adresy resolvera. Jedna użyła narzędzia do wyszukiwania, druga przechwyciła pakiety na adapterze, a trzecia odczytała własną diagnostykę klienta. Żadna nie kłamie i żadna nie opisuje tego samego etapu. Nazwanie punktu obserwacji zamienia sprzeczność w mapę.

Jedno zapytanie, kilka punktów obserwacji

Dla jednej nazwy wewnętrznej jest co najmniej pięć miejsc do sprawdzenia: aplikacja i wywoływane przez nią API resolvera, obowiązująca polityka domenowa na kliencie, przechwycenie na adapterze lub filtrze, kontrolowana granica bramy oraz resolver, który faktycznie odbiera zapytanie.

Każde odpowiada na inne pytanie i żadne samo nie dowodzi, dokąd trafiło zapytanie.

Przechwycenie na adapterze pokazuje pakiety, a nie intencję. Nie mówi, który resolver wybrał klient, a puste przechwycenie może oznaczać odpowiedź z pamięci podręcznej lub inne API resolvera, a nie odrzucony pakiet. Traktuj każdą obserwację jako dowód dotyczący jednego etapu. Następnie złóż etapy w ścieżkę.

Filtr klienta leży między aplikacją a przewodem

Klient VPN z Split-DNS stosuje dopasowanie domen, zanim pakiet opuści maszynę. Nazwy w tunelowanym sufiksie trafiają do resolvera wewnętrznego; wszystko inne trafia do lokalnego. Filtr jest polityką, a polityka może się różnić w zależności od platformy i wersji klienta.

Wskazówki Secure Client dotyczące Split-DNS firmy Cisco obejmują dopasowanie domen i filtr Windows, a także oddzielają to, co widzi aplikacja korzystająca z natywnego API resolvera, od tego, co widzi narzędzie takie jak nslookup. Właśnie te różnice są istotne.

Zacznij od obowiązującego profilu i jednego zwykłego zapytania aplikacji. Każdy test wskazujący konkretny serwer to zamierzone obejście; wyjaśnij je własną diagnostyką klienta i nie pozwól, by stało się kryterium akceptacji.

nslookup idzie inną ścieżką niż aplikacja

nslookup buduje własne zapytanie DNS i może ominąć politykę resolvera systemu operacyjnego. Dzięki temu jest przydatnym narzędziem do zadania konkretnego pytania konkretnemu serwerowi i mylącym narzędziem do sprawdzania, czego doświadczy aplikacja.

W Windows tabela polityki rozwiązywania nazw decyduje, który sufiks korzysta z którego serwera. Jej odczyt pokazuje politykę, której będzie przestrzegać aplikacja, i to często brakujący element.

Odczytaj politykę, a następnie zadaj to samo pytanie przez zwykły resolver:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Szyfrowane resolvere ukrywają zapytanie, a nie połączenie

Przeglądarka z własnym resolverem DNS-over-HTTPS to zupełnie inny przypadek. Zapytanie wychodzi wewnątrz TLS, więc przechwycenie pakietów pokazuje połączenie z adresem resolvera, ale nie pytaną nazwę.

Najpierw ustal zarządzaną politykę przeglądarki, a potem porównaj ją z zapytaniem systemu operacyjnego. Przeglądarka, której wolno wybrać własny resolver, może w ogóle nie widzieć polityki Split-DNS.

Ta sama ostrożność dotyczy każdego klienta, który dostarcza własny resolver. Przechwycenie identyfikujące zdalne połączenie nie jest dowodem dotyczącym nazwy zapytania. Jeśli potrzebujesz nazwy, weź ją z logów samego resolvera lub z diagnostyki aplikacji, z zachowaniem obowiązujących zasad prywatności.

Porównaj z oznaczonym testem

Wybierz zatwierdzoną nazwę wewnętrzną do testu oraz nazwę publiczną, która nie niesie wrażliwego znaczenia. Dla każdej zapisz czas, typ rekordu, odpowiedź i oczekiwaną politykę.

Tam, gdzie to dozwolone, porównaj odbiór w resolverze z jedną wąską obserwacją klienta lub bramy:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

Nigdy nie wysyłaj prywatnych nazw do niepowiązanych publicznych resolverów tylko po to, by stworzyć porównanie, i redaguj wszystko, czym się dzielisz. Na koniec oddziel poprawną odpowiedź DNS od następującego po niej połączenia z usługą: rozwiązany prywatny adres nadal potrzebuje trasy i autoryzacji aplikacji.