Corrigir DNS no WireGuard: 3 falhas comuns

Por que o DNS deixa de funcionar assim que o túnel WireGuard é ativado

O DNS através do WireGuard falha de três formas, e cada uma tem a sua própria correção. Nada é resolvido, os nomes são resolvidos mas as consultas saem do computador sem passar pelo túnel, ou o próprio gestor de resolução do cliente substitui a configuração alguns segundos depois de a interface arrancar. O túnel quase nunca é o problema. O problema está na linha que indica ao cliente qual o resolver a consultar e no encaminhamento que determina como os pacotes chegam a esse resolver.

O WireGuard transporta pacotes IP e não conhece o DNS (domain name system, o serviço que converte nomes como example.com em endereços IP). A linha DNS = num bloco de cliente [Interface] não é uma configuração do WireGuard. Essa linha é lida por wg-quick, o wrapper de shell que ativa a interface, e wg-quick edita depois a configuração do resolver do cliente enquanto o túnel está ativo e restaura-a em wg-quick down. Portanto, todos os problemas abaixo são problemas de encaminhamento ou problemas de wg-quick, nunca problemas de criptografia. Se o túnel ainda não estiver configurado, comece por uma VPN WireGuard autoalojada no seu próprio VPS e volte depois a esta página.

Confirme primeiro que o túnel está saudável. Só depois altere 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 ambos os pings devem responder. Se ping 1.1.1.1 exceder o tempo limite, existe um problema de encaminhamento ou NAT (network address translation), não um problema de DNS, e nenhuma alteração na configuração do resolver irá ajudar. Se os pings responderem mas o débito cair assim que começa o tráfego real, trata-se de um problema separado, e o WireGuard lento quase sempre está relacionado com o MTU e não com qualquer aspeto desta página. Todos os exemplos aqui usam 10.8.0.0/24 como sub-rede do túnel e 10.8.0.1 como endereço do túnel no servidor. Substitua-os pelos seus próprios valores.

Falha 1: nada é resolvido porque o resolver nunca responde

O sintoma é claro. ping 1.1.1.1 funciona, e curl https://example.com devolve isto:

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

Consulte diretamente o resolver 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 devolve um endereço, o que prova que os pacotes chegam à Internet através do túnel. O segundo não devolve nada e apresenta ;; communication timed out; no servers could be reached. O diagnóstico é esse: o cliente está configurado para usar 10.8.0.1, e 10.8.0.1 não responde na porta UDP 53.

Há duas causas possíveis. Ou não existe nenhum resolver em execução no servidor, ou a firewall do servidor descarta a consulta antes de ela chegar. Verifique ambas no servidor.

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

Um resolver em execução e corretamente associado apresenta uma linha com 10.8.0.1:53 ou 0.0.0.0:53. No Ubuntu, a surpresa costuma ser 127.0.0.53:53: trata-se do listener stub do systemd-resolved, que se associa a um endereço de loopback e fica deliberadamente inacessível a partir de outras máquinas. Configurar um cliente VPN para usar um servidor cujo único resolver é esse stub produz exatamente este timeout.

A correção consiste num resolver que escute no endereço do túnel e numa 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'

Depois, abra a porta apenas para o tráfego do túnel. Com nftables, adicione estas duas linhas à chain 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. Nunca abra a porta 53 à Internet pública. Um resolver recursivo aberto é encontrado por scanners em poucos dias e usado para amplificar ataques de negação de serviço. O seu fornecedor vai detetar esse tráfego antes de si.

Execute novamente dig +short @10.8.0.1 example.com no cliente. Um endereço no resultado significa que o caminho até ao resolver funciona. O cliente só precisa agora de o utilizar. 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: fugas de DNS, porque um túnel dividido não encaminha o resolvedor

Esta falha é mais grave porque tudo parece funcionar. Os nomes são resolvidos, as páginas carregam e as consultas atravessam a rede local em texto simples, apesar de não querer confiar nela.

Duas configurações causam este problema. A primeira é um cliente com AllowedIPs = 0.0.0.0/0, ::/0 e sem uma linha DNS =. wg-quick instala a rota predefinida na sua própria tabela de encaminhamento e adiciona uma regra com suppress_prefixlength 0. Isto mantém intencionalmente as rotas locais mais específicas, para que a máquina continue a conseguir comunicar com a impressora. O resolvedor que o cliente aprendeu por DHCP, normalmente o router em 192.168.1.1, corresponde a uma dessas rotas locais. O seu tráfego passa pelo túnel. A rede local continua a receber a lista completa dos nomes que 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 esse endereço através do túnel. Por isso, a consulta sai pela ligação local, exatamente como no primeiro caso.

Confirme qual é o resolvedor que está realmente a responder. whoami.akamai.net é um nome de teste público que responde com o endereço IP do resolvedor recursivo que fez a consulta. Assim, 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 ligação. Se o bloco da ligação Ethernet ou sem fios ainda mostrar Current DNS Server: 192.168.1.1, enquanto o bloco wg0 não mostrar nenhum, existe uma fuga. Se dig +short whoami.akamai.net devolver o endereço da sua ligação de banda larga doméstica em vez do endereço do servidor, isso confirma o problema a partir do lado remoto. A linha tcpdump fornece a prova definitiva: numa configuração correta, todos os pacotes destinados à porta 53 passam por wg0; numa fuga, passam por wlan0 ou enp3s0.

A correção tem duas partes, e ambas são necessárias. Defina DNS para 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, por isso a consulta é encriptada e enviada para o servidor. Se precisar de usar um resolvedor público num túnel dividido, adicione-o como uma rota de host: AllowedIPs = 10.8.0.0/24, 9.9.9.9/32. Os pacotes passam então pelo túnel, embora a rede local ainda possa ver que escolheu esse fornecedor com base em sessões anteriores. Um resolvedor que execute no seu próprio servidor evita esta questão.

