Czy Twój VPN szyfruje DNS, czy tylko następny przeskok?

Włączanie szyfrowanego DNS na serwerze VPN bywa opisywane jako zamykanie wycieku, a ten opis ukrywa, które połączenie się zmieniło. Przeskok od klienta do resolvera i przeskok od resolvera do nadrzędnego to osobne połączenia z osobnymi właścicielami. Zaszyfrowanie jednego pozostawia drugie dokładnie takie, jakie było.

Zapisz, kto odbiera zapytanie na każdym etapie, zanim dotkniesz pliku konfiguracji.

Dwa układy wyglądają tak samo na stronie ustawień

W pierwszym układzie urządzenie samo uruchamia DNS over TLS, a tunel po prostu przenosi to połączenie do wybranego resolvera. Sesja TLS kończy się na resolverze, co oznacza, że resolver widzi zapytanie, a wyjście VPN widzi zaszyfrowany tekst, którego nie potrafi odczytać. W drugim układzie urządzenie wysyła zwykły DNS przez tunel do przekaźnika na hoście VPN, a ten przekaźnik otwiera własne szyfrowane połączenie z resolverem nadrzędnym. Na liście funkcji oba wyglądają jak "szyfrowany DNS z VPN", ale umieszczają czytelne zapytanie w różnych budynkach.

Różnica jest mierzalna, a nie filozoficzna. Poszukaj sesji TLS na kliencie albo na serwerze i dowiesz się, który układ naprawdę masz.

Zmapuj łańcuch resolverów, zanim go zmienisz

Policz resolvery na ścieżce i nazwij rolę każdego z nich. Komponent przekazujący oddaje żądanie innemu resolverowi, natomiast resolver rekurencyjny wykonuje pracę polegającą na znalezieniu odpowiedzi i może rozmawiać bezpośrednio z serwerami autorytatywnymi. Te role zdefiniowano osobno dokładnie z tego powodu, a definicje resolverów z RFC 9076 są warte przeczytania, zanim założysz, że istnieje jeden nadrzędny cel. Host uruchamiający własny resolver rekurencyjny nie ma jednego "nadrzędnego" do szyfrowania, co unieważnia cały plan.

Następnie zapytaj, którego komponentu klient jest skonfigurowany używać. Adres DNS dostarczany przez profil VPN mówi, dokąd trafiają zapytania, a nie który proces na nie odpowiada.

Zwróć też uwagę na zachowanie przy awarii. Jeśli szyfrowany nadrzędny resolver stanie się nieosiągalny, czy przekaźnik zawodzi bezpiecznie, wraca do tekstu jawnego, czy przełącza się na inny resolver? Ta decyzja należy do zapisu, ponieważ zmienia gwarancję prywatności w momencie, gdy tunel jest najmniej zdrowy.

Sprawdź, który przeskok jest szyfrowany

Zacznij od klienta i potwierdź, czy utrzymuje sesję TLS na porcie 853. Zapytanie, które poprawnie rozwiązuje się przez port 53, nie dowodzi niczego o szyfrowaniu.

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

Następnie przejdź na host VPN i poszukaj wychodzącego szyfrowanego połączenia, które otworzył przekaźnik. Tabela gniazd mówi, czy istnieje nadrzędna sesja TLS i który proces ją posiada:

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

Jeśli klient pokazuje sesję TLS, a serwer nie, jesteś w pierwszym układzie i serwer nie może odczytać zapytań przekazywanych na warstwie IP. Jeśli serwer pokazuje sesję TLS, a klient zwykły ruch portu 53 wewnątrz tunelu, jesteś w drugim układzie: dalszy przeskok jest chroniony, ale przekaźnik nadal czyta każdą nazwę, o którą prosi urządzenie. Ten drugi wynik nie jest awarią, lecz nazywanie go szyfrowaniem end-to-end jest błędem.

Zapisz właściciela i zachowanie przy awarii

Własność decyduje o tym, co możesz obiecać. Właściciel urządzenia kontroluje szyfrowane połączenie po stronie klienta, natomiast administrator VPN kontroluje dalsze połączenie tworzone przez jego przekaźnik. Kto nie obsługuje żadnego z nich, może jedynie opisać ścieżkę.

Zanim cokolwiek włączysz, sprawdź nazewnictwo wewnętrzne. Wysyłanie nazw organizacji do publicznego resolvera nie jest równorzędnym projektem, a strefa split-horizon istniejąca tylko wewnątrz sieci w ogóle nie zostanie rozwiązana nadrzędnie. Po zmianie przetestuj jedną nazwę wewnętrzną i jedną publiczną, a wynik zachowaj razem ze zmianą konfiguracji. Jeśli szyfrowana ścieżka psuje rozwiązywanie nazw hostów wewnętrznych, poprawką jest reguła resolvera o ograniczonym zakresie, a nie szerszy tunel.

Zakończ, pisząc jedno zdanie na przeskok: który komponent odebrał zapytanie, czy ten przeskok był szyfrowany i kto może odczytać nazwę. Gdy zdanie o hoście VPN nadal mówi, że może czytać zapytania, dokumentacja powinna to powiedzieć, ponieważ diagram twierdzący inaczej zostanie zaufany przez kogoś, kto nigdy nie uruchomił tych poleceń.