WireGuard nie wypycha DNS: obsługa prywatnej strefy BIND

Uścisk dłoni niesie klucze i dozwolone adresy IP, nigdy resolvera. Oto gotowa prywatna strefa BIND 9 oraz polityka klienta dla każdego łącza, która pozwala ją rozwiązać.

Podniosłeś WireGuard, tunel przepuszcza ruch, a wewnętrzna nazwa nadal się nie rozwiązuje. Następny ruch to zwykle szukanie ustawienia DNS w konfiguracji WireGuard, jakby peer mógł wypchnąć resolver tak, jak robią to inne VPN-y. Nie może. Uścisk dłoni niesie klucze, adresy interfejsu i dozwolone adresy IP, i nie ma pola na serwery DNS ani domeny wyszukiwania. Polityka resolvera żyje na kliencie i tam należy poprawka.

Tunel i resolver to odrębne umowy

WireGuard jest celowo mały. Przenosi pakiety dla adresów, które wymienisz, i uwierzytelnia peerów; wszystko powyżej tej warstwy to twój projekt. OpenVPN potrafi wypchnąć dhcp-option DNS, bo jego kanał kontrolny niesie konfigurację, i ta różnica potyka ludzi przechodzących między nimi.

Działający tunel nie mówi więc nic o rozwiązywaniu nazw. Klient może mieć idealną trasę do 10.90.0.1 i nadal wysyłać zapytania do publicznego resolvera, dlatego objaw wygląda jak “VPN zepsuł DNS”, choć DNS nigdy nie był kierowany na VPN.

Obsłuż strefę, nie stając się resolverem rekurencyjnym

Strona serwera to mała strefa autorytatywna, nie ogólny resolver. W tym przykładzie brama to 10.90.0.1, klienci to 10.90.0.0/24, a aplikacja, na której ci zależy, odpowiada na 10.60.0.20.

Scal te ustawienia z istniejącym blokiem options, zamiast tworzyć drugi:

options {
    listen-on { 127.0.0.1; 10.90.0.1; };
    listen-on-v6 { none; };
    allow-query { 127.0.0.1; 10.90.0.0/24; };
    allow-transfer { none; };
    recursion no;
};

Następnie zadeklaruj strefę i jej plik:

zone "corp.example" {
    type primary;
    file "/etc/bind/db.corp.example";
};
$TTL 300
@ IN SOA ns.corp.example. hostmaster.corp.example. ( 1 3600 600 604800 300 )
@      IN NS ns.corp.example.
ns     IN A  10.90.0.1
portal IN A  10.60.0.20

Sprawdź przed przeładowaniem, bo błąd składni przy przeładowaniu kładzie cały serwer dla każdej strefy, którą obsługuje:

named-checkconf
named-checkzone corp.example /etc/bind/db.corp.example

Otwórz UDP i TCP 53 tylko na interfejsie VPN. Publikowanie prywatnego autorytetu na interfejsie publicznym zaprasza zarówno zapytania, jak i wyliczanie, a allow-transfer powinno pozostać zamknięte, chyba że drugorzędny naprawdę go potrzebuje.

Skieruj klienta na nią, dla każdego łącza

Załóż, że połączenie należy do NetworkManagera, a resolverem jest systemd-resolved. Najpierw przeczytaj istniejącą politykę, zwłaszcza dowolną domenę trasowania głównego, bo wpis ~. przebije to, co zamierzasz dodać.

nmcli connection modify wg-office +ipv4.dns 10.90.0.1
nmcli connection modify wg-office +ipv4.dns-search '~corp.example'

Tylda jest tym ważnym znakiem. Oznacza domenę jako tylko-trasę: nazwy pod corp.example idą do serwera DNS tego łącza, a domena nie jest dopisywana jako sufiks wyszukiwania krótkich nazw. Bez niej wpisanie portal zaczyna rozwiązywać portal.corp.example, co jest wygodne dla ciebie i zaskakujące dla wszystkich innych. Trzymaj tyldę w cudzysłowach, bo bez cudzysłowów jest to rozwinięcie powłoki czekające, by wskazać twój katalog domowy.

Zastosuj zmianę przez menedżera, który posiada interfejs, a następnie połącz połączenie ponownie. Nie uruchamiaj drugiej instancji wg-quick dla tego samego interfejsu; dwóch właścicieli będzie się kłócić o trasy i jeden z nich wygra w najgorszym momencie.

Zweryfikuj ścieżkę przed nazwą

Odpytaj nazwę z klienta i potwierdź zarówno odpowiedź, jak i serwer, który ją wytworzył:

resolvectl query portal.corp.example

Jeśli to zwróci 10.60.0.20, umowa DNS jest spełniona. Jeśli upłynie limit czasu, sprawdź najpierw trasę do 10.90.0.1, potem regułę zapory, potem allow-query na serwerze. Błędy rozwiązywania nazw w tej konfiguracji są prawie zawsze kwestią osiągalności lub ACL, a nie pliku strefy. Pracuj od klienta na zewnątrz, bo serwer nie może ci powiedzieć, dlaczego zapytanie nigdy nie dotarło.

Pamiętaj, że aplikacja nadal potrzebuje własnej trasy i własnego uprawnienia usługi. Rozwiązana nazwa wskazująca na nieosiągalny adres to inna awaria w tym samym ubraniu.

Co wciąż nie jest automatyczne

Aplikacje z własną logiką resolvera całkowicie ignorują resolver systemowy, i żadna ilość nmcli tego nie zmieni. Wdrożenia walidujące DNSSEC potrzebują wyraźnego projektu kotwicy zaufania dla strefy prywatnej; odpowiedzią nie jest ogólne polecenie wyłączenia walidacji. Testuj tym samym oprogramowaniem klienckim, którego używają twoi użytkownicy, a nie narzędziem, które przypadkiem korzysta z resolvera systemowego. Różnica między tymi dwoma to cały raport o błędzie.

Floty mogą automatyzować tę politykę klienta przez swój system provisioningu, ale polityka pozostaje osobnym obiektem z właścicielem. Dokumentacja BIND 9 obejmuje użyte powyżej mechanizmy nasłuchu i obsługi zapytań, i to właściwe miejsce, by potwierdzić zachowanie dla zainstalowanej wersji.

Następny krok: dodaj podbicie numeru seryjnego strefy i polecenia sprawdzające do swojej procedury zmian, aby edycja rekordu nie mogła trafić na produkcję bez sprawdzenia.

Powiązane artykuły