Por que o Pi-hole v6 ignora consultas DNS dos clientes WireGuard

O Pi-hole v6 recebe uma consulta DNS na porta 53 e então decide se o pacote que chegou pode ser respondido. Num host WireGuard, essa segunda decisão costuma ser o motivo pelo qual um cliente recebe timeout enquanto o resolvedor parece saudável a partir da LAN. A porta está aberta, o FTL está em execução, e ainda assim nada volta de 10.90.0.1. Três coisas interagem antes de uma resposta sair: dns.interface, dns.listeningMode e o firewall à frente de ambos.

O socket de escuta não decide quem recebe uma resposta

O FTL abre ouvintes UDP e TCP na porta 53. Na configuração padrão o socket costuma ser wildcard, então ss -lunp | grep :53 mostra 0.0.0.0:53 e [::]:53 quer os clientes VPN sejam atendidos ou não. Um socket wildcard aceita o pacote e então o FTL aplica suas regras de interface e de origem antes de responder. Por isso "a porta está escutando" prova muito pouco sobre um cliente de túnel.

Leia a configuração em execução em vez do arquivo que você acha ativo. pihole-FTL --config dns.interface e pihole-FTL --config dns.listeningMode imprimem os valores efetivos, e eles podem diferir do arquivo do host quando um contêiner, uma variável de ambiente ou um gerenciador de implantação é dono do ajuste. A referência de configuração do Pi-hole FTL lista os modos e qual deles depende da interface.

LOCAL pergunta qual sub-rede, SINGLE pergunta qual interface

O LOCAL, o padrão, responde a consultas cujo endereço de origem pertence a uma sub-rede configurada em uma das interfaces do host. Um wg0 simples com 10.90.0.1/24 passa nesse teste, porque o cliente em 10.90.0.2 está dentro da sub-rede do túnel. Um cliente roteado do outro lado de um par, ou um escondido atrás de NAT em outro prefixo, não passa, mesmo com o pacote chegando em wg0, e nenhuma consulta aparece no log.

O SINGLE muda a pergunta. Aceita consultas que chegam na interface indicada em dns.interface, incluindo loopback, e ignora a sub-rede de origem. É o modo que sobrevive a uma topologia VPN encadeada ou roteada. Defina as duas chaves juntas, porque um modo sem interface indicada não é uma instrução completa:

sudo pihole-FTL --config dns.interface "wg0"
sudo pihole-FTL --config dns.listeningMode "SINGLE"

O BIND muda o socket, e isso tem um custo

O BIND não filtra um socket wildcard; ele vincula a porta 53 apenas a endereços que existem na interface indicada, então o kernel recusa pacotes que chegam a outro lugar. É mais rigoroso que o SINGLE e não é sinônimo dele. O custo aparece na inicialização: se wg0 não estiver ativa quando o FTL inicia, pode não haver endereço para vincular, e o resolvedor pode rodar sem ouvinte até a interface aparecer e o FTL reiniciar.

Escolha BIND quando você controla a ordem de inicialização, por exemplo uma unidade systemd ordenada depois da interface WireGuard, e quando quer que o kernel descarte pacotes perdidos antes de o FTL vê-los. Escolha SINGLE quando o túnel vai e vem, ou quando a interface é criada por uma ferramenta que inicia depois do FTL.

O firewall é o segundo portão

Um modo FTL correto ainda falha se o firewall do host descarta a porta 53 em wg0. Permita a faixa de origem da VPN para os dois protocolos e mantenha o lado da internet fechado. No nftables, com a cadeia input existente na tabela inet filter, as regras ficam assim:

sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 udp dport 53 accept
sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 tcp dport 53 accept

Adicione regras IPv6 correspondentes se o túnel transportar IPv6, e coloque-as antes da política de descarte da cadeia. Se o host usa ufw ou firewalld, expresse a mesma correspondência nesse gerenciador em vez de misturar ferramentas. Não encaminhe a porta 53 do roteador da internet; os clientes devem alcançar o endereço VPN do resolvedor através do túnel.

Dois caminhos permanecem separados. As consultas dos clientes terminam no FTL. As buscas do próprio FTL para o upstream saem conforme a tabela de roteamento do host, que pode ou não usar o túnel, então um resolvedor que responde mas não devolve nada útil é um problema de upstream. A administração web e a API escutam nas próprias portas e precisam da própria restrição.

Verifique a resposta e a recusa

De um cliente VPN, consulte o endereço do resolvedor pelos dois protocolos: dig @10.90.0.1 example.com e dig +tcp @10.90.0.1 example.com. Depois verifique o log de consultas na interface de administração para confirmar que o FTL registrou a consulta. Um timeout do cliente sem entrada no log aponta para o firewall ou o filtro de interface; uma entrada sem resposta aponta para a resolução upstream.

Teste o caminho negativo a partir de um host fora da VPN. dig @10.90.0.1 example.com deve expirar, e ss -lunp no resolvedor não deve mostrar a porta 53 vinculada a um endereço público. Reinicie o serviço uma vez, depois reinicie o host e confirme que o resolvedor continua respondendo quando wg0 reaparece. Uma consulta que só funciona até o próximo reinício não é uma mudança concluída.