Awaryjny DNS w VPN: dokąd naprawdę trafia zapytanie

Ustawienie resolvera przełącza się z adresu prywatnego na publiczny, a wniosek przychodzi natychmiast: tunel przecieka. Czasem tak jest. Często jednak zapytanie awaryjne nadal podróżowało wewnątrz tunelu do resolvera wybranego przez administratora, co czyni z tego decyzję polityki, a nie usterkę. Rozdzielenie tych przypadków wymaga trzech faktów zamiast jednego, a pierwszym z nich jest to, kto odpowiedział. Ustal, kto otrzymał zapytanie, która trasa je niosła i o jakie nazwy pytano.

Tryb awaryjny to polityka, a nie jedno zachowanie

Każdy klient musi zdecydować, co robi, gdy preferowany resolver przestaje odpowiadać. Może zablokować rozwiązywanie, ponowić próbę, użyć skonfigurowanej alternatywy albo zdać się na system operacyjny, a z punktu widzenia prywatności to cztery różne produkty. Odczytanie ekranu ustawień mówi, jakie zachowanie jest skonfigurowane; nie mówi, które wystąpiło. Ekran z jednym przełącznikiem nie opisuje czterech możliwości.

Przeglądarki dodają własną warstwę. Przeglądarka z włączonym bezpiecznym DNS może rozwiązać nazwę przez własnego wybranego dostawcę, nawet gdy system operacyjny wskazuje gdzie indziej, co oznacza, że polityka klienta tunelu może nigdy nie zostać zapytana w sprawie żądań, na których naprawdę ci zależy. Sprawdź aplikację, która wysłała żądanie, a nie tylko ustawienie systemowe.

Tożsamość zastępczego resolvera to pierwszy fakt, który warto ustalić. Publiczny resolver należący do dostawcy, któremu już ufasz, to inna sytuacja niż adres dostarczony przez sieć, w której akurat jesteś. Sam adres rzadko mówi, na który z tych dwóch patrzysz.

Kto odbiera zapytanie po przełączeniu

Odbiorca i trasa są niezależne, a tylko ich kombinacja opisuje ekspozycję. Publiczny resolver osiągnięty przez tunel nigdy nie widzi adresu twojej sieci dostępowej, natomiast ten sam resolver osiągnięty bezpośrednio go widzi. Oba przypadki dają odpowiedź, a test wycieku, który raportuje tylko adres resolvera, opisze je identycznie. Czytając wynik, pytaj o interfejs, a nie tylko o adres.

Nazwy wewnętrzne czynią różnicę konkretną. Publiczny resolver zwykle nie potrafi odpowiedzieć na nazwę split-horizon, więc zapytanie kończy się niepowodzeniem, choć nazwa została już ujawniona stronie, która nie powinna jej widzieć. Dostępność i prywatność idą tu więc razem, zamiast być wymieniane.

Tunel może też nieść zapytanie do resolvera, którym nie zarządza dostawca VPN, ponieważ tunel przekazuje, a nie rozwiązuje. Host przekazujący widzi zapytanie jawnym tekstem, a następnie otwiera własne połączenie dalej, co chroni następny skok, nie chroniąc pierwszego.

Sprawdź trasę i odbiorcę razem

Obserwuj pakiety, a nie konfigurację. Zapytaj system, który resolver zostałby użyty, a następnie potwierdź, że zapytanie rzeczywiście wyszło z oczekiwanego interfejsu na oczekiwany adres.

resolvectl status | grep -E "Current DNS Server|DNS Servers|DNSOverTLS"
dig +short example.com
tcpdump -ni any udp port 53 or tcp port 853

Jeśli przechwycenie pokazuje, że zapytanie opuszcza interfejs fizyczny, gdy tunel jest aktywny, tryb awaryjny ominął tunel niezależnie od tego, co mówi lista resolverów. Jeśli pojawia się ono na interfejsie tunelu, pytanie staje się tym, kto obsługuje drugi koniec i co przechowuje.

Powtórz sprawdzenie dla jednej nazwy wewnętrznej i jednej publicznej. Zapytanie wewnętrzne to miejsce, w którym konfiguracja awaryjna zwykle się ujawnia, ponieważ resolver, który nie potrafi odpowiedzieć, mimo wszystko otrzymuje pytanie.

Zdecyduj, czy tryb awaryjny powinien być dozwolony

Jeśli wymaganiem jest, by rozwiązywanie zatrzymało się, gdy preferowany resolver jest niedostępny, skonfiguruj politykę egzekwowania, która zawodzi w trybie zamkniętym, i zaakceptuj konsekwencję: nazwy nie będą rozwiązywane podczas awarii. To świadoma wymiana dostępności, a nie usterka, i projekt powinien to powiedzieć, zanim awaria nastąpi.

Jeśli wymaganiem jest tylko to, by zapytania nie podróżowały poza tunel, publiczny resolver osiągnięty przez tunel może być dopuszczalny pod warunkiem zrozumienia operatora i jego polityki retencji. Taka akceptacja jest osądem o osobie trzeciej, a nie twierdzeniem o kryptografii, i należy do tego, kto odpowiada za twierdzenie o prywatności. Jeśli nazwy wewnętrzne mają nadal działać, tryb awaryjny musi być resolverem utrzymującym strefy wewnętrzne, co zwykle oznacza, że celem awaryjnym jest inny serwer, a nie inna rodzina adresów.

Udokumentuj wynik jako zdanie o zachowaniu: który resolver odbiera zapytania w normalnej pracy, który odbiera je po awarii i czy nazwy wewnętrzne rozwiązują się w drugim przypadku. Test wycieku, który ostatecznie ładuje stronę, dowodzi mniej niż to zdanie, ponieważ strona może się załadować przez resolver, którego nigdy nie należało pytać.