WireGuard DNS na iPhone: domena to tylko sufiks wyszukiwania

Piszesz jeden wiersz z adresem resolvera i domeną firmy, oczekując, że tylko nazwy w tej domenie będą korzystać z resolvera tunelu. Na kliencie Apple wszystkie nazwy trafiają teraz tam, a krótkie nazwy w domenie również są rozwiązywane. Wiersz robi dwie osobne rzeczy, a tylko jedna z nich dotyczy tego, które zapytania obsługuje tunel. Druga to wygoda pisania, którą życzeniowe odczytanie awansowało na politykę.

Na co rozkładany jest wiersz DNS

Klient czyta wpis jako listę i klasyfikuje każdy element według kształtu. Wszystko, co wygląda jak adres, staje się serwerem DNS; wszystko, co wygląda jak domena, staje się sufiksem wyszukiwania. Oba trafiają do ustawień tunelu, ale do różnych pól. Przykładowy wiersz dla tunelu, który przenosi prywatny resolver i jedną domenę wewnętrzną, wygląda tak.

DNS = 10.24.8.53, lab.internal.example

Adres dostarcza resolver. Domena dostarcza sufiks, który pozwala klientowi wpisać krótką nazwę, a systemowi dopisać resztę przed zapytaniem. Żaden z nich nie mówi nic o ograniczeniu resolvera do tej domeny, a to właśnie ta część, której ludzie oczekują i nie dostają. Tylko jedno pole na platformie może wyrazić to ograniczenie, i nie jest to to pole.

Dwa pola Apple, dwa różne zadania

Apple ujawnia tę różnicę w swoim obiekcie ustawień DNS. Lista domen wyszukiwania jest udokumentowana jako lista używana do kwalifikowania nazw hostów z jedną etykietą: wpisz gołą nazwę hosta, a system może po kolei dopisać każdy sufiks. To reguła uzupełniania, a nie reguła routingu. Nic na tej liście nie decyduje, który serwer jest pytany.

Lista domen dopasowania to inna właściwość. Decyduje, które przestrzenie nazw używają tego zestawu ustawień DNS, a pusty wpis oznacza domenę domyślną, a nie jeden konkretny sufiks. generator ustawień tunelu pakietów w kliencie Apple podąża za tym modelem. Umieszcza przeanalizowane sufiksy wyszukiwania na liście wyszukiwania, a gdy są serwery, ustawia listę dopasowania na pusty ciąg. Wynikiem jest resolver tunelu, który odpowiada na wszystko, co system mu wysyła, plus sufiks, który pomaga przy krótkich nazwach.

Domena w tym wierszu nie jest więc selektorem przestrzeni nazw. Dodanie kolejnej nie zawęża zapytań używanych przez tunel, a usunięcie jej też ich nie rozszerza. Zmienia się tylko to, ile krótkich nazw zostanie uzupełnionych.

Dlaczego każda nazwa i tak dociera do resolvera tunelu

Przy pustym wpisie dopasowania tunel jest kandydatem na resolver zwykłych nazw, nie tylko domeny firmy. W konfiguracji pełnego tunelu zwykle ma to niewielkie znaczenie, ponieważ cały ruch i tak jest w tunelu. W tunelu dzielonym ma to duże znaczenie. Nazwy publiczne mogą teraz być rozwiązywane przez resolver, który ma tylko strefę prywatną, a awaria wygląda jak zepsuty VPN, choć w rzeczywistości to resolver odpowiadający tylko na część przestrzeni nazw. Tunel jest w porządku, zapytania wychodzą, a odpowiedzi wracają puste.

Dostępne są dwie naprawy i są to różne decyzje. Uczyń resolver tunelu pełnym resolverem, który przekazuje nazwy publiczne zatwierdzoną ścieżką, albo przestań wysyłać nazwy publiczne tam, zmieniając konfigurację klienta, a nie listę domen. Pierwsza trzyma każde zapytanie w tunelu i ufa nadrzędnemu. Druga trzyma część zapytań lokalnie i akceptuje, że nazwy prywatne mogą przestać się rozwiązywać, gdy tunel jest wyłączony.

Czego naprawdę wymagałby dzielony DNS

Polityka resolvera ograniczona do przestrzeni nazw wymaga klienta, który pozwala ją wyrazić: dopasuj domeny na platformach Apple albo równoważne ustawienie w produkcie, którego używasz. Pole konfiguracji przyjmujące tylko serwery i sufiksy nie może jej wyrazić, niezależnie od interpunkcji. Profil może nieść politykę, ponieważ opisuje konfigurację zarządzaną, a nie podpowiedź w momencie połączenia. Może nazwać domenę, serwery i to, co powinno się stać, gdy ta domena jest nieosiągalna. To jest różnica między ustawieniem a umową.

Na zarządzanych urządzeniach Apple jest to zwykle dostarczane przez profil konfiguracji, który przenosi ustawienia DNS specyficzne dla domeny. To inny mechanizm niż plik konfiguracji WireGuard, a oba mogą współistnieć tylko wtedy, gdy klient respektuje profil. Sprawdź, jak twój klient naprawdę nazywa to pole, zanim założysz, że oba produkty zachowują się tak samo. Skrypt wg-quick na Macu i aplikacja WireGuard na iPhonie czytają podobne wiersze i instalują je przez różne warstwy.

Czytaj zainstalowane ustawienia, nie konfigurację

Na Macu możesz sprawdzić, na czym system skończył, co daje więcej informacji niż ponowne czytanie pliku, który napisałeś. Lista resolverów pokazuje, które serwery są skonfigurowane dla których domen, a zapytania z zakresem pokazują, który wygrał. Klient, który psuje wiersz, pokazuje to tutaj, a nie w pliku, który napisałeś. Na iOS nie ma równoważnej linii poleceń, więc dowodem jest tam wynik: nazwa prywatna rozwiązywana przez tunel i nazwa publiczna, której odpowiedź ujawnia, który resolver odpowiedział.

scutil --dns | grep -A3 resolver
networksetup -getdnsservers Wi-Fi

Te dwa polecenia drukują bieżącą konfigurację resolvera i serwery DNS aktywnej usługi. Jeśli resolver tunelu pojawia się jako resolver domyślny bez ograniczenia domeny, konfiguracja robi dokładnie to, o co poprosił klient. Napraw to, zmieniając mechanizm, a nie dodając drugi sufiks i licząc na to, że zachowanie się zmieni.