Gi heime-VPN-en din eigne DNS-poster for nas.home.arpa
Publiser eitt namn frå dnsmasq, rut resolveren gjennom WireGuard, og vel deretter mellom å dytte DNS til heile klienten og split-DNS berre for home.arpa.
Når tunnelen er oppe, er det siste steget vanlegvis eit namn som verkar i staden for ei adresse du limer inn i eit bokmerke. Ein dnsmasq-vertspost pluss ei resolveradresse klienten kan nå gjer det med to filer og utan multicast. Avgjerda som verkeleg krev ettertanke er smalare: sender klienten all DNS gjennom heimeresolveren, eller berre namna under home.arpa? Alt nedanfor føreset eit godkjent WireGuard-oppsett med ein Linux-klient og ein laboratorieresolver som heimeadministratoren allereie administrerer.
Tre måtar å gi klienten ein resolver
| Approach | Scope | Cost |
|---|---|---|
DNS = in the wg-quick interface | the client's general DNS while the tunnel is up | every name in the house now depends on the tunnel |
Platform split-DNS for home.arpa | only that suffix | more configuration per client platform |
Manual dig @resolver | one query at a time | fine for testing, useless for applications |
For ein berbar datamaskin som av og til koplar seg til tunnelen, er split-DNS det betre standardvalet: det held vanlege internettnamn på resolveren maskinen allereie stolar på. For ein maskin som finst for å nå heimetenester, er det enklare å dytte resolveren, og kostnaden ved omfanget spelar inga rolle.
Publiser posten på resolveren som eig sona
Hald rollene frå kvarandre før du skriv konfigurasjon: VPN-klientadressa, resolveren og tenesta er tre ulike vertar med tre ulike jobbar. I dette laboratoriet er dei 10.77.0.2 for klienten, 192.168.50.53 for dnsmasq og 192.168.50.20 for NAS-en, medan tunnelen rutar heime-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
Lina host-record gir adressa, og lina local= held ukjende home.arpa-spørsmål inne i denne resolveren i staden for å videresende dei oppover. Les den eksisterande konfigurasjonen din først og samsvar alt som allereie definerer ein server, eit grensesnitt eller same lokale domene; å stable eit fragment oppå eit motstridande gir ein resolver som lastar gladeleg og svarar feil. dnsmasq-handboka definerer begge direktiva og lyttestyringa.
Stadfest deretter tenesta som køyrer, ikkje fila. Ein konfigurasjonstest pluss ein omstart er minimum, og det effektive svaret er det ei spørjing returnerer.
Rut resolveren, ikkje berre nettsida
WireGuard sin AllowedIPs avgjer kva destinasjonar som kjem inn i tunnelen. Viss resolveradressa fell utanfor han, forlèt spørjinga den normale ruta og når aldri dnsmasq, sjølv om NAS-en sjølv er tilgjengeleg. Ta med adressa til resolveren, eller LAN-prefikset som inneheld henne, og kontroller videresendingspolicyen til gatewayen på den andre sida.
Tillat UDP og TCP på port 53 frå det autoriserte tunnelområdet, med ein returveg tilbake til tunneladressa til klienten. Ikkje videresend port 53 frå WAN for å gjere testing enklare: ein open rekursiv resolver på ei heimekopling blir funnen innan timar. Å binde til eit grensesnitt er ikkje ein tilgangspolicy i seg sjølv.
Kontroller svaret før bruksprogrammet
Spør resolveren først direkte, deretter systemet, deretter bruksprogrammet. Kvart steg isolerer ein lenkje i kjeda, og skilnaden mellom dei er 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-spørjinga er verd å køyre fordi eit avkorta UDP-svar tvingar fram eit nytt forsøk, og ein policy som droppar TCP 53 gir feil som verkar periodiske. Steget getent viser kva resolverkonfigurasjonen til maskinen faktisk gjer, noko som ikkje alltid er det du dytta ut.
Avgjer kva som skjer når tunnelen er nede
Viss den generelle DNS-en til klienten peikar på 192.168.50.53, sluttar all namneoppløysing å verke når tunnelen ikkje er oppe. Det er akseptabelt på ein maskin som berre er nyttig med tunnelen, og uakseptabelt på ein berbar datamaskin som også brukar Wi-Fi på ein kafé. Split-DNS unngår spørsmålet heilt, fordi berre home.arpa-oppslag avheng av heimeresolveren.
Hugs kva namnet er: home.arpa er reservert for bustadnettverk og er ikkje globalt unikt, så eit anna nettverk kan med rette bruke same namn. Det er ei lokal bekvemmelegheit, ikkje ein påliteleg identifikator. Hald posten oppdatert når tenesta flyttar, og fjern resolverpolicyen når laboratoriet blir avvikla, i staden for å etterlate ein berbar datamaskin som peikar på ei adresse han berre kan nå gjennom ein tunnel som ikkje finst lenger.