Daj swojej domowej VPN własne rekordy DNS dla nas.home.arpa

Gdy tunel jest podniesiony, ostatnim krokiem jest zwykle nazwa, która działa, zamiast adresu wklejanego do zakładki. Rekord hosta w dnsmasq plus adres resolvera, do którego klient może dotrzeć, robią to dwoma plikami i bez multicastu. Decyzja, która naprawdę wymaga namysłu, jest węższa: czy klient wysyła cały DNS przez domowy resolver, czy tylko nazwy pod home.arpa? Wszystko poniżej zakłada zatwierdzoną konfigurację WireGuard z klientem Linux i laboratoryjnym resolverem, którym domowy administrator już zarządza.

Trzy sposoby przekazania klientowi resolvera

Dla laptopa, który od czasu do czasu dołącza do tunelu, split-DNS jest lepszym ustawieniem domyślnym: trzyma zwykłe nazwy internetowe na resolverze, któremu maszyna już ufa. Dla maszyny, która istnieje po to, by docierać do domowych usług, wypchnięcie resolvera jest prostsze, a koszt zakresu nie ma znaczenia.

Opublikuj rekord na resolverze, który włada strefą

Przed pisaniem konfiguracji rozdziel role: adres klienta VPN, resolver i usługa to trzy różne hosty z trzema różnymi zadaniami. W tym laboratorium są to 10.77.0.2 dla klienta, 192.168.50.53 dla dnsmasq i 192.168.50.20 dla NAS, a tunel trasuje domowy LAN.

listen-address=127.0.0.1,192.168.50.53
bind-interfaces
local=/home.arpa/
host-record=nas.home.arpa,192.168.50.20

Wiersz host-record dostarcza adres, a wiersz local= trzyma nieznane pytania o home.arpa wewnątrz tego resolvera, zamiast przekazywać je wyżej. Najpierw przeczytaj istniejącą konfigurację i pogódź wszystko, co już definiuje serwer, interfejs lub tę samą domenę lokalną; dołożenie fragmentu na sprzeczny daje resolver, który wesoło się ładuje i odpowiada błędnie. Podręcznik dnsmasq definiuje obie dyrektywy i sterowanie nasłuchem.

Następnie sprawdź działającą usługę, a nie plik. Test konfiguracji plus restart to minimum, a rzeczywistą odpowiedzią jest to, co zwraca zapytanie.

Trasuj resolver, nie tylko stronę internetową

AllowedIPs WireGuarda decyduje, które cele wchodzą do tunelu. Jeśli adres resolvera wypada poza to, zapytanie wychodzi zwykłą trasą i nigdy nie dociera do dnsmasq, choć sam NAS jest osiągalny. Uwzględnij adres resolvera lub prefiks LAN, który go zawiera, i sprawdź politykę przekazywania bramy po drugiej stronie.

Zezwól na UDP i TCP na porcie 53 z autoryzowanego zakresu tunelu, z drogą powrotną do adresu tunelu klienta. Nie przekazuj portu 53 z WAN, aby ułatwić testy: otwarty rekurencyjny resolver na łączu domowym znajduje się w ciągu godzin. Przywiązanie do interfejsu samo w sobie nie jest polityką dostępu.

Sprawdź odpowiedź przed aplikacją

Najpierw zapytaj resolver bezpośrednio, potem system, potem aplikację. Każdy krok izoluje jedno ogniwo łańcucha, a różnica między nimi to diagnoza.

dig @192.168.50.53 nas.home.arpa. A
dig +tcp @192.168.50.53 nas.home.arpa. A
getent ahostsv4 nas.home.arpa
curl -sS --max-time 5 http://nas.home.arpa/ -o /dev/null -w '%{http_code}\n'

Warto uruchomić zapytanie TCP, bo obcięta odpowiedź UDP wymusza ponowną próbę, a polityka, która odrzuca TCP 53, daje awarie wyglądające na okresowe. Krok getent pokazuje, co naprawdę robi konfiguracja resolvera maszyny, co nie zawsze jest tym, co wypchnąłeś.

Zdecyduj, co się dzieje, gdy tunel jest wyłączony

Jeśli ogólny DNS klienta wskazuje 192.168.50.53, wszelkie rozwiązywanie nazw przestaje działać, gdy tunel nie jest podniesiony. Jest to do przyjęcia na maszynie, która jest użyteczna tylko z tunelem, i nie do przyjęcia na laptopie, który korzysta też z Wi-Fi w kawiarni. Split-DNS całkowicie unika tego pytania, bo tylko wyszukiwania home.arpa zależą od domowego resolvera.

Pamiętaj, czym jest ta nazwa: home.arpa jest zarezerwowana dla sieci mieszkalnych i nie jest globalnie unikalna, więc inna sieć może legalnie użyć tej samej nazwy. To lokalna wygoda, a nie wiarygodny identyfikator. Utrzymuj rekord aktualny, gdy usługa się przenosi, i usuń politykę resolvera, gdy laboratorium jest wycofywane, zamiast zostawiać laptop wskazujący adres, do którego dotrze tylko przez tunel, którego już nie ma.