Como corrigir o DNS no WireGuard: 3 falhas comuns

Por que o DNS falha assim que o túnel WireGuard é ativado

O DNS pelo WireGuard falha de três formas, e cada uma tem sua própria correção. Nada é resolvido, ou os nomes são resolvidos, mas as consultas saem da sua máquina fora do túnel, ou o próprio gerenciador de resolução do cliente substitui a configuração segundos depois que a interface é iniciada. O túnel quase nunca é o problema. O problema é a linha que informa ao cliente qual resolvedor consultar e o roteamento que determina como os pacotes chegam a esse resolvedor.

O WireGuard transporta pacotes IP e não tem conhecimento de DNS (domain name system, o serviço que transforma nomes como example.com em endereços IP). A linha DNS = em um bloco [Interface] do cliente não é uma configuração do WireGuard. Ela é lida por wg-quick, o wrapper de shell que ativa a interface, e wg-quick edita a configuração de resolução do cliente enquanto o túnel está ativo e a restaura em wg-quick down. Portanto, todos os problemas abaixo são problemas de roteamento ou de wg-quick, nunca de criptografia. Se o túnel ainda não foi criado, comece por uma VPN WireGuard auto-hospedada em seu próprio VPS e depois volte a esta página.

Confirme que o túnel está funcionando antes de alterar o DNS.

sudo wg show
ping -c 3 10.8.0.1
ping -c 3 1.1.1.1

wg show deve listar o peer com um latest handshake recente, e os dois pings devem responder. Se ping 1.1.1.1 atingir o tempo limite, você tem um problema de encaminhamento ou NAT (network address translation), não um problema de DNS, e nenhuma alteração na configuração do resolvedor ajudará. Todos os exemplos aqui usam 10.8.0.0/24 como a sub-rede do túnel e 10.8.0.1 como o endereço do túnel do servidor. Substitua-os pelos seus próprios valores.

Falha 1: nada é resolvido porque o resolvedor nunca responde

O sintoma é preciso. ping 1.1.1.1 funciona, e curl https://example.com retorna:

curl: (6) Could not resolve host: example.com

Consulte diretamente o resolvedor do túnel a partir do cliente. dig faz parte do pacote dnsutils no Ubuntu e no Debian.

dig +short @1.1.1.1 example.com
dig +short @10.8.0.1 example.com

O primeiro comando retorna um endereço, o que prova que os pacotes chegam à internet pelo túnel. O segundo não retorna nada e exibe ;; communication timed out; no servers could be reached. Esse é o diagnóstico completo: o cliente está apontando para 10.8.0.1, e 10.8.0.1 não responde na porta UDP 53.

Há duas causas possíveis. Nenhum resolvedor está em execução no servidor, ou o firewall do servidor descarta a consulta antes que ela chegue. Verifique os dois pontos no servidor.

sudo ss -ulnp | grep ':53'
sudo nft list ruleset

Um resolvedor em execução e associado corretamente exibe uma linha com 10.8.0.1:53 ou 0.0.0.0:53. No Ubuntu, o problema geralmente é 127.0.0.53:53: esse é o listener stub do systemd-resolved, que associa um endereço de loopback e não pode ser acessado deliberadamente por outras máquinas. Apontar um cliente VPN para um servidor cujo único resolvedor é esse stub produz exatamente esse timeout.

A correção é usar um resolvedor que escute no endereço do túnel e adicionar uma regra de firewall que permita o acesso dos peers.

sudo apt update && sudo apt install -y unbound
printf 'server:\n  interface: 10.8.0.1\n  access-control: 10.8.0.0/24 allow\n' \
  | sudo tee /etc/unbound/unbound.conf.d/wireguard.conf
sudo systemctl restart unbound
sudo ss -ulnp | grep '10.8.0.1:53'

Em seguida, abra a porta somente para o tráfego do túnel. Com nftables, adicione estas duas linhas à cadeia input em /etc/nftables.conf e recarregue com sudo systemctl reload nftables.

udp dport 53 iifname "wg0" accept
tcp dport 53 iifname "wg0" accept

Com ufw, sudo ufw allow in on wg0 to any port 53 faz o mesmo trabalho. Nunca abra a porta 53 para a internet pública. Um resolvedor recursivo aberto é encontrado por scanners em poucos dias e usado para amplificar ataques de negação de serviço. Seu provedor perceberá esse tráfego antes de você.

Execute dig +short @10.8.0.1 example.com novamente no cliente. Um endereço na saída significa que o caminho até o resolvedor funciona. Agora o cliente só precisa usá-lo. Adicione a linha ao bloco [Interface] do cliente e reinicie a interface com sudo wg-quick down wg0 && sudo wg-quick up wg0.

[Interface]
PrivateKey = <client private key>
Address = 10.8.0.2/32
DNS = 10.8.0.1

Falha 2: vazamentos de DNS, porque um túnel dividido não roteia o resolvedor

