Czy DNS Twojego VPN jest naprawdę używany? Przechwyć port 53 i zobacz

Zapytaj większość ludzi, co klient VPN robi z DNS, a powiedzą, że ustawia resolver, więc zapytania podróżują wewnątrz tunelu. Wypchnięcie jest prawdziwe; założenie, że staje się zapytaniem, nie. Między wypchniętą opcją a pakietem na przewodzie stoją trzy etapy, a każdy zawodzi niezależnie w sposób, który wygląda jak zepsuty serwer DNS. Dlatego strona testu wycieku i działająca przeglądarka mogą nie zgadzać się co do tej samej maszyny w tej samej chwili.

Wypchnięta opcja nie jest zapytaniem

Etap pierwszy to serwer oferujący ustawienia, na przykład wypchnięta opcja DNS wskazująca resolver wewnątrz tunelu. Etap drugi to klient stosujący te ustawienia do interfejsu. Etap trzeci to aplikacja faktycznie wysyłająca zapytanie na ten adres. Awaria na drugim etapie zostawia opcję widoczną w logu połączenia, podczas gdy lista resolverów pozostaje niezmieniona, a awaria na trzecim etapie zostawia całkowicie poprawną listę resolverów nieużywaną.

Większość diagnostyki zlepia te trzy w jeden i obwinia serwer VPN, który zwykle jest jedyną stroną mogącą dowieść, że wykonała swoją część. Czytaj zamiast tego rzeczywisty stan resolvera klienta, a potem obserwuj wyjście jednego zapytania. Te dwa spostrzeżenia oddzielają konfigurację od routingu i od polityki, i kosztują około pięciu minut. Zachowaj zrzuty, bo następny inżynier chce stanu przed i po, a nie ich opisu.

Sprawdź, co interfejs naprawdę trzyma

W Linuksie resolverem systemowym może być zwykły plik, NetworkManager albo systemd-resolved, a to, który z nich go posiada, decyduje, gdzie wyląduje wypchnięty serwer. Proces OpenVPN z linii poleceń nie aktualizuje resolvera systemowego sam, więc udokumentowaną integracją jest skrypt up/down albo menedżer połączeń, który już wie, jak stosować ustawienia. Uruchamianie obu to skuteczny sposób tworzenia wyścigu.

resolvectl status
cat /etc/resolv.conf

W Windowsie lista jest na kartę, więc karta tunelu może trzymać serwery wewnętrzne, podczas gdy karta fizyczna zachowuje lokalne i wygrywa dla niektórych nazw. Porównuj obie karty, a nie tę, którą uznajesz za aktywną.

Śledź jedno zapytanie poza maszynę

Przechwyć oba interfejsy jednocześnie, a potem rozwiąż jedną nazwę, która powinna korzystać z resolvera wewnętrznego. Ta para zrzutów odpowiada na to, na co nie odpowie żadne wyjście konfiguracji.

sudo tcpdump -ni tun0 port 53
sudo tcpdump -ni any port 53

Zapytanie, które pojawia się na interfejsie fizycznym i nigdy w tunelu, oznacza, że klient wybrał zły resolver. Zapytanie, które nie pojawia się na żadnym z nich, oznacza, że aplikacja odpowiedziała z pamięci podręcznej, zapytała stub nasłuchujący na loopbacku albo użyła szyfrowanego resolvera, którego ruch nigdy nie pojawia się jako port 53. Przechwytuj też odpowiedzi, nie tylko zapytania, bo zapytanie wychodzące przez tunel z odpowiedzią z publicznego adresu to inna usterka niż brak jakiejkolwiek odpowiedzi.

Zapora, która akceptuje tylko własny DNS

Komercyjni klienci czasem instalują własne łańcuchy filtrów. Jeden udokumentowany wzorzec pozwala na DNS do własnego resolvera klienta i wyrzuca cały pozostały ruch UDP na porcie 53, który próbuje opuścić interfejs inny niż loopback, w tym ruch, który użytkownik celowo skierował gdzie indziej. Zapytania demona znikają bez śladu, co czyta się jako awaria resolvera, a nie jako filtr.

sudo iptables -S OUTPUT
sudo iptables -S | grep -i -E 'dns|53'

Jeśli reguła odrzucania jest oceniana przed Twoim wyjątkiem, dodana reguła nigdy nie zostanie osiągnięta, więc wstaw ją na pierwszej pozycji i ogranicz cel do resolvera, który naprawdę masz na myśli.

sudo iptables -I OUTPUT 1 -p udp --dport 53 -d 172.20.8.1 -j ACCEPT

Ten wyjątek jest diagnostyczny, a nie polityczny. Jeśli reguła dostawcy jest celowa, wspieraną naprawą jest skonfigurowanie klienta tak, aby zezwalał na ten resolver, i zapisanie decyzji, bo wstawiona reguła nie przetrwa następnej aktualizacji klienta.

Dlaczego strona wycieku dowodzi mniej, niż wygląda

To, co pokazuje strona testu wycieku, to resolver, który rozmawiał z operatorem testu, a nie ten, z którym konsultowała się Twoja maszyna. Lokalny forwarder rekursujący na zewnątrz umieszcza swój własny adres wyjściowy na tej stronie, a szyfrowane zapytania mogą zostawić stronę całkowicie pustą. Oba wyniki są czytane źle, jeden jako wyciek, drugi jako gwarancja, i żaden z tych odczytów nie wynika z obserwacji.

Obronnym dowodem jest zrzut: interfejs, adres docelowy, odpowiedź i znacznik czasu. Zrób jeden, zanim tunel wstanie, i jeden potem, a następnym razem, gdy nazwa zawiedzie, porównaj je. Ta para mówi też następnej osobie, czy usterka była w rozwiązywaniu, routingu czy we własnej polityce dostępu resolvera.