A atribuição de resolvers é uma das diferenças visíveis entre uma configuração WireGuard feita manualmente e uma mesh coordenada, e faz parte do compromisso descrito em WireGuard em comparação com Tailscale. Executar um servidor de controlo Headscale alojado por si fornece essa coordenação sem entregar o material das suas chaves a terceiros. Se essa última parte for o que o preocupa, tenha em conta que o Tailscale nunca detém as chaves que encriptam o seu tráfego e que a pergunta mais importante é o que um servidor de coordenação comprometido ou uma conta de identidade roubada poderia acrescentar à sua rede.

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

Os clientes macOS, Windows, iOS e Android aplicam DNS = através da aplicação oficial e causam poucos problemas. No Linux, essa definição é aplicada por um script de shell que tem de determinar qual dos vários gestores de resolução está a ser utilizado.

A primeira falha é evidente. 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 comunica com systemd-resolved e volte a ativar a interface.

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 corretamente DNS Servers: 10.8.0.1 e as consultas continuam a ser enviadas para o resolvedor antigo. O systemd-resolved mantém uma lista de resolvedores separada para cada ligação e escolhe uma ligação por consulta. Se nenhuma ligação estiver marcada como rota predefinida para nomes, continua a utilizar o resolvedor da ligação sem fios, porque essa ligação tem um domínio de pesquisa e a sua não.

Defina o resolvedor e assuma a rota predefinida no mesmo passo. %i é expandido para o nome da interface, por isso 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

Apague a linha DNS = quando utilizar PostUp desta forma, porque, caso contrário, dois mecanismos escrevem o estado do resolvedor e apenas um deles faz a limpeza depois. O argumento ~. é a parte importante: marca wg0 como o domínio de encaminhamento para todos os nomes, fazendo com que o systemd-resolved envie todas as consultas para essa ligação em vez de escolher uma ligação por consulta. Verifique o resultado.

resolvectl status wg0

Um resultado correto contém DNS Servers: 10.8.0.1 e Default Route: yes. Se Default Route apresentar no, a parte resolvectl domain não foi executada e o sistema voltou à seleção por ligação.

Vale a pena mencionar mais um caso. Se /etc/resolv.conf for um ficheiro real, em vez de um link simbólico para /run/systemd/resolve/stub-resolv.conf, outro componente é o responsável por esse ficheiro, normalmente o NetworkManager ou um runtime de contentores. Execute ls -l /etc/resolv.conf antes de investigar qualquer outra coisa, porque uma ferramenta que reescreva esse ficheiro a cada alteração de rede irá desfazer o seu trabalho no momento menos conveniente.

O upgrade: o seu próprio resolvedor com filtragem através do túnel

Quando as consultas passam de forma fiável pelo túnel, o resolvedor na outra extremidade torna-se um ponto de controlo. Executar o AdGuard Home nesse local dá a todos os dispositivos ligados filtragem por listas de bloqueio e um registo de consultas, sem software no cliente e sem configuração por dispositivo. O script oficial de instalação, verificado em julho de 2026, é composto por 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 durante a primeira execução. Aceda-lhe através do túnel em http://10.8.0.1:3000, em vez de abrir essa porta publicamente, e no assistente defina tanto o endereço de escuta do DNS como o endereço de escuta da administração para 10.8.0.1. Se unbound da falha um ainda mantiver o mesmo endereço, pare-o primeiro com sudo systemctl disable --now unbound, porque dois processos não podem associar a porta UDP 53 ao mesmo endereço e o segundo termina com listen udp 10.8.0.1:53: bind: address already in use.

As configurações dos clientes não precisam de alterações se já indicarem DNS = 10.8.0.1. O registo de consultas mostrará agora todas as pesquisas de todos os peers. Isto é uma decisão real de privacidade, não um benefício gratuito: transfere a confiança do seu fornecedor de Internet para si próprio, e é você quem tem de manter esse servidor atualizado. Um servidor exposto à Internet precisa primeiro das medidas básicas, e os primeiros dez minutos num VPS novo explica-as.

FAQ

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

O túnel transporta pacotes e não trata nomes. Portanto, um túnel funcional com consultas de nomes quebradas 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, geralmente porque o stub do systemd-resolved está vinculado apenas a 127.0.0.53, ou que o firewall do servidor está descartando o tráfego UDP destinado à porta 53 que chega por wg0. Corrija primeiro o listener e depois abra a porta apenas para wg0.

Como verifico se meu DNS está vazando pelo WireGuard?

Execute sudo tcpdump -ni any -c 10 port 53 no cliente e observe 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 simples. dig +short whoami.akamai.net fornece uma segunda verificação, porque responde com o endereço público do resolvedor recursivo que fez a consulta. Portanto, uma resposta que não seja 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, ou o cliente não terá uma rota para ele. Com AllowedIPs = 10.8.0.0/24, um resolvedor em 10.8.0.1 está abrangido e a consulta é criptografada. Um resolvedor público, como 9.9.9.9, não está abrangido. Portanto, a consulta sai 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. Por isso, uma entrada correta em wg0 é ignorada enquanto outro link mantém a rota padrão para os 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 deve informar Default Route: yes.

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

Corrija primeiro um cliente Linux, porque essa é a única plataforma que mostra o mecanismo. resolvectl status e tcpdump informam qual resolvedor respondeu e qual interface transportou o pacote. Aplicações de telemóvel e desktop usam os mesmos valores de DNS e AllowedIPs sem mostrar essa configuração interna. Portanto, quando o cliente Linux estiver correto, você estará copiando uma configuração que já foi validada.