Ge din hemma-VPN egna DNS-poster för nas.home.arpa

När tunneln är uppe är det sista steget oftast ett namn som fungerar i stället för en adress du klistrar in i ett bokmärke. En dnsmasq-värdpost plus en resolveradress som klienten kan nå gör det med två filer och utan multicast. Beslutet som verkligen kräver eftertanke är smalare: skickar klienten all DNS via hemresolvern, eller bara namnen under home.arpa? Allt nedan förutsätter en godkänd WireGuard-konfiguration med en Linux-klient och en laboratorieresolver som hemadministratören redan hanterar.

Tre sätt att ge klienten en resolver

För en bärbar dator som då och då ansluter till tunneln är split-DNS det bättre standardvalet: det håller vanliga internetnamn kvar hos resolvern som maskinen redan litar på. För en maskin som finns för att nå hemmetjänsterna är det enklare att trycka ut resolvern, och kostnaden för omfattningen spelar ingen roll.

Publicera posten hos resolvern som äger zonen

Håll rollerna åtskilda innan du skriver konfiguration: VPN-klientens adress, resolvern och tjänsten är tre olika värdar med tre olika uppgifter. I det här labbet är de 10.77.0.2 för klienten, 192.168.50.53 för dnsmasq och 192.168.50.20 för NAS:en, medan tunneln routar hemma-LAN:et.

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

Raden host-record ger adressen och raden local= håller okända home.arpa-frågor kvar i den här resolvern i stället för att skicka dem vidare uppåt. Läs din befintliga konfiguration först och stäm av allt som redan definierar en server, ett gränssnitt eller samma lokala domän; att stapla ett fragment ovanpå ett motstridigt ger en resolver som laddas glatt och svarar fel. dnsmasq-handboken definierar båda direktiven och lyssningsstyrningen.

Verifiera sedan tjänsten som körs, inte filen. Ett konfigurationstest plus en omstart är minimum, och det faktiska svaret är det en fråga returnerar.

Routa resolvern, inte bara webbsidan

WireGuards AllowedIPs avgör vilka destinationer som kommer in i tunneln. Om resolveradressen faller utanför den lämnar frågan den vanliga rutten och når aldrig dnsmasq, även om NAS:en själv är nåbar. Ta med resolverns adress, eller LAN-prefixet som innehåller den, och kontrollera gatewayens vidarebefordringspolicy på andra sidan.

Tillåt UDP och TCP på port 53 från det auktoriserade tunnelområdet, med en returväg tillbaka till klientens tunneladress. Vidarebefordra inte port 53 från WAN för att underlätta testning: en öppen rekursiv resolver på en hemanslutning hittas inom timmar. Att binda till ett gränssnitt är inte i sig en åtkomstpolicy.

Kontrollera svaret före applikationen

Fråga resolvern direkt först, sedan systemet, sedan applikationen. Varje steg isolerar en länk i kedjan, och skillnaden mellan dem är diagnosen.

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-frågan är värd att köra eftersom ett avkortat UDP-svar tvingar fram ett nytt försök, och en policy som släpper TCP 53 ger fel som verkar intermittenta. Steget getent visar vad maskinens resolverkonfiguration faktiskt gör, vilket inte alltid är det du tryckte ut.

Bestäm vad som händer när tunneln är nere

Om klientens allmänna DNS pekar på 192.168.50.53 slutar all namnuppslagning att fungera när tunneln inte är uppe. Det är acceptabelt på en maskin som bara är användbar med tunneln, och oacceptabelt på en bärbar dator som också använder kafé-Wi-Fi. Split-DNS kringgår frågan helt, eftersom bara home.arpa-slagningar beror på hemresolvern.

Kom ihåg vad namnet är: home.arpa är reserverat för bostadsnät och är inte globalt unikt, så ett annat nät kan lagligt använda samma namn. Det är en lokal bekvämlighet, inte en pålitlig identifierare. Håll posten uppdaterad när tjänsten flyttar, och ta bort resolverpolicyn när labbet avvecklas i stället för att lämna en bärbar dator som pekar på en adress den bara kan nå via en tunnel som inte längre finns.