Pi-hole não bloqueia anúncios após a VPN conectar: cinco verificações

Os anúncios ainda aparecem num cliente, o Pi-hole declara-se saudável e o túnel está ativo, por isso o instinto é encaminhar o tráfego desse cliente através do Pi. É a curva errada. A filtragem precisa das perguntas, não dos pacotes, e um cliente cujas consultas vão para o resolvedor do provedor continua sem filtro, para onde quer que o tráfego flua. Percorra esta lista em ordem e pare no primeiro passo que falhar, porque um passo posterior não pode dizer nada enquanto um anterior estiver quebrado.

1. Leia o resolvedor que o cliente realmente usa

Pergunte ao cliente, não ao router. No Linux, o resolvectl status imprime os servidores DNS por ligação e qual ligação vence; o /etc/resolv.conf sozinho é normalmente um stub que aponta para 127.0.0.53. No Windows, o ipconfig /all lista os servidores fornecidos pelo DHCP por adaptador, e no macOS o scutil --dns mostra o mesmo por âmbito. Se a resposta não for o endereço do Pi-hole, tem um problema de atribuição e o passo 2 é onde ele vive.

Duas coisas derrotam o resolvedor do sistema mesmo quando ele está configurado corretamente. Navegadores com o seu próprio DNS seguro (a opção “Use secure DNS” do Chrome, o network.trr.mode do Firefox) enviam consultas por HTTPS a um resolvedor público e nunca abrem a porta 53. E um cliente VPN no próprio cliente pode instalar um servidor DNS na sua interface de túnel com um domínio de encaminhamento ~., o que torna essa ligação autoritativa para todos os nomes.

Teste o caminho que as aplicações percorrem, não o caminho que uma ferramenta de depuração percorre. O resolvectl query example.com mostra qual ligação respondeu, e o getent hosts example.com passa pelo mesmo caminho NSS que uma aplicação; no macOS, o dscacheutil -q host -a name example.com lê os resolvedores por âmbito que o scutil --dns lista. Um dig nu não faz isto: lê o /etc/resolv.conf e salta a seleção por ligação, por isso pode responder a partir do Pi-hole enquanto todas as aplicações usam o resolvedor empurrado, e é exatamente essa a falha para a qual esta lista existe. Guarde o dig @192.168.1.53 para testar um servidor específico.

2. Confirme quem distribui a resposta

A atribuição vem de quem responde ao DHCP. No dnsmasq é uma única linha, dhcp-option=6,192.168.1.53; na interface web de um router é o campo DNS da secção DHCP da LAN. Os clientes têm de renovar antes de o ver. Um dispositivo ligado há dias ainda mantém a concessão antiga, e um dispositivo com um resolvedor escrito à mão mantém-na para sempre. Renove num cliente de teste em vez de assumir a propagação.

O IPv6 é a metade que fica esquecida. Os anúncios do router podem transportar o seu próprio servidor DNS (RDNSS), e no OpenWrt isso é a opção ra_dns do odhcpd; um cliente que prefere IPv6 usa esse servidor enquanto a opção DHCPv4 que acabou de definir fica sem uso. Se não está pronto para servir DNS por IPv6, apague apenas o anúncio de DNS: ra_dns no odhcpd, ou a opção RDNSS naquilo que responde aos anúncios do router. Desligar o anúncio inteiro também retira o endereçamento IPv6 da LAN, o que é uma mudança muito maior do que a pretendida, enquanto apagar só a opção de DNS mantém o endereçamento intacto e torna o RDNSS em falta visível numa captura de pacotes.

3. Prove que a consulta chega ao Pi-hole

Uma consulta a partir do Pi não prova nada sobre o caminho de rede. Execute-a do cliente e leia o código de resposta:

dig @192.168.1.53 example.com
dig @192.168.1.53 doubleclick.net

Um tempo limite aponta para filtragem ou para uma rota; REFUSED aponta para uma regra de acesso; SERVFAIL aponta para o resolvedor a montante atrás do Pi-hole; uma resposta correta que nunca aparece no registo de consultas significa que o cliente perguntou outra coisa. Verifique UDP e TCP 53, porque as respostas grandes e alguns resolvedores recaem em TCP, e publique ambos quando o Pi-hole corre num contentor. Um mapeamento que só cobre UDP produz falhas intermitentes que parecem perda de pacotes.

Depois, o modo de escuta do Pi-hole decide se responde de todo. No modo apenas local, o dnsmasq ignora consultas de origens que não estão numa sub-rede ligada diretamente, e é exatamente esse o aspeto de um cliente atrás de outro router ou que chega por um túnel: o cliente esgota o tempo e a consulta nunca chega ao registo. Uma consulta que ainda assim aparece como REFUSED foi rejeitada por uma lista de acesso ou por uma regra de firewall. Permitir todas as origens é a correção habitual, em conjunto com uma regra de firewall que limita a porta 53 às suas próprias sub-redes.

4. Verifique se o túnel substituiu ou engoliu a resposta

Este é o caso em que os dois sintomas se escondem. Quando o router é ele próprio um cliente VPN, uma opção DNS empurrada pode sobrepor-se à definição da LAN no momento em que o túnel sobe: os servidores OpenVPN empurram dhcp-option DNS, e os perfis WireGuard trazem a sua própria entrada DNS. Leia o resolvedor efetivo do router com o túnel ativo, não antes, e ignore o que a página da LAN afirma.

A outra falha é acessibilidade, não substituição. Se os prefixos permitidos do túnel incluírem a sua sub-rede de LAN, o router tem uma rota que envia as consultas de 192.168.1.53 para dentro do túnel, e o outro lado não tem rota de volta: as consultas esgotam o tempo apesar de o túnel estar saudável. O contrário acontece quando o Pi-hole está numa sub-rede que o túnel não transporta. Compare o endereço com os prefixos permitidos do túnel e a tabela de rotas do router antes de voltar a tocar no DNS.

Escolha uma correção, não ambas. Ou mantenha o túnel longe do DNS — com pull-filter ignore “dhcp-option DNS” no OpenVPN e sem prefixo de LAN em AllowedIPs no WireGuard —, ou aceite o resolvedor empurrado e abdique da filtragem local para os clientes atrás desse router. Escolha o que escolher, escreva-o ao lado do perfil, porque a próxima pessoa que o editar inverterá a decisão por acidente.

5. Repita o teste após uma reconexão

Faça uma consulta a partir de um cliente, confirme que esse cliente aparece no registo do Pi-hole, depois resolva um domínio que devia estar bloqueado e verifique se obtém a resposta de bloqueio em vez da real. Reconecte o túnel e execute as mesmas duas consultas, porque uma definição de resolvedor que só aguenta até à próxima conexão é o resultado habitual de uma correção aplicada na camada errada.

Deixe um caminho de resolvedor secundário que não dependa do túnel, para que uma falha do Pi-hole degenere em navegação sem filtro em vez de nenhuma navegação. Guarde os valores anteriores de DHCP e do resolvedor até o teste passar duas vezes; uma mudança que quebra a internet da casa à hora do jantar é muito mais difícil de depurar do que uma que pode reverter num minuto.