Podzielony DNS przez OpenVPN: co musi robić domena routingu w każdym systemie operacyjnym

Każde zapytanie podzielonego DNS zaczyna się od tego samego zdania: nazwy firmy trafiają do DNS firmy, a wszystko inne działa dalej. Zamiana tego zdania w konfigurację oznacza odpowiedź na trzy pytania dla każdego systemu operacyjnego, a odpowiedzi używają w każdym z nich innych mechanizmów. Profile, które działają na laptopie z Linuksem, często zawodzą w Windows z powodów, które nie mają nic wspólnego z tunelem. Różnica to zwykle ustawienie resolvera wzięte za trasę.

Najpierw nazwij politykę, potem wybierz prymityw platformy, który ją wyraża.

Trzy ustawienia łatwe do pomylenia

Sufiks wyszukiwania rozwija krótką nazwę: wpisanie files staje się files.corp.example, gdy resolver próbuje sufiksów po kolei. Domena routingu wybiera, który resolver odpowiada na zapytania w obrębie przestrzeni nazw. Trasa IP tylko czyni wybrany resolver osiągalnym. Te trzy żyją w różnych warstwach, a zamiana jednego na drugi daje konfigurację, która wygląda dobrze i niczego nie rozwiązuje.

Zamieszanie ma swoją cenę: dodanie sufiksu wyszukiwania wysyła każdą krótką nazwę do resolvera roboczego, w tym nazwy należące gdzie indziej. Wybór domeny routingu zostawia niepowiązane zapytania na lokalnym resolverze i nadal wysyła *.corp.example przez tunel.

Linux: domena tylko-trasowa, nie sufiks wyszukiwania

W systemd-resolved domena z tyldą na początku jest domeną tylko-trasową, co oznacza, że zapytania w tej przestrzeni nazw idą do powiązanego resolvera, nie stając się też sufiksem wyszukiwania. resolvectl domain tun0 '~corp.example' ustawia to, a resolvectl dns tun0 10.8.0.1 nazywa serwer. Oba ustawienia należą do interfejsu, więc znikają razem z nim. Tylda to część, którą ludzie pomijają, a bez niej krótkie nazwy zaczynają się rozwiązywać przez resolver roboczy.

Nie instaluj też tej samej domeny jako globalnego sufiksu wyszukiwania. Oba ustawienia nie są zbędne; jedno kieruje, a drugie przepisuje to, co wpisałeś.

Windows potrzebuje polityki przestrzeni nazw, nie sufiksu

Windows trzyma politykę podzielonego DNS w Name Resolution Policy Table, a nie w sufiksie DNS karty sieciowej. Reguła mapuje przestrzeń nazw na konkretne serwery: Add-DnsClientNrptRule -Namespace .corp.example -NameServers 10.8.0.1. Ustawienie samego sufiksu zmienia wygląd krótkich nazw; nie kieruje zapytania do innego serwera.

Sprawdź obowiązującą politykę za pomocą Get-DnsClientNrptPolicy po połączeniu, bo reguła z wcześniejszego połączenia może przetrwać tunel. Usuwaj reguły po nazwie, gdy tunel pada, i utrzymuj stabilną nazwę wyświetlaną, aby czyszczenie trafiało we właściwy wpis.

Jeden właściciel resolvera na platformę

Menedżer pulpitu, skrypt up OpenVPN i lokalny demon resolvera mogą próbować zapisać tę samą konfigurację. Gdy się nie zgadzają, wygrywa ostatni piszący, a wynik zależy od kolejności demontażu. Wybierz jeden komponent, który ma właścicielstwo stanu resolvera, pozwól innym raportować zamiast pisać, i przetestuj ponowne połączenie: polityka powinna je przetrwać bez duplikowania reguł. Przetestuj też rozłączenie, bo to właśnie pozostały stan sprawia, że następne połączenie zachowuje się inaczej.

Aplikacje, które przynoszą własny szyfrowany resolver, całkowicie ignorują politykę systemu operacyjnego. To właściwość aplikacji, a nie defekt tunelu.

Sprawdź wynik, nie tekst profilu

Rozwiąż jedną nazwę, która powinna przejść przez tunel, i jedną, która nie powinna, na każdej platformie, i potwierdź, który serwer odpowiedział. resolvectl query host.corp.example i Resolve-DnsName host.corp.example oba raportują serwer, który odpowiedział. Powtórz po ponownym połączeniu. Następnie potwierdź, że resolver tunelu jest osiągalny pod adresem, który popycha profil, bo poprawna polityka wskazująca nieosiągalny serwer zawodzi tak samo jak brak polityki.

Zapisz zamierzone zachowanie w notatkach profilu: który sufiks kieruje, który serwer na niego odpowiada i co dzieje się z resztą. Następna obsługiwana platforma będzie potrzebować tego zdania bardziej niż pliku konfiguracji.