WireGuard no empuja DNS: servir una zona BIND privada

El saludo inicial transporta claves e IP permitidas, nunca un resolutor. Aquí tienes una zona BIND 9 privada ya resuelta más la política de cliente por enlace que la hace resolver.

Has levantado WireGuard, el túnel pasa tráfico y el nombre interno sigue sin resolverse. El siguiente movimiento suele ser buscar un ajuste de DNS en la configuración de WireGuard, como si un par pudiera empujar un resolutor tal como hacen otras VPN. No puede. El saludo inicial transporta claves, direcciones de interfaz e IP permitidas, y no tiene campo para servidores DNS ni dominios de búsqueda. La política de resolutor vive en el cliente, y ahí pertenece la corrección.

El túnel y el resolutor son contratos separados

WireGuard es pequeño a propósito. Mueve paquetes para las direcciones que enumeras y autentica pares; todo lo que está por encima de esa capa es tu diseño. OpenVPN puede empujar un dhcp-option DNS porque su canal de control transporta configuración, y esa diferencia desconcierta a quien se mueve entre los dos.

Así que un túnel que funciona no te dice nada sobre la resolución de nombres. El cliente puede tener una ruta perfecta hacia 10.90.0.1 y aun así enviar sus consultas a un resolutor público, y por eso el síntoma parece “la VPN rompió el DNS” cuando en realidad el DNS nunca se apuntó a la VPN.

Sirve la zona sin convertirte en un resolutor recursivo

El lado del servidor es una zona autoritativa pequeña, no un resolutor general. En este ejemplo la puerta de enlace es 10.90.0.1, los clientes son 10.90.0.0/24, y la aplicación que te importa responde en 10.60.0.20.

Combina estos ajustes en el bloque options existente en lugar de crear un segundo:

options {
    listen-on { 127.0.0.1; 10.90.0.1; };
    listen-on-v6 { none; };
    allow-query { 127.0.0.1; 10.90.0.0/24; };
    allow-transfer { none; };
    recursion no;
};

Luego declara la zona y su archivo:

zone "corp.example" {
    type primary;
    file "/etc/bind/db.corp.example";
};
$TTL 300
@ IN SOA ns.corp.example. hostmaster.corp.example. ( 1 3600 600 604800 300 )
@      IN NS ns.corp.example.
ns     IN A  10.90.0.1
portal IN A  10.60.0.20

Valida antes de recargar, porque un error de sintaxis al recargar tumba todo el servidor para cada zona que sirve:

named-checkconf
named-checkzone corp.example /etc/bind/db.corp.example

Abre UDP y TCP 53 solo en la interfaz de la VPN. Publicar una autoridad privada en la interfaz pública invita tanto a consultas como a enumeración, y allow-transfer debería permanecer cerrado salvo que un secundario realmente lo necesite.

Apunta el cliente hacia ella, por enlace

Supón que NetworkManager posee la conexión y que systemd-resolved es el resolutor. Lee primero la política existente, sobre todo cualquier dominio de enrutamiento raíz, porque una entrada ~. superará lo que estás a punto de añadir.

nmcli connection modify wg-office +ipv4.dns 10.90.0.1
nmcli connection modify wg-office +ipv4.dns-search '~corp.example'

La tilde es el carácter importante. Marca el dominio como solo-ruta: los nombres bajo corp.example van al servidor DNS de este enlace, y el dominio no se añade como sufijo de búsqueda de nombres cortos. Sin ella, teclear portal empieza a resolver portal.corp.example, lo cual es cómodo para ti y sorprendente para todos los demás. Mantén la tilde dentro de las comillas, porque una sin comillas es una expansión del shell que espera apuntar a tu directorio personal.

Aplica el cambio mediante el gestor que posee la interfaz, y luego reconecta la conexión. No inicies una segunda instancia de wg-quick para la misma interfaz; dos dueños se pelearán por las rutas y uno de ellos ganará en el peor momento.

Verifica el camino antes del nombre

Consulta el nombre desde el cliente y confirma tanto la respuesta como el servidor que la produjo:

resolvectl query portal.corp.example

Si eso devuelve 10.60.0.20, el contrato DNS está cumplido. Si expira, comprueba primero la ruta hacia 10.90.0.1, luego la regla del cortafuegos y luego allow-query en el servidor. Los fallos de resolución de nombres en esta configuración son casi siempre alcanzabilidad o una ACL, no el archivo de zona. Trabaja hacia fuera desde el cliente, porque el servidor no puede decirte por qué una consulta nunca llegó.

Recuerda que la aplicación todavía necesita su propia ruta y su propio permiso de servicio. Un nombre resuelto que apunta a una dirección inalcanzable es otro fallo con la misma ropa.

Lo que todavía no es automático

Las aplicaciones con su propia lógica de resolutor ignoran por completo el resolutor del sistema, y ninguna cantidad de nmcli cambia eso. Los despliegues que validan DNSSEC necesitan un diseño explícito de ancla de confianza para la zona privada; la respuesta no es una instrucción general de desactivar la validación. Prueba con el mismo software de cliente que ejecutan tus usuarios, no con una herramienta que casualmente use el resolutor del sistema. La brecha entre ambos es todo el informe de error.

Las flotas pueden automatizar esta política de cliente mediante su sistema de aprovisionamiento, pero la política sigue siendo un objeto aparte con un dueño. La referencia de BIND 9 cubre los controles de escucha y consulta usados arriba, y es el lugar correcto para confirmar el comportamiento para la versión que tengas instalada.

Siguiente paso: añade el incremento del número de serie de la zona y los comandos de comprobación a tu procedimiento de cambios, para que una edición de registro no llegue a producción sin revisar.

Artículos relacionados