Este caso é pior porque tudo parece funcionar. Os nomes são resolvidos, as páginas carregam e as consultas atravessam a rede local em texto claro, embora você não quisesse confiar nela.

Duas configurações causam esse problema. A primeira é um cliente com AllowedIPs = 0.0.0.0/0, ::/0 e sem a linha DNS =. wg-quick instala a rota padrão na própria tabela de roteamento e adiciona uma regra com suppress_prefixlength 0. Isso mantém intencionalmente as rotas locais mais específicas ativas, para que a máquina ainda possa acessar a impressora. O resolvedor que o cliente aprendeu via DHCP, normalmente o roteador em 192.168.1.1, corresponde a uma dessas rotas locais. O tráfego passa pelo túnel. A rede local ainda recebe a lista completa dos nomes que você consulta.

A segunda é um túnel dividido: AllowedIPs = 10.8.0.0/24 com DNS = 9.9.9.9. Como 9.9.9.9 não está dentro de AllowedIPs, o cliente não tem uma rota para ele pelo túnel. Por isso, a consulta sai pelo enlace local, exatamente como no primeiro caso.

Comprove qual resolvedor está realmente respondendo. whoami.akamai.net é um nome de teste público que responde com o endereço IP do resolvedor recursivo que fez a consulta. Assim, você pode comparar a resposta com o endereço público do seu servidor.

resolvectl status
dig +short whoami.akamai.net
sudo tcpdump -ni any -c 10 port 53

resolvectl status imprime um bloco por enlace. Se o bloco do seu enlace Ethernet ou sem fio ainda mostrar Current DNS Server: 192.168.1.1, enquanto o bloco wg0 não mostrar nenhum, esse é o vazamento. Se dig +short whoami.akamai.net retornar o endereço da sua conexão de banda larga residencial, em vez do endereço do servidor, isso confirma o problema no lado remoto. A linha tcpdump é a prova que encerra a discussão: em uma saída saudável, todos os pacotes destinados à porta 53 passam por wg0; em caso de vazamento, eles passam por wlan0 ou enp3s0.

A correção tem duas partes, e ambas são necessárias. Defina DNS como um endereço que esteja dentro do túnel e confirme que esse endereço está dentro de AllowedIPs.

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.8.0.0/24, 10.20.0.0/16

10.8.0.1 está dentro de 10.8.0.0/24. Portanto, a consulta é criptografada e enviada ao servidor. Se você insistir em usar um resolvedor público em um túnel dividido, adicione-o como uma rota de host: AllowedIPs = 10.8.0.0/24, 9.9.9.9/32. Os pacotes passarão pelo túnel, mas a rede local ainda poderá identificar que você escolheu esse provedor com base em sessões anteriores. Um resolvedor operado por você elimina essa questão.

A atribuição do resolvedor é uma das diferenças visíveis entre o WireGuard configurado manualmente e uma malha coordenada. Ela faz parte da relação de compromissos descrita em WireGuard comparado ao Tailscale. Executar um servidor de controle Headscale auto-hospedado oferece essa coordenação sem entregar seu material de chaves a terceiros.

Falha três: resolvconf e systemd-resolved entram em conflito em clientes Linux

Os clientes macOS, Windows, iOS e Android aplicam DNS = pelo aplicativo oficial e causam poucos problemas. No Linux, a configuração é aplicada por um script de shell que precisa identificar qual dos vários gerenciadores de resolução você está usando.

A primeira falha é explícita. sudo wg-quick up wg0 termina com:

resolvconf: command not found

wg-quick chama resolvconf, mas esse binário não está instalado. Instale a implementação que se comunica com systemd-resolved e ative a interface novamente.

sudo apt install -y openresolv
sudo systemctl restart systemd-resolved
sudo wg-quick down wg0 && sudo wg-quick up wg0
resolvectl status wg0

A segunda falha é silenciosa e é a que pode consumir uma noite inteira. A interface é ativada, resolvectl status wg0 mostra DNS Servers: 10.8.0.1 corretamente, mas as consultas ainda são enviadas ao resolvedor antigo. O systemd-resolved mantém uma lista de resolvedores separada para cada link e escolhe um link para cada consulta. Se nenhum link for marcado como rota padrão para nomes, ele continuará usando o resolvedor do link sem fio, porque esse link tem um domínio de pesquisa e o seu não.

Defina o resolvedor e assuma a rota padrão na mesma etapa. %i é expandido para o nome da interface, portanto este bloco funciona sem alterações em qualquer interface.

[Interface]
Address = 10.8.0.2/32
PostUp = resolvectl dns %i 10.8.0.1; resolvectl domain %i ~.
PostDown = resolvectl revert %i

Remova a linha DNS = quando usar PostUp dessa forma, pois, caso contrário, dois mecanismos gravarão o estado do resolvedor e apenas um deles fará a limpeza depois. O argumento ~. é a parte importante: ele marca wg0 como o domínio de roteamento para todos os nomes, fazendo o systemd-resolved enviar todas as consultas para lá em vez de escolher um link por consulta. Verifique o resultado.

