Dlaczego Private DNS w telefonie psuje rozwiązywanie nazw VPN

Aplikacje nie potrafią rozwiązać nazwy, choć tunel pozostaje połączony, a wszystkie inne wskaźniki wyglądają zdrowo. W telefonie zwykłą przyczyną jest resolver wybrany przez urządzenie, a nie przez profil VPN. Dwa ustawienia mogą każde rościć sobie władzę nad tym samym zapytaniem. Ustalenie, które wygrywa i czy w ogóle potrafi odpowiedzieć na pytanie, jest szybsze niż dotykanie tunelu.

Dwa ustawienia decydują o tej samej nazwie

Ustawienie Private DNS w telefonie wybiera resolver dla urządzenia, w trybach od automatycznego wyboru po nazwaną nazwę hosta. Profil VPN może jednocześnie narzucić własny resolver, a oba są konfigurowane na różnych ekranach i przez różnych właścicieli. Żadne nie musi nadpisywać drugiego w każdej aplikacji. Dlatego działający tunel i nieudane zapytanie mogą współistnieć bez sprzeczności.

Przeglądarka może dodać trzecią warstwę, ponieważ bezpieczny DNS w przeglądarce może wybrać własnego dostawcę. Aplikacja, która wywołała błąd, jest jedyną wiarygodną wskazówką, kto z trzech odpowiedział. Resolver też musi potrafić odpowiedzieć. Nazwa istniejąca tylko w firmie nie jest w danych publicznego resolvera, więc zapytanie zawodzi z powodu treści, a nie łączności.

Wybierz tryb według potrzebnych nazw

Jeśli urządzenie musi rozwiązywać nazwy wewnętrzne, resolver musi być tym, który trzyma te strefy, co zwykle oznacza resolver tunelu albo podzieloną konfigurację DNS dokumentowaną przez organizację. Jeśli liczą się tylko nazwy publiczne, rygorystyczny szyfrowany resolver jest obronnym wyborem, który usuwa też zapytania w otwartym tekście. Decyzja wynika z nazw, a nie z preferencji dotyczącej szyfrowania.

Zachowanie przy awarii też zależy od trybu. Rygorystyczny wybór, który nie może dotrzeć do swojego resolvera, daje awarię dla każdej nazwy, natomiast tryb z dozwolonym wycofaniem może utrzymać nazwy publiczne działające, a wewnętrzne zepsute. Ta różnica mówi, w którym trybie jesteś, zanim otworzysz ekran ustawień. Na urządzeniu zarządzanym decyduje zatwierdzona polityka, a użytkownik nie może jej bezpiecznie obejść. W konfiguracji osobistej jedno udokumentowane porównanie wystarczy do zidentyfikowania konfliktu, a zamierzone ustawienie prywatności należy potem przywrócić, a nie pozostawiać wyłączone.

Sprawdź, która aplikacja pyta

Odtwórz awarię w aplikacji, która ją zgłosiła, i zanotuj, czy błąd dotyczy nazwy, czy połączenia. Błąd nazwy w jednej aplikacji i udana strona w innej to sygnatura dwóch resolverów, a nie zepsutego tunelu.

adb shell settings get global private_dns_mode
adb shell settings get global private_dns_specifier
adb shell dumpsys connectivity | grep -i -m 5 dns

Te polecenia czytają bieżącą konfigurację urządzenia, a wersje producentów mogą zmieniać nazwy lub ograniczać wartości bazowe, więc traktuj wynik jako wskazówkę, a nie specyfikację. Dokumentacja Androida dotycząca Private DNS opisuje tryby i formę nazwy hosta, której oczekuje urządzenie.

Porównaj tę odpowiedź z resolverem narzucanym przez profil VPN. Jeśli się nie zgadzają, znalazłeś konflikt, a pozostałe pytanie brzmi, któremu organizacja chce pozwolić wygrać.

Przywróć zamierzone ustawienie po jednym porównaniu

Zmień jedno ustawienie, ponownie przetestuj obie nazwy i przywróć ustawienie. Urządzenie pozostawione w trybie pobłażliwym rozwiązuje nazwy wewnętrzne i cicho wysyła każde zapytanie publiczne do tego, kto odpowie pierwszy, co jest zmianą prywatności, której nikt nie zapisał.

Zapisz wynik jako regułę: nazwy wewnętrzne rozwiązuje ten resolver, publiczne tamten, a przeglądarka podąża za urządzeniem albo nie. Reguła, która nazywa resolver, jest sprawdzalna, natomiast notatka, że VPN naprawiono, nie jest. Następnie sprawdź, czy coś jeszcze na urządzeniu zależy od zmienionego resolvera. Sprawdzanie aktualizacji, wykrywanie portali przechwytujących i klienci poczty wysyłają własne żądania i zawodzą w sposób, który użytkownicy zgłaszają jako niepowiązane problemy.