Zezwól na DNS tylko przez własny resolver VPN: przegląd krok po kroku

Prześledź jedno zapytanie o nazwę od chwili, gdy ją wpiszesz. Przeglądarka pyta system operacyjny, system operacyjny pyta resolver wybrany przez jego politykę, a zapytanie opuszcza urządzenie jakimś interfejsem z jakimś transportem. Twój projekt VPN mówi, że odpowiedź powinna przyjść z konkretnego resolvera konkretną drogą. Luka między tymi dwoma zdaniami to właśnie to, co konfigurujesz, a potem egzekwujesz.

Krok 1: nazwij resolver i ścieżkę

Zapisz trzy rzeczy, zanim dotkniesz zapory: adres resolvera, protokół i port, których oczekujesz, oraz interfejs, którym zapytanie ma wyjść. Bez tej listy reguła jest domysłem na temat ruchu, a nie egzekwowaniem decyzji. VPN może nieść dane aplikacji, podczas gdy DNS działa według osobnego układu, i samo w sobie nie jest to błędem. Tak dzieje się wtedy, gdy nikt nie powiedział klientowi nic innego.

Wyraźne nazwanie ścieżki to różnica między projektem a przypadkiem. Daje też coś do późniejszego testowania, bo każde spostrzeżenie można porównać z zapisanym oczekiwaniem. Trzymaj tę listę w zgłoszeniu zmiany, a nie w czyjejś głowie.

Krok 2: ustaw politykę tam, gdzie naprawdę mieszka

Wybór resolvera należy do klienta: konfiguracja sieci systemu operacyjnego, własne ustawienia klienta VPN albo zarządzana polityka przeglądarki. Ustaw ją najpierw tam, mechanizmem wspieranym przez platformę, bo zapora nie może zmusić klienta do wyboru resolvera, o którym nigdy mu nie powiedziano. Na kliencie z dzielonym tunelem powiedz wprost, które domeny idą do wewnętrznego resolvera. W zarządzanym parku polityka przeglądarki jest często jedyną dźwignią dla DoH, bo przeglądarka może wybrać własny zaszyfrowany resolver niezależnie od ustawienia systemowego.

Pomiń to i przejdź od razu do zapory, a dostaniesz regułę zezwalającą właściwemu resolverowi oraz klienta, który nigdy z niej nie korzysta. Reguła wygląda poprawnie, a logi resolvera pozostają puste, co jest mylącą parą przy diagnozowaniu. Najpierw skonfiguruj wybór, potem go wyegzekwuj.

Krok 3: egzekwuj ścieżkę wąsko

Teraz dodaj zezwolenie sieciowe dla dozwolonej ścieżki: adres resolvera, protokół i port oraz interfejs, którym ma wyjść. Trzymaj regułę ograniczoną do tego resolvera, zamiast zezwalać na cały wychodzący DNS. Trzy ścieżki poniżej to te, które może wybrać nowoczesny klient, i tylko pierwszą obejmuje reguła portu 53.

Blokowanie DoH i DoT jest legalne; zakładanie, że reguła portu 53 już je zablokowała, nie jest. Przeglądarka z DoH rozwiązuje nazwy ścieżką, której twoja reguła nigdy nie opisała, a aplikacja z własnym resolverem robi to samo. Zapisz każdą ścieżkę, którą zamierzasz zezwolić, i każdą, którą zamierzasz odrzucić. Reguła, która nie nazywa ścieżki, nie zdecydowała o niej.

Krok 4: śledź nazwy prywatne i publiczne

Dzielony DNS celowo wysyła tylko prywatne przestrzenie nazw do wewnętrznego resolvera, podczas gdy nazwy publiczne idą gdzie indziej, więc więcej niż jeden resolver w projekcie nie jest wyciekiem. Wyciek to zapytanie, które powinno pójść do twojego resolvera, a trafia gdzie indziej, albo nieosiągalna zamierzona ścieżka, przez którą klient po cichu się cofa. Takie dwa przypadki trzeba wytropić. Prześledź jedną nazwę wewnętrzną i jedną publiczną w ramach zamierzonej polityki i zanotuj, który resolver odpowiedział na każdą.

Strona testowa raportująca twój resolver jest wskazówką, nie dowodem, bo widzi tylko te zapytania, które do niej dotarły. Przechwyć zapytanie po stronie klienta, gdy musisz wiedzieć, którą ścieżką naprawdę poszło, i porównaj oba spostrzeżenia. Kiedy się nie zgadzają, znalazłeś ciche cofnięcie, którego nikt nie udokumentował.

Jeśli adres resolvera jest poprawny, ale nieosiągalny, problem leży w routingu lub filtrowaniu, a nie w polityce. Prześledź zapytanie do tego adresu i potwierdź, że odpowiedź wraca oczekiwanym interfejsem, zanim zmienisz jakiekolwiek ustawienie resolvera.

Krok 5: zostaw drogę powrotną

Zanim zaostrzysz dostęp do DNS na bramie, potwierdź metodę odzyskiwania, która nie zależy od rozwiązywania nazw. Zepsuty resolver utrudnia dotarcie do każdego narzędzia naprawczego, w tym do tych, którymi wycofałbyś zmianę. Trzymaj lokalną konsolę lub ścieżkę poza pasmem otwartą, dopóki nowa polityka nie zostanie udowodniona. Usuń ją dopiero wtedy, gdy polityka przetrwa ponowne połączenie.

Po ponownym połączeniu lub aktualizacji polityki przeglądarki sprawdź ponownie stan efektywny, bo oba mogą zmienić resolver bez zmiany twojej reguły. Wymogiem jest znany odbiorca i chroniona ścieżka dla zapytań, a nie uspokajająca etykieta resolvera na jednym zrzucie ekranu. Specyfikacja RFC 8484 dla DNS over HTTPS jest punktem odniesienia dla zaszyfrowanej ścieżki, której twoja reguła portu nie widzi.