WireGuard non empurra DNS: servir unha zona BIND privada

O saúdo inicial transporta claves e IP permitidas, nunca un resolutor. Aquí tes unha zona BIND 9 privada xa resolta máis a política de cliente por enlace que a fai resolver.

Levantaches WireGuard, o túnel pasa tráfico e o nome interno segue sen resolverse. O seguinte paso adoita ser buscar un axuste de DNS na configuración de WireGuard, coma se un par puidese empurrar un resolutor tal como fan outras VPN. Non pode. O saúdo inicial transporta claves, enderezos de interface e IP permitidas, e non ten campo para servidores DNS nin dominios de busca. A política de resolutor vive no cliente, e aí pertence a corrección.

O túnel e o resolutor son contratos separados

WireGuard é pequeno a propósito. Move paquetes para os enderezos que listas e autentica pares; todo o que está por riba desa capa é o teu deseño. OpenVPN pode empurrar un dhcp-option DNS porque a súa canle de control transporta configuración, e esa diferenza desconcerta a quen se move entre os dous.

Así que un túnel que funciona non che di nada sobre a resolución de nomes. O cliente pode ter unha ruta perfecta cara a 10.90.0.1 e aínda así enviar as súas consultas a un resolutor público, e por iso o síntoma parece “a VPN rompeu o DNS” cando en realidade o DNS nunca se apuntou á VPN.

Serve a zona sen converterte nun resolutor recursivo

O lado do servidor é unha zona autoritativa pequena, non un resolutor xeral. Neste exemplo a pasarela é 10.90.0.1, os clientes son 10.90.0.0/24, e a aplicación que che importa responde en 10.60.0.20.

Fusiona estes axustes no 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;
};

Despois declara a zona e o seu ficheiro:

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 erro de sintaxe ao recargar bota abaixo todo o servidor para cada zona que serve:

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

Abre UDP e TCP 53 só na interface da VPN. Publicar unha autoridade privada na interface pública convida tanto a consultas coma a enumeración, e allow-transfer debería quedar pechado salvo que un secundario realmente o necesite.

Apunta o cliente cara a ela, por enlace

Supón que NetworkManager posúe a conexión e que systemd-resolved é o resolutor. Le primeiro a política existente, sobre todo calquera dominio de encamiñamento raíz, porque unha entrada ~. superará o que estás a punto de engadir.

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

A til é o carácter importante. Marca o dominio como só-ruta: os nomes baixo corp.example van ao servidor DNS deste enlace, e o dominio non se engade como sufixo de busca de nomes curtos. Sen ela, teclear portal comeza a resolver portal.corp.example, o cal é cómodo para ti e sorprendente para todos os demais. Mantén a til dentro das comiñas, porque unha sen comiñas é unha expansión da shell que agarda apuntar ao teu directorio persoal.

Aplica o cambio mediante o xestor que posúe a interface, e despois reconecta a conexión. Non inicies unha segunda instancia de wg-quick para a mesma interface; dous donos pelexarán polas rutas e un deles gañará no peor momento.

Verifica o camiño antes do nome

Consulta o nome desde o cliente e confirma tanto a resposta coma o servidor que a produciu:

resolvectl query portal.corp.example

Se iso devolve 10.60.0.20, o contrato DNS está cumprido. Se expira, comproba primeiro a ruta cara a 10.90.0.1, despois a regra da devasa e despois allow-query no servidor. Os fallos de resolución de nomes nesta configuración son case sempre alcanzabilidade ou unha ACL, non o ficheiro de zona. Traballa cara a fóra desde o cliente, porque o servidor non che pode dicir por que unha consulta nunca chegou.

Lembra que a aplicación aínda necesita a súa propia ruta e o seu propio permiso de servizo. Un nome resolvido que apunta a un enderezo inalcanzable é outro fallo coa mesma roupa.

O que aínda non é automático

As aplicacións coa súa propia lóxica de resolutor ignoran por completo o resolutor do sistema, e ningunha cantidade de nmcli cambia iso. Os despregamentos que validan DNSSEC necesitan un deseño explícito de áncora de confianza para a zona privada; a resposta non é unha instrución xeral de desactivar a validación. Proba co mesmo software de cliente que executan os teus usuarios, non cunha ferramenta que casualmente use o resolutor do sistema. A fenda entre ambos é todo o informe de erro.

As flotas poden automatizar esta política de cliente mediante o seu sistema de aprovisionamento, pero a política segue sendo un obxecto aparte cun dono. A referencia de BIND 9 cobre os controis de escoita e consulta usados arriba, e é o lugar correcto para confirmar o comportamento para a versión que teñas instalada.

Seguinte paso: engade o incremento do número de serie da zona e os comandos de comprobación ao teu procedemento de cambios, para que unha edición de rexistro non poida chegar a produción sen revisar.

Artigos relacionados