Una vez que el túnel está levantado, el último paso suele ser un nombre que funciona en lugar de una dirección que pega en un marcador. Un registro de host de dnsmasq más una dirección de resolutor a la que el cliente pueda llegar hacen eso con dos archivos y sin multicast. La decisión que realmente exige pensar es más estrecha: ¿el cliente envía todo el DNS por el resolutor de casa, o solo los nombres bajo home.arpa? Todo lo siguiente supone una instalación de WireGuard aprobada con un cliente Linux y un resolutor de laboratorio que el administrador de la casa ya gestiona.

Tres formas de entregar un resolutor al cliente

ApproachScopeCost
DNS = in the wg-quick interfacethe client's general DNS while the tunnel is upevery name in the house now depends on the tunnel
Platform split-DNS for home.arpaonly that suffixmore configuration per client platform
Manual dig @resolverone query at a timefine for testing, useless for applications

Para un portátil que se une al túnel de vez en cuando, el split-DNS es el mejor valor por defecto: mantiene los nombres ordinarios de internet en el resolutor en el que la máquina ya confía. Para una máquina que existe para llegar a los servicios de casa, enviar el resolutor es más sencillo y el coste del alcance no importa.

Publique el registro en el resolutor que posee la zona

Mantenga los papeles separados antes de escribir configuración: la dirección del cliente VPN, el resolutor y el servicio son tres hosts distintos con tres trabajos distintos. En este laboratorio son 10.77.0.2 para el cliente, 192.168.50.53 para dnsmasq y 192.168.50.20 para el NAS, con el túnel enrutando la LAN de 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

La línea host-record aporta la dirección y la línea local= mantiene las preguntas desconocidas de home.arpa dentro de este resolutor en lugar de reenviarlas hacia arriba. Lea primero su configuración existente y concilie todo lo que ya defina un servidor, una interfaz o el mismo dominio local; apilar un fragmento sobre uno conflictivo produce un resolutor que carga felizmente y responde mal. El manual de dnsmasq define ambas directivas y los controles de escucha.

Después verifique el servicio en ejecución, no el archivo. Una prueba de configuración más un reinicio es el mínimo, y la respuesta efectiva es lo que devuelve una consulta.

Enrute el resolutor, no solo la página web

El AllowedIPs de WireGuard decide qué destinos entran en el túnel. Si la dirección del resolutor queda fuera, la consulta sale por la ruta normal y nunca llega a dnsmasq, aunque el propio NAS sea accesible. Incluya la dirección del resolutor, o el prefijo de LAN que la contiene, y compruebe la política de reenvío de la puerta de enlace en el otro extremo.

Permita UDP y TCP en el puerto 53 desde el rango de túnel autorizado, con un camino de vuelta hacia la dirección de túnel del cliente. No reenvíe el puerto 53 desde la WAN para facilitar las pruebas: un resolutor recursivo abierto en una conexión doméstica se encuentra en pocas horas. Enlazarse a una interfaz no es una política de acceso por sí mismo.

Compruebe la respuesta antes que la aplicación

Consulte primero al resolutor directamente, luego al sistema, luego a la aplicación. Cada paso aísla un eslabón de la cadena, y la diferencia entre ellos es el 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 la pena ejecutar la consulta TCP porque una respuesta UDP truncada obliga a reintentar, y una política que descarta TCP 53 produce fallos que parecen intermitentes. El paso getent muestra qué hace realmente la configuración de resolutor de la máquina, que no siempre es lo que usted envió.

Decida qué pasa cuando el túnel está caído

Si el DNS general del cliente apunta a 192.168.50.53, toda resolución de nombres deja de funcionar cuando el túnel no está levantado. Eso es aceptable en una máquina que solo es útil con el túnel, e inaceptable en un portátil que también usa el Wi-Fi de una cafetería. El split-DNS evita la cuestión por completo, porque solo las consultas de home.arpa dependen del resolutor de casa.

Recuerde qué es el nombre: home.arpa está reservado para redes residenciales y no es único a nivel global, así que otra red puede usar legítimamente el mismo nombre. Es una comodidad local, no un identificador fiable. Mantenga el registro al día cuando el servicio se mueva, y retire la política del resolutor cuando se jubile el laboratorio en lugar de dejar un portátil apuntando a una dirección a la que solo puede llegar por un túnel que ya no existe.

Artículos relacionados