DNS VPN na iPhonie: kto jest właścicielem ustawienia, decyduje, gdzie ono obowiązuje

Wpisz adres prywatnego resolvera w ustawieniach Wi-Fi iPhone'a, a będzie działał, dopóki telefon nie opuści tej sieci, czyli dokładnie wtedy, gdy VPN powinien przejąć kontrolę. To pierwsza pułapka mobilnego DNS: miejsce, w którym wpisałeś ustawienie, definiuje jego zakres, a zakres jest węższy, niż większość zakłada. Zanim cokolwiek zmienisz, odpowiedz na trzy pytania o wdrożenie, ponieważ odpowiedzi decydują, której kontrolki powinieneś dotknąć. Traktuj tę kolejność jako przegląd projektu, a nie polowanie na ustawienia.

Trzy pytania, zanim wpiszesz adres resolvera

Po pierwsze, które nazwy naprawdę wymagają specjalnego traktowania? Strefa prywatna, taka jak corp.example, jest przestrzenią nazw, a nie jednym hostem, i odpowiedzią powinna być domena, a nie jeden rekord. Po drugie, który resolver jest dla niej autorytatywny i kto jest właścicielem tej usługi? Po trzecie, która ścieżka czyni ten resolver osiągalnym z telefonu: tunel, trasowana sieć Wi-Fi czy coś zupełnie innego?

Jeśli którykolwiek z tych trzech nie ma właściciela, zatrzymaj się. Zmiana DNS wykonana bez przestrzeni nazw, autorytatywnego źródła i osiągalnej ścieżki to zgadywanie, które w sieci komórkowej zawiedzie inaczej niż w biurze.

Wpis DNS dla Wi-Fi należy do tej sieci Wi-Fi

Ręczna konfiguracja DNS w iOS jest przechowywana dla każdej sieci osobno. Działa, dopóki telefon jest połączony z tym SSID, i przestaje działać, gdy nie jest, co oznacza, że nie może zarządzać ruchem komórkowym ani opisywać, co robi klient VPN. Edytowanie jej, aby naprawić aplikację, która zawodzi w sieci komórkowej, jest zmianą ustawienia, którego zawodząca ścieżka nigdy nie czyta.

To nie czyni DNS dla poszczególnych sieci bezużytecznym. Dla domowego laboratorium lub jednego biurowego SSID to najprostszy sposób dotarcia do wewnętrznego resolvera i jest uczciwy co do swojej granicy.

Mechanizm DNS VPN zależy od protokołu i klienta

Dostawca tunelu pakietowego w iOS może skonfigurować DNS przez API ustawień DNS Apple, które udostępnia adresy resolvera i dopasowanie domen tunelowi posiadającemu połączenie. Natywna konfiguracja IKEv2 może otrzymać DNS przez ładunek konfiguracji IKE, gdy brama go wypycha, ale to, czy dany klient stosuje to, co otrzymuje, jest szczegółem implementacji, który musisz zweryfikować. Klient oparty na aplikacji może całkowicie zaimplementować własną ścieżkę rozwiązywania.

To różne punkty integracji i wynik jednego z nich nie staje się regułą dla wszystkich iPhone'ów. Wspieranym mechanizmem jest to, co profil lub dostawca dokumentuje dla używanego protokołu.

Decyduj według własności, nie według wygody

Jeśli urządzenie jest zarządzane, właściciel profilu powinien dostarczyć ustawienie DNS wraz z konfiguracją VPN, aby ponowna rejestracja je przywróciła, bez konieczności pamiętania czegokolwiek przez użytkownika. Jeśli tunel należy do aplikacji dostawcy, jej ekran ustawień jest miejscem, w którym należy patrzeć, a jej dokumentacja jest autorytetem w tym, co może rozdzielić. Jeśli telefon jest prywatny, a potrzeba dotyczy jednej wewnętrznej nazwy w jednej sieci, ustawienie dla sieci jest proporcjonalne.

Reguła decyzyjna jest krótka: ustawienie należy do miejsca, w którym provisionowane jest połączenie. Wszędzie indziej jest lokalnym wyjątkiem, który wymaże następna zmiana sieci.

Weryfikuj na ścieżkach, których telefon naprawdę używa

Przetestuj świeże żądanie z aplikacji, która potrzebuje prywatnej nazwy, w biurowym Wi-Fi, w sieci komórkowej i podczas przejścia między nimi. Aplikacja z własną integracją resolvera może obrać inną ścieżkę niż system, więc testuj rzeczywistą aplikację, a nie kartę przeglądarki, która działa przypadkowo.

Gdy prywatna nazwa zawodzi, zachowaj dokładny błąd i stan profilu. Publiczny resolver, który odpowiada, że nazwa nie istnieje, daje poprawną odpowiedź na niewłaściwe pytanie, a dodanie go obok firmowego resolvera nie jest projektem przestrzeni nazw.

Na koniec przechowuj zweryfikowaną politykę razem ze źródłem provisioningu. Następne ponowne połączenie lub rejestracja powinny przywrócić tę samą usługę nazw, ponieważ profil tak powiedział, a nie dlatego, że ktoś pamiętał zmianę wykonaną na jednym hotspocie dwa lata temu.