resolvectl status wg0

Uma saída correta contém DNS Servers: 10.8.0.1 e Default Route: yes. Se Default Route mostrar no, a parte resolvectl domain não foi executada e você voltou à seleção de links.

Há outro caso que merece ser mencionado. Se /etc/resolv.conf for um arquivo real, e não um link simbólico para /run/systemd/resolve/stub-resolv.conf, algum outro componente é o responsável por ele, geralmente o NetworkManager ou um runtime de contêineres. Execute ls -l /etc/resolv.conf antes de investigar qualquer outra coisa, pois uma ferramenta que reescreve esse arquivo a cada alteração de rede desfará seu trabalho no momento menos conveniente.

A atualização: seu próprio resolvedor com filtragem pelo túnel

Quando as consultas passam pelo túnel de forma confiável, o resolvedor na outra ponta se torna um ponto de controle. Executar o AdGuard Home nesse local fornece filtragem por listas de bloqueio e um log de consultas para todos os dispositivos conectados, sem software no cliente e sem configuração por dispositivo. O script oficial de instalação, verificado em julho de 2026, é executado em uma linha.

curl -s -S -L https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sh -s -- -v

O assistente de configuração escuta na porta 3000 na primeira execução. Acesse-o pelo túnel em http://10.8.0.1:3000 em vez de abrir essa porta publicamente. No assistente, defina o endereço de escuta do DNS e o endereço de escuta administrativo como 10.8.0.1. Se unbound da primeira falha ainda estiver usando o mesmo endereço, pare-o primeiro com sudo systemctl disable --now unbound, porque dois processos não podem associar a porta UDP 53 a um mesmo endereço, e o segundo processo encerra com listen udp 10.8.0.1:53: bind: address already in use.

As configurações dos clientes não precisam ser alteradas se já estiverem definidas como DNS = 10.8.0.1. O log de consultas agora mostrará cada consulta de todos os peers. Isso é uma decisão real de privacidade, não um benefício sem custo: você transfere a confiança do seu provedor de internet para si mesmo e passa a ser responsável por manter esse servidor atualizado. Um servidor exposto à internet precisa ter o básico configurado primeiro, e os primeiros dez minutos em um VPS novo explica esses procedimentos.

FAQ

Por que meu túnel WireGuard se conecta, mas os nomes não são resolvidos?

O túnel transporta pacotes e não processa nomes. Portanto, um túnel funcional com consultas falhando indica que o resolvedor configurado não está respondendo. Teste com dig +short @10.8.0.1 example.com no cliente. Uma resposta communication timed out significa que não há nenhum resolvedor escutando nesse endereço do túnel. Isso ocorre frequentemente porque o stub do systemd-resolved escuta apenas em 127.0.0.53. Outra possibilidade é o firewall do servidor estar descartando a porta UDP 53 recebida em wg0. Corrija primeiro o listener. Depois, abra a porta somente para wg0.

Como verifico se meu DNS está vazando pelo WireGuard?

Execute sudo tcpdump -ni any -c 10 port 53 no cliente e monitore a coluna da interface enquanto navega. Todos os pacotes devem usar wg0. Se aparecerem na interface sem fio ou ethernet, as consultas estão saindo em texto claro. dig +short whoami.akamai.net fornece uma segunda verificação, pois responde com o endereço público do resolvedor recursivo que fez a consulta. Portanto, uma resposta que não contenha o endereço do seu servidor confirma o vazamento.

Preciso da linha DNS = se uso um túnel dividido?

Sim. O endereço do resolvedor também deve estar dentro de AllowedIPs. Caso contrário, o cliente não terá uma rota até ele. Com AllowedIPs = 10.8.0.0/24, um resolvedor em 10.8.0.1 estará coberto e a consulta será criptografada. Um resolvedor público, como 9.9.9.9, não estará coberto. Nesse caso, a consulta sairá pelo link local, mesmo que a linha DNS pareça correta.

Por que o resolvectl mostra o servidor correto, mas as consultas ainda são enviadas para outro lugar?

O systemd-resolved mantém uma lista de resolvedores por link e escolhe um link para cada consulta. Assim, uma entrada correta em wg0 é ignorada enquanto outro link mantiver a rota padrão para nomes. Adicione PostUp = resolvectl dns %i 10.8.0.1; resolvectl domain %i ~. ao bloco [Interface] do cliente e remova a linha DNS =. Em seguida, resolvectl status wg0 deverá informar Default Route: yes.

Qual cliente devo corrigir primeiro quando vários estão com problemas?

Corrija primeiro um cliente Linux, pois ele é a única plataforma que mostra o mecanismo. resolvectl status e tcpdump informam qual resolvedor respondeu e qual interface transportou o pacote. Aplicativos de telefone e desktop aplicam os mesmos valores de DNS e AllowedIPs sem expor essa configuração. Depois que o cliente Linux estiver correto, você estará copiando uma configuração que já foi validada.