WireGuard não empurra DNS: servir uma zona BIND privada

O handshake transporta chaves e IPs permitidos, nunca um resolvedor. Aqui está uma zona BIND 9 privada pronta mais a política de cliente por ligação que a faz resolver.

Você subiu o WireGuard, o túnel passa tráfego, e o nome interno continua sem resolver. O próximo passo costuma ser procurar um ajuste de DNS na configuração do WireGuard, como se um par pudesse empurrar um resolvedor como outras VPNs fazem. Não pode. O handshake transporta chaves, endereços de interface e IPs permitidos, e não tem campo para servidores DNS ou domínios de busca. A política do resolvedor vive no cliente, e é ali que pertence a correção.

O túnel e o resolvedor são contratos separados

O WireGuard é pequeno de propósito. Ele move pacotes para os endereços que você lista e autentica pares; tudo acima dessa camada é o seu projeto. OpenVPN consegue empurrar um dhcp-option DNS porque o canal de controle dele transporta configuração, e essa diferença derruba quem transita entre os dois.

Então um túnel funcionando não diz nada sobre resolução de nomes. O cliente pode ter uma rota perfeita até 10.90.0.1 e ainda enviar as consultas a um resolvedor público, e é por isso que o sintoma parece “a VPN quebrou o DNS” quando o DNS nunca foi apontado para a VPN.

Sirva a zona sem virar um resolvedor recursivo

O lado do servidor é uma zona autoritativa pequena, não um resolvedor geral. Neste exemplo o gateway é 10.90.0.1, os clientes são 10.90.0.0/24, e a aplicação que lhe importa responde em 10.60.0.20.

Junte estes ajustes ao bloco options existente em vez de criar um 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;
};

Depois declare a zona e o arquivo dela:

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

Valide antes de recarregar, porque um erro de sintaxe ao recarregar derruba o servidor inteiro para cada zona que ele serve:

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

Abra UDP e TCP 53 apenas na interface da VPN. Publicar uma autoridade privada na interface pública convida tanto consultas quanto enumeração, e allow-transfer deve permanecer fechado a menos que um secundário realmente precise.

Aponte o cliente para ela, por ligação

Suponha que o NetworkManager possui a conexão e que o systemd-resolved é o resolvedor. Leia primeiro a política existente, especialmente qualquer domínio de roteamento raiz, porque uma entrada ~. vai superar o que você está prestes a adicionar.

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

O til é o caractere importante. Ele marca o domínio como somente-rota: nomes sob corp.example vão para o servidor DNS desta ligação, e o domínio não é anexado como sufixo de busca de nomes curtos. Sem ele, digitar portal começa a resolver portal.corp.example, o que é cômodo para você e surpreendente para todos os outros. Mantenha o til dentro das aspas, porque um sem aspas é uma expansão do shell esperando para apontar ao seu diretório pessoal.

Aplique a mudança pelo gerenciador que possui a interface, e depois reconecte a conexão. Não inicie uma segunda instância de wg-quick para a mesma interface; dois donos vão brigar por rotas e um deles vence no pior momento.

Verifique o caminho antes do nome

Consulte o nome a partir do cliente e confirme tanto a resposta quanto o servidor que a produziu:

resolvectl query portal.corp.example

Se isso retornar 10.60.0.20, o contrato de DNS está cumprido. Se der timeout, verifique primeiro a rota até 10.90.0.1, depois a regra de firewall, depois allow-query no servidor. Falhas de resolução de nomes neste arranjo são quase sempre alcance ou uma ACL, não o arquivo de zona. Trabalhe de dentro do cliente para fora, porque o servidor não pode lhe dizer por que uma consulta nunca chegou.

Lembre-se de que a aplicação ainda precisa da própria rota e da própria permissão de serviço. Um nome resolvido que aponta para um endereço inalcançável é outra falha com a mesma roupa.

O que ainda não é automático

Aplicações com lógica própria de resolvedor ignoram completamente o resolvedor do sistema, e nenhuma quantidade de nmcli muda isso. Implantações que validam DNSSEC precisam de um desenho explícito de âncora de confiança para a zona privada; a resposta não é uma instrução genérica de desativar a validação. Teste com o mesmo software de cliente que seus usuários executam, não com uma ferramenta que por acaso usa o resolvedor do sistema. A diferença entre os dois é todo o relatório de bug.

Frotas podem automatizar esta política de cliente pelo sistema de provisionamento, mas a política continua sendo um objeto separado com um dono. A referência do BIND 9 cobre os controles de escuta e de consulta usados acima, e é o lugar certo para confirmar o comportamento para a versão instalada.

Próximo passo: adicione o incremento do número de série da zona e os comandos de verificação ao seu procedimento de mudanças, para que uma edição de registro não chegue à produção sem checagem.

Artigos relacionados