Giv din hjemme-VPN sine egne DNS-poster til nas.home.arpa
Udgiv ét navn fra dnsmasq, send resolveren gennem WireGuard, og vælg derefter mellem at skubbe DNS til hele klienten og split-DNS kun for home.arpa.
Når tunnelen er oppe, er det sidste skridt normalt et navn, der virker, i stedet for en adresse, du indsætter i et bogmærke. En dnsmasq-værtspost plus en resolveradresse, som klienten kan nå, klarer det med to filer og uden multicast. Den beslutning, der virkelig kræver omtanke, er snævrere: sender klienten al DNS gennem hjemmeresolveren, eller kun navnene under home.arpa? Alt nedenfor forudsætter et godkendt WireGuard-opsætning med en Linux-klient og en laboratorieresolver, som hjemmeadministratoren allerede administrerer.
Tre måder at give klienten en 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 |
Til en bærbar computer, der af og til tilslutter sig tunnelen, er split-DNS det bedre standardvalg: det holder almindelige internetnavne på den resolver, maskinen allerede stoler på. Til en maskine, der findes for at nå hjemmets tjenester, er det enklere at skubbe resolveren, og omkostningen ved omfanget betyder ikke noget.
Udgiv posten på den resolver, der ejer zonen
Hold rollerne adskilt, før du skriver konfiguration: VPN-klientadressen, resolveren og tjenesten er tre forskellige værter med tre forskellige opgaver. I dette laboratorium er de 10.77.0.2 til klienten, 192.168.50.53 til dnsmasq og 192.168.50.20 til NAS, mens tunnelen router hjemmets 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
Linjen host-record leverer adressen, og linjen local= holder ukendte home.arpa-spørgsmål inde i denne resolver i stedet for at videresende dem opad. Læs din eksisterende konfiguration først, og afstem alt, der allerede definerer en server, en grænseflade eller samme lokale domæne; at stable et fragment oven på et modstridende giver en resolver, der indlæses glad og svarer forkert. dnsmasq-manualen definerer begge direktiver og lyttekontrollen.
Bekræft derefter den kørende tjeneste, ikke filen. En konfigurationstest plus en genstart er minimum, og det effektive svar er det, en forespørgsel returnerer.
Rut resolveren, ikke bare websiden
WireGuards AllowedIPs bestemmer, hvilke destinationer der kommer ind i tunnelen. Hvis resolveradressen falder uden for den, forlader forespørgslen den normale rute og når aldrig dnsmasq, selv om selve NAS'en er tilgængelig. Medtag resolverens adresse eller det LAN-præfiks, der indeholder den, og kontroller gatewayens videresendelsespolitik på den anden side.
Tillad UDP og TCP på port 53 fra det autoriserede tunnelområde, med en returvej tilbage til klientens tunneladresse. Videresend ikke port 53 fra WAN for at gøre test nemmere: en åben rekursiv resolver på en hjemmeforbindelse findes inden for få timer. At binde til en grænseflade er ikke i sig selv en adgangspolitik.
Kontroller svaret før applikationen
Spørg først resolveren direkte, derefter systemet, derefter applikationen. Hvert trin isolerer et led i kæden, og forskellen mellem dem 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-forespørgslen er værd at køre, fordi et afkortet UDP-svar tvinger et nyt forsøg, og en politik, der dropper TCP 53, giver fejl, der ser periodiske ud. Trin getent viser, hvad maskinens resolverkonfiguration faktisk gør, hvilket ikke altid er det, du skubbede ud.
Beslut, hvad der sker, når tunnelen er nede
Hvis klientens generelle DNS peger på 192.168.50.53, holder enhver navneopløsning op med at virke, når tunnelen ikke er oppe. Det er acceptabelt på en maskine, der kun er nyttig med tunnelen, og uacceptabelt på en bærbar computer, der også bruger Wi-Fi på en café. Split-DNS undgår spørgsmålet helt, fordi kun home.arpa-opslag afhænger af hjemmeresolveren.
Husk, hvad navnet er: home.arpa er reserveret til beboelsesnetværk og er ikke globalt unikt, så et andet netværk kan med rette bruge samme navn. Det er en lokal bekvemmelighed, ikke en troværdig identifikator. Hold posten opdateret, når tjenesten flytter, og fjern resolverpolitikken, når laboratoriet nedlægges, i stedet for at efterlade en bærbar computer, der peger på en adresse, den kun kan nå gennem en tunnel, der ikke findes længere.