Dlaczego etykieta kraju w DNS nie dowodzi wycieku VPN

Zagranicznie wyglądające adresy resolverów nieustannie pojawiają się w wynikach testów DNS, a wniosek, do którego dochodzą ludzie, jest zawsze ten sam: zapytania musiały wydostać się z tunelu. Czasami tak było. Częściej raport opisuje, która usługa rekurencyjna odpowiedziała i gdzie według bazy danych znajduje się ten adres, a to stwierdzenie o infrastrukturze, nie o twoich pakietach. Rozdzielenie obserwacji i wniosku wymaga trzech faktów: kto odpowiedział, jak podróżowała nazwa i jaką politykę faktycznie skonfigurowałeś.

Przeczytaj, co test faktycznie zaobserwował

Większość stron testowych działa tak samo: proszą klienta o rozwiązanie unikalnej nazwy hosta, a potem sprawdzają, który resolver ją pobrał, albo po prostu zwracają adres resolvera zgłaszany przez klienta. To identyfikuje usługę rekurencyjną i, jeśli zapytanie niosło informacje o podsieci klienta, przybliżoną lokalizację sieciową. Nie dowodzi, że zapytanie opuściło urządzenie poza tunelem, i z pewnością nie dowodzi, że ta sama trasa została użyta dla każdej nazwy. Jedna obserwacja jednego wyszukiwania jest uogólniana na twierdzenie o całym ruchu.

Test pokazujący adres resolvera jest użyteczniejszy niż plakietka kraju, bo adres można porównać z listą resolverów, którą klient rzeczywiście otrzymał.

Anycast i przekazywanie wyjaśniają większość niespodzianek

Duże publiczne resolvery ogłaszają ten sam adres z wielu miejsc, a sieć kieruje każde zapytanie do lokalizacji najbliższej pod względem routingu. Baza geolokalizacji przypisuje potem ten adres do jednego miejsca, które może być korporacyjnym adresem rejestracyjnym na innym kontynencie albo centrum danych, które nie jest tym odpowiadającym. RFC 4786 omawia praktykę operacyjną usług anycast i trudność powiązania takiego adresu z jednym miejscem fizycznym. Mapa jest uproszczeniem decyzji routingu i upraszcza w kierunku, który daje alarmujące wyniki.

Przekazywanie dodaje drugą warstwę. Lokalny resolver stub, router lub resolver dostawcy mogą przekazywać zapytania do usługi wyżej, a nazwa widoczna w teście odzwierciedla ostatniego operatora w tym łańcuchu, a nie pierwszego. Rozszerzenia podsieci klienta mogą dopasować odpowiedź z góry do twojej sieci, jednocześnie sprawiając, że zgłaszana lokalizacja wygląda jak miejsce, w którym nigdy nie byłeś.

Skonfigurowany resolver może więc być poprawny i mimo to dawać zagranicznie wyglądający wynik, a resolver w twoim kraju może być tym błędnym, bo należy do strony, której nie wybrałeś.

Kto otrzymał nazwę i jaką trasą

Na praktyczną część odpowiadają dwa pytania: którego serwera używa klient i czy do tego serwera dociera się przez tunel. Porównaj listę resolverów z adresem w wyniku testu, zanim wyciągniesz wnioski o routingu, a potem sprawdź, czy zapytanie do tego adresu wychodzi przez interfejs tunelu. Jeśli oba adresy się różnią, ciekawym odkryciem jest to, że coś przepisało lub ominęło zamierzony resolver, i to zasługuje na uważniejsze spojrzenie niż nazwa kraju.

resolvectl query example.com
resolvectl status | grep -A3 'DNS Servers'
dig +short TXT whoami.akamai.net

Pierwsze polecenie pokazuje, który serwer odpowiedział na nazwę, drugie pokazuje skonfigurowaną listę i jej zakres, a trzecie podaje adres resolvera tak, jak widzi go usługa publiczna. Gdy wszystkie trzy się zgadzają, polityka robi to, do czego została skonfigurowana, cokolwiek mówi etykieta kraju.

Porównaj z polityką, którą wybrałeś

VPN, który wymusza resolver, przeglądarka skonfigurowana do używania własnego szyfrowanego DNS i system operacyjny, który preferuje ustawienia jednego interfejsu, mogą być osobno poprawne, a razem sprzeczne. Nowoczesne przeglądarki mogą wysyłać zapytania szyfrowanym transportem do dostawcy wybranego w przeglądarce, co celowo omija listę resolverów systemu. To nie jest wyciek w sensie zepsutego tunelu; to polityka wybrana gdzie indziej, a znalezienie, gdzie ją wybrano, jest prawdziwym zadaniem.

Urządzenia służbowe dodają reguły dla domen: nazwy wewnętrzne muszą trafiać do resolvera organizacji, podczas gdy wszystko inne idzie według domyślnych. Zastąpienie tego układu dlatego, że strona testowa pokazała nieoczekiwany kraj, to właśnie sposób, w jaki nazwy wewnętrzne przestają się rozwiązywać dla całego zespołu.

Utrzymuj testy wąskie i bezpieczne

Pytanie publicznej usługi testowej o wewnętrzną nazwę hosta ujawnia nazwę stronie, która nie ma z nią nic wspólnego, a odpowiedź nie mówi niczego, czego nie powiedziałoby lokalne przeczytanie listy resolverów.

Zamiast tego używaj nazw, które ujawniają infrastrukturę, zapisuj adres resolvera, zakres i użyty interfejs, i porównuj ten zapis z udokumentowanym zamiarem. Etykieta na mapie to kontekst rozmowy, a nie wynik zaliczony lub nie, i traktowanie jej jak wyroku tworzy zmiany konfiguracji zamiast diagnozy.