Gee jou tuis-VPN sy eie DNS-rekords vir nas.home.arpa
Publiseer een naam uit dnsmasq, lei die resolver deur WireGuard, en kies dan tussen DNS vir die hele kliënt en split-DNS net vir home.arpa.
Sodra die tonnel op is, is die laaste stap gewoonlik 'n naam wat werk in plaas van 'n adres wat jy in 'n boekmerk plak. 'n dnsmasq-hostrekord plus 'n resolveradres wat die kliënt kan bereik, doen dit met twee lêers en geen multicast nie. Die besluit wat werklik nadenke verg, is smaller: stuur die kliënt alle DNS deur die tuisresolver, of net die name onder home.arpa? Alles hieronder veronderstel 'n goedgekeurde WireGuard-opstelling met 'n Linux-kliënt en 'n laboratoriumresolver wat die tuisadministrateur reeds bestuur.
Drie maniere om die kliënt 'n resolver te gee
| 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 |
Vir 'n skootrekenaar wat die tonnel nou en dan betree, is split-DNS die beter verstek: dit hou gewone internetname op die resolver wat die masjien reeds vertrou. Vir 'n masjien wat bestaan om tuisdienste te bereik, is dit eenvoudiger om die resolver te stoot, en die omvangkoste maak nie saak nie.
Publiseer die rekord by die resolver wat die sone besit
Hou die rolle uitmekaar voordat jy konfigurasie skryf: die VPN-kliëntadres, die resolver en die diens is drie verskillende hosts met drie verskillende take. In hierdie laboratorium is hulle 10.77.0.2 vir die kliënt, 192.168.50.53 vir dnsmasq en 192.168.50.20 vir die NAS, met die tonnel wat die tuis-LAN roeteer.
listen-address=127.0.0.1,192.168.50.53
bind-interfaces
local=/home.arpa/
host-record=nas.home.arpa,192.168.50.20
Die host-record-reël verskaf die adres en die local=-reël hou onbekende home.arpa-vrae binne hierdie resolver in plaas daarvan om hulle opstroom aan te stuur. Lees eers jou bestaande konfigurasie en versoen alles wat reeds 'n bediener, 'n koppelvlak of dieselfde plaaslike domein definieer; om 'n fragment bo-op 'n botsende een te stapel, lewer 'n resolver op wat gelukkig laai en verkeerd antwoord. Die dnsmasq-handleiding definieer beide richtlijnen en die luisterkontroles.
Verifieer dan die lopende diens, nie die lêer nie. 'n Konfigurasietoets plus 'n herbegin is die minimum, en die effektiewe antwoord is wat 'n navraag teruggee.
Roeteer die resolver, nie net die webblad nie
WireGuard se AllowedIPs bepaal watter bestemmings die tonnel binnegaan. As die resolveradres buite dit val, verlaat die navraag die normale roete en bereik nooit dnsmasq nie, selfs al is die NAS self bereikbaar. Sluit die resolver se adres in, of die LAN-voorvoegsel wat dit bevat, en kyk na die gateway se aanstuurbeleid aan die oorkant.
Laat UDP en TCP op poort 53 vanaf die gemagtigde tonnelreeks toe, met 'n terugpad na die kliënt se tonneladres. Moenie poort 53 van die WAN af aanstuur om toetsing makliker te maak nie: 'n oop rekursiewe resolver op 'n tuisverbinding word binne ure gevind. Om aan 'n koppelvlak te bind is nie op sigself 'n toegangsbeleid nie.
Kontroleer die antwoord voor die toepassing
Vra die resolver eers direk, vra dan die stelsel, en vra dan die toepassing. Elke stap isoleer een skakel in die ketting, en die verskil tussen hulle is die diagnose.
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'
Die TCP-navraag is die moeite werd om te hardloop, want 'n afgekapte UDP-antwoord dwing 'n herpoging, en 'n beleid wat TCP 53 laat val, lewer foute op wat intermitterend lyk. Die getent-stap wys wat die masjien se resolverkonfigurasie werklik doen, wat nie altyd is wat jy gestoot het nie.
Besluit wat gebeur wanneer die tonnel af is
As die kliënt se algemene DNS na 192.168.50.53 wys, hou elke naamresolusie op werk wanneer die tonnel nie op is nie. Dit is aanvaarbaar op 'n masjien wat net nuttig is met die tonnel, en onaanvaarbaar op 'n skootrekenaar wat ook kafee-Wi-Fi gebruik. Split-DNS vermy die vraag heeltemal, want net home.arpa-opsoeke hang van die tuisresolver af.
Onthou wat die naam is: home.arpa is gereserveer vir residensiële netwerke en is nie wêreldwyd uniek nie, so 'n ander netwerk kan wettig dieselfde naam gebruik. Dit is 'n plaaslike gerief, nie 'n betroubare identifiseerder nie. Hou die rekord bygewerk wanneer die diens skuif, en verwyder die resolverbeleid wanneer die laboratorium uit diens gestel word eerder as om 'n skootrekenaar te los wat na 'n adres wys wat hy net deur 'n tonnel kan bereik wat nie meer bestaan nie.