Dejte své domácí VPN vlastní DNS záznamy pro nas.home.arpa

Jakmile je tunel nahoře, posledním krokem je obvykle jméno, které funguje, místo adresy, kterou vkládáte do záložky. Záznam hostitele v dnsmasq plus adresa resolveru, na kterou se klient dostane, to zvládnou se dvěma soubory a bez multicastu. Rozhodnutí, které opravdu stojí za přemýšlení, je užší: posílá klient veškerý DNS přes domácí resolver, nebo jen jména pod home.arpa? Vše níže předpokládá schválené zapojení WireGuardu s linuxovým klientem a laboratorním resolverem, který domácí správce už spravuje.

Tři způsoby, jak klientovi předat resolver

Pro notebook, který do tunelu občas vstoupí, je split-DNS lepší výchozí volbou: udrží běžná internetová jména na resolveru, kterému stroj už věří. Pro stroj, který existuje kvůli dosažení domácích služeb, je doručení resolveru jednodušší a cena rozsahu nehraje roli.

Zveřejněte záznam na resolveru, který vlastní zónu

Před psaním konfigurace držte role oddělené: adresa klienta VPN, resolver a služba jsou tři různí hostitelé se třemi různými úkoly. V této laboratoři to je 10.77.0.2 pro klienta, 192.168.50.53 pro dnsmasq a 192.168.50.20 pro NAS, přičemž tunel směruje domácí 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

Řádek host-record dodá adresu a řádek local= udrží neznámé dotazy na home.arpa uvnitř tohoto resolveru, místo aby je přeposlal výš. Nejprve si přečtěte stávající konfiguraci a srovnejte vše, co už definuje server, rozhraní nebo stejnou lokální doménu; navršení fragmentu na konfliktní dává resolver, který se vesele načte a odpovídá špatně. Manuál dnsmasq definuje obě direktivy i ovládání naslouchání.

Pak ověřte běžící službu, ne soubor. Test konfigurace plus restart je minimum a skutečná odpověď je to, co dotaz vrátí.

Směrujte resolver, ne jen webovou stránku

AllowedIPs WireGuardu určuje, které cíle vstoupí do tunelu. Pokud adresa resolveru leží mimo, dotaz odejde běžnou cestou a k dnsmasq se nikdy nedostane, i když je samotný NAS dostupný. Zahrňte adresu resolveru nebo prefix LAN, který ji obsahuje, a ověřte politiku přeposílání brány na druhé straně.

Povolte UDP i TCP na portu 53 z autorizovaného rozsahu tunelu, se zpáteční cestou k adrese tunelu klienta. Nepřeposílejte port 53 z WAN, abyste si usnadnili testování: otevřený rekurzivní resolver na domácím připojení se najde během hodin. Vázání na rozhraní samo o sobě není přístupová politika.

Ověřte odpověď dřív než aplikaci

Nejdřív se zeptejte resolveru přímo, pak systému, pak aplikace. Každý krok izoluje jeden článek řetězu a rozdíl mezi nimi je diagnóza.

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'

TCP dotaz stojí za spuštění, protože zkrácená UDP odpověď vynutí opakování a politika, která zahazuje TCP 53, vytváří poruchy, jež vypadají občasné. Krok getent ukáže, co konfigurace resolveru na stroji skutečně dělá, což není vždy to, co jste poslali.

Rozhodněte, co se stane, když tunel spadne

Pokud obecný DNS klienta míří na 192.168.50.53, veškeré překládání jmen přestane fungovat, když tunel není nahoře. To je přijatelné na stroji, který je užitečný jen s tunelem, a nepřijatelné na notebooku, který používá i Wi-Fi v kavárně. Split-DNS otázku úplně obejde, protože na domácím resolveru závisí jen dotazy na home.arpa.

Pamatujte, co to jméno je: home.arpa je vyhrazeno pro rezidenční sítě a není globálně jedinečné, takže jiná síť může stejné jméno legitimně použít. Je to místní pohodlí, ne důvěryhodný identifikátor. Udržujte záznam aktuální, když se služba přesune, a při vyřazení laboratoře politiku resolveru odstraňte, místo abyste nechali notebook ukazovat na adresu, na kterou se dostane jen tunelem, který už neexistuje.