VPN w Androidzie rozwiązuje pełną nazwę hosta, ale nie krótką

Wpisujeszfilesw emulatorze terminala i nic nie wraca; wpisujeszfiles.corp.examplei ten sam serwer odpowiada natychmiast. Nic nie zmieniło się w danych logowania VPN, a prywatny serwer DNS nigdy nie był zepsuty. W Androidzie krótka etykieta i pełna nazwa idą różnymi ścieżkami przez resolver, a jedna z tych ścieżek zależy od ustawienia, które musi dostarczyć właściciel tunelu. Decyzja przed tobą nie dotyczy tego, który serwer DNS zmienić, ale tego, kto kontroluje sieć, której aplikacja faktycznie używa.

Domena wyszukiwania nie jest adresem. To lista sufiksów, które resolver dokleja do gołej etykiety, zanim się podda.

Sufiks wyszukiwania i serwer DNS to osobne pola

Adres resolvera mówi Androidowi, gdzie pytać. Sufiks wyszukiwania mówi, o co pytać, gdy podajesz tylko skrajną lewą etykietę. Oba mieszkają na tym samym obiekcie sieciowym i każde z nich może brakować samodzielnie.

Właśnie ta niezależność wyjaśnia, dlaczego pełna nazwa hosta działa. Nazwa w pełni kwalifikowana nie potrzebuje sufiksu, bo już jest łańcuchem, który trafia do serwera.

Android pokazuje ten podział poprzezLinkProperties. Lista serwerów DNS i lista wyszukiwania domen leżą na tym samym obiekcie, a druga jest zwykle pusta nawet wtedy, gdy pierwsza jest pełna. Sieć z resolverem, ale bez domeny, to sieć, w której sufiks nigdy nie został zastosowany — a nie serwer, który odrzucił krótką nazwę.

Przeczytaj efektywną sieć, zanim cokolwiek zmienisz

Wi-Fi, sieć komórkowa i interfejs VPN to trzy osobne sieci, a tunel staje się domyślny, gdy tylko się podniesie. Sufiks, który działał w Wi-Fi biurowym, nie jest więc automatycznie sufiksem obowiązującym, gdy tunel jest aktywny. Sprawdź sieć, na której aplikacja jest naprawdę wybrana, a nie tę, którą skonfigurowałeś w zeszłym tygodniu.

Powłoka terminala na urządzeniu jest tu słabym świadkiem, bo jejresolv.confodzwierciedla jeden widok resolvera, a nie widok każdej aplikacji.

Paski adresu przeglądarek dodają kolejną warstwę: gołe słowo może zostać potraktowane jako zapytanie wyszukiwania albo rozwiązane przezwłasną politykę przeglądarki dotyczącą szyfrowanego DNS, więc strona ładująca się w Chrome niczego nie dowodzi o zapytaniach systemowych. Testuj czymś, co korzysta z resolvera platformy i wypisuje, co wróciło. Potem uruchom formę krótką i pełną w tej samej sesji, w tej samej sieci, i zanotuj, która dała odpowiedź.

Jeśli budujesz aplikację VPN, dołącz sufiks w builderze

Gdy twoja aplikacja ustanawia interfejs przezVpnService,addSearchDomainto obsługiwane wejście do tego celu. Przyjmuje ciąg domeny, na przykładcorp.example, i nie jest alternatywnym sposobem przekazania adresu serwera.

Wywołanie wiąże sufiks z siecią, którą budujesz, więc nie ma żadnego globalnego ustawienia do przełączenia później. Jeśli aplikacja rozbiera interfejs i przy ponownym połączeniu buduje go od nowa, nowy builder musi znowu dodać sufiks, inaczej sieć zastępcza powstanie bez niego.

Tu właśnie wiele importów profili z komputera gubi to pole. Eksporter zapisuje domenę do własnego modelu, frontend Androida mapuje tylko opcje, które zna, a uzyskany interfejs wygląda poprawnie pod każdym innym względem. Profil, który działa na laptopie i zawodzi na telefonie, to zwykle luka w mapowaniu, a nie problem protokołu.

Jeśli tylko korzystasz z VPN, to nie twoja sprawa to ustawiać

Nie ma edycji po stronie klienta, która dodaje sufiks, ani globalnej właściwości, którą można zmienić, by go podrobić. Wartość dostarcza ten, kto posiada tunel: w profilu zarządzanego klienta, w jego mapowaniu na poszczególne platformy albo przez to, co wysyła serwer. Powiedz, na jakiej platformie jesteś i która nazwa zawodzi, bo frontendy desktopowy i mobilny różnią się dokładnie w tym polu.

Ponowny import profilu z komputera nadal niczego nie dowodzi o mapowaniu mobilnym.

Trzy warunki decydują, czy masz defekt, czy oczekiwane ograniczenie. Po pierwsze, czy organizacja w ogóle traktuje krótką etykietę jako obsługiwaną nazwę, czy to udogodnienie, które kiedykolwiek działało tylko w biurowym Wi-Fi? Po drugie, czy nieudane zapytanie pochodzi z przeglądarki, która może całkowicie ominąć resolver systemowy? Po trzecie, czy krótka nazwa ma być osiągalna przez tunel, czy tylko z LAN? Jeśli ostatnia odpowiedź brzmi tylko-LAN, dodanie sufiksu stworzyłoby nazwę, która rozwiązuje się poza biurem, a potem nie jest routowana.

Gdy sufiks jest obecny, a krótkie nazwy nadal zawodzą

Jeśli lista wyszukiwania domen już pokazujecorp.example, przestań winić sufiks. Sprawdź, czy resolver w ogóle zwraca odpowiedź dla rozszerzonej nazwy, bo sufiks zmienia tylko zadawane pytanie. Nigdy nie czyni serwera autorytatywnym dla strefy, której nie hostuje.

Potem sprawdź trasę. Adres, który się rozwiązuje, ale nie jest przenoszony przez tunel, zawodzi przy połączeniu, co wygląda identycznie jak nieudane zapytanie w przeglądarce, która po cichu się poddaje.

Certyfikaty zasługują na osobne wspomnienie. Walidacja HTTPS używa nazwy hosta, którą naprawdę wpisałeś, więc krótka nazwa, która poprawnie się rozszerza, i tak przedstawiafilesw uścisku dłoni. Certyfikat wydany dlafiles.corp.examplenie będzie dla niego ważny, a ten błąd jest prawidłowym zachowaniem, a nie objawem problemu z DNS, od którego zacząłeś.

Co zrobić dalej

Potwierdź podział, zanim czegokolwiek dotkniesz: pełna nazwa się rozwiązuje, krótka nie, ta sama aplikacja, ta sama sesja. Potem znajdź wybraną sieć i przeczytaj jej listę wyszukiwania domen obok listy resolverów. Która z tych dwóch jest pusta, mówi ci, kto musi działać — ty, jeśli aplikacja jest twoja; operator tunelu, jeśli nie.

Na koniec preferuj pełną nazwę usługi w zakładkach i konfiguracji klienta wszędzie, gdzie liczy się przenośność. Przetrwa zmianę sieci, nie zależy od mapowania, którego mobilny frontend może nie implementować, i odpowiada nazwie, dla której wydano certyfikat.