Dea á súa VPN doméstica os seus propios rexistros DNS para nas.home.arpa
Publique un nome desde dnsmasq, encamiñe o resolutor por WireGuard e logo escolla entre enviar o DNS a todo o cliente ou facer split-DNS só para home.arpa.
Unha vez o túnel está levantado, o último paso adoita ser un nome que funciona en lugar dun enderezo que pega nun marcador. Un rexistro de host de dnsmasq máis un enderezo de resolutor ao que o cliente poida chegar fan iso con dous ficheiros e sen multicast. A decisión que realmente require pensar é máis estreita: o cliente envía todo o DNS polo resolutor da casa, ou só os nomes baixo home.arpa? Todo o seguinte supón unha instalación de WireGuard aprobada cun cliente Linux e un resolutor de laboratorio que o administrador da casa xa xestiona.
Tres maneiras de entregar un resolutor ao cliente
| 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 |
Para un portátil que se une ao túnel de cando en vez, o split-DNS é o mellor valor por defecto: mantén os nomes ordinarios de internet no resolutor no que a máquina xa confía. Para unha máquina que existe para chegar aos servizos da casa, enviar o resolutor é máis sinxelo e o custo do alcance non importa.
Publique o rexistro no resolutor que posúe a zona
Manteña os papeis separados antes de escribir configuración: o enderezo do cliente VPN, o resolutor e o servizo son tres hosts distintos con tres traballos distintos. Neste laboratorio son 10.77.0.2 para o cliente, 192.168.50.53 para dnsmasq e 192.168.50.20 para o NAS, co túnel encamiñando a LAN da casa.
listen-address=127.0.0.1,192.168.50.53
bind-interfaces
local=/home.arpa/
host-record=nas.home.arpa,192.168.50.20
A liña host-record fornece o enderezo e a liña local= mantén as preguntas descoñecidas de home.arpa dentro deste resolutor en lugar de reenvialas cara arriba. Lea primeiro a súa configuración existente e concilie todo o que xa define un servidor, unha interface ou o mesmo dominio local; apilar un fragmento sobre un conflitivo produce un resolutor que carga alegremente e responde mal. O manual de dnsmasq define ambas as directivas e os controis de escoita.
Despois verifique o servizo en execución, non o ficheiro. Unha proba de configuración máis un reinicio é o mínimo, e a resposta efectiva é o que devolve unha consulta.
Encamiñe o resolutor, non só a páxina web
O AllowedIPs de WireGuard decide que destinos entran no túnel. Se o enderezo do resolutor queda fóra, a consulta sae pola ruta normal e nunca chega a dnsmasq, aínda que o propio NAS sexa accesible. Inclúa o enderezo do resolutor, ou o prefixo de LAN que o contén, e comprobe a política de reenvío da pasarela no outro extremo.
Permita UDP e TCP no porto 53 desde o rango de túnel autorizado, cun camiño de volta cara ao enderezo de túnel do cliente. Non reenvíe o porto 53 desde a WAN para facilitar as probas: un resolutor recursivo aberto nunha conexión doméstica atópase en poucas horas. Ligarse a unha interface non é unha política de acceso por si mesmo.
Comprobe a resposta antes da aplicación
Consulte primeiro o resolutor directamente, despois o sistema, despois a aplicación. Cada paso illa un elo da cadea, e a diferenza entre eles é o diagnóstico.
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'
Vale a pena executar a consulta TCP porque unha resposta UDP truncada obriga a reintentar, e unha política que descarta TCP 53 produce fallos que parecen intermitentes. O paso getent mostra que fai realmente a configuración de resolutor da máquina, que non sempre é o que vostede enviou.
Decida que pasa cando o túnel está caído
Se o DNS xeral do cliente apunta a 192.168.50.53, toda resolución de nomes deixa de funcionar cando o túnel non está levantado. Iso é aceptable nunha máquina que só é útil co túnel, e inaceptable nun portátil que tamén usa o Wi-Fi dunha cafetería. O split-DNS evita a cuestión por completo, porque só as consultas de home.arpa dependen do resolutor da casa.
Lembre o que é o nome: home.arpa está reservado para redes residenciais e non é único a nivel global, así que outra rede pode usar lexitimamente o mesmo nome. É unha comodidade local, non un identificador fiable. Manteña o rexistro ao día cando o servizo se move, e retire a política do resolutor cando o laboratorio se xubila en lugar de deixar un portátil apuntando a un enderezo ao que só pode chegar por un túnel que xa non existe.