Como o Social Dork cria um bloqueador de anúncios Pi-hole com o ZimaBoard 2

Agradecemos a The Social Dork | Cibersegurança por partilhar um projeto com Pi-hole e Tailscale que filtra pedidos DNS em casa e a partir de um telemóvel fora de casa. O ZimaBoard 2 executa os serviços, o Pi-hole verifica os domínios solicitados e o Tailscale proporciona uma ligação privada ao servidor. Veja o tutorial original no YouTube para assistir à demonstração completa.

Veja antes de ler: Este vídeo de oito minutos é útil se quiser perceber onde se enquadra a filtragem de anúncios ao nível da rede, antes de alterar as definições de DNS da sua casa. O criador instala o Pi-hole no ZimaOS, testa um cliente Windows, adiciona listas de bloqueio e, em seguida, liga um telemóvel através do Tailscale.

O resultado útil é um serviço de filtragem DNS reutilizável. O criador demonstra menos anúncios visíveis num sítio Web de exemplo e atividade de consultas a partir do telemóvel remoto. Essas observações mostram que o percurso de filtragem funciona nessa configuração; não provam que todos os anúncios, sistemas de rastreio ou ligações maliciosas serão bloqueados.

Perceba o que o Pi-hole filtra antes de escolher o hardware

A explicação começa com um sítio Web que carrega conteúdo de vários domínios. O Pi-hole recebe os pedidos DNS do cliente e verifica os nomes solicitados face à política configurada. Os nomes permitidos podem ser resolvidos através de um resolvedor a montante; os nomes bloqueados recebem uma resposta de bloqueio. O ponto de controlo importante é a consulta DNS, antes de o cliente tentar obter conteúdo desse domínio.

Esse âmbito também define o limite. Um filtro DNS não consegue distinguir um anúncio de conteúdo pretendido quando ambos usam o mesmo nome de anfitrião. Os clientes que usam outro resolvedor podem contornar o percurso escolhido. Considere o título do vídeo, «bloquear todos os anúncios», como a motivação do projeto, e não como um resultado universal. A filtragem de conteúdo no navegador e a filtragem DNS funcionam em camadas diferentes e podem complementar-se.

Siga uma consulta no sistema antes de alterar toda a rede. Um cliente pede o endereço de um anfitrião; o Pi-hole aplica a sua política; um pedido permitido pode chegar ao resolvedor a montante; a resposta regressa ao cliente. A ligação Web subsequente é um fluxo separado. Isto explica por que motivo um contador de domínios bloqueados é uma prova útil de atividade DNS, mas não mede todas as ligações efetuadas por uma aplicação.

Garanta que o serviço DNS tem um ponto de acesso estável na rede doméstica

The Social Dork utiliza o ZimaBoard 2 e instala o Pi-hole através da loja de aplicações ZimaOS mostrada no vídeo. O criador também menciona um portátil existente como anfitrião alternativo. O requisito prático é ter uma máquina sempre disponível quando os clientes dependem dela para o DNS; a demonstração não justifica a compra da opção com mais memória apenas para filtrar tráfego.

Ligue o anfitrião, atribua ao ponto final DNS um endereço estável ou uma reserva DHCP e confirme que o serviço está acessível a partir de um cliente de teste. A rede do contentor e o mapeamento de portas afetam o endereço que os clientes devem utilizar. Verifique se a sua instalação responde efetivamente a consultas DNS nesse ponto final, em vez de presumir que uma página de administração acessível significa que o serviço DNS está pronto.

Registe os endereços antes de alterar um cliente

Numa instalação em contentor, verifique a acessibilidade do serviço DNS tanto por TCP como por UDP. O exemplo oficial do Docker do Pi-hole expõe ambos os protocolos na porta 53 e mantém o diretório de configuração. Esses detalhes são importantes mesmo quando uma loja de aplicações oculta a configuração do contentor por trás de um botão Instalar. Consulte a configuração real da aplicação antes de alterar um serviço do anfitrião que possa já utilizar a mesma porta.

O vídeo mostra a instalação a partir da loja de aplicações ZimaOS do criador. A versão atual da aplicação e o modo de rede podem ser diferentes. Guarde as definições que explicam como a aplicação acede à rede: o endereço, as portas publicadas, a localização do armazenamento, o resolvedor a montante e o comportamento ao reiniciar. Esse pequeno registo facilita a verificação de uma migração ou reinstalação posterior.

Teste num cliente antes de alterar o DNS de toda a casa

No tutorial, um portátil Windows permanece ligado à rede Wi-Fi doméstica enquanto a definição DNS IPv4 é alterada para o endereço do Pi-hole. Em seguida, o criador verifica a atividade das consultas. Este é um primeiro teste simples de gerir: se a navegação deixar de funcionar, basta repor as definições desse cliente, enquanto o resto da casa mantém a configuração existente.

Para uma cobertura mais ampla, o guia pós-instalação do Pi-hole explica como o DHCP pode anunciar o endereço DNS do Pi-hole aos clientes. Renove a concessão do cliente ou volte a ligar-se e, em seguida, verifique que servidor de resolução utiliza efetivamente. Verifique também o DNS IPv6 e quaisquer definições de DNS encriptado do navegador ou do sistema operativo; alterar um único campo IPv4 não prova que todas as consultas o utilizem.

Um segundo servidor de resolução sem filtragem também pode comprometer o resultado esperado. Os clientes podem utilizar outro servidor de resolução configurado, em vez de o manterem estritamente como alternativa de emergência. Decida se a prioridade é a continuidade ou uma filtragem consistente e teste o comportamento quando o anfitrião do Pi-hole estiver indisponível. Registe as definições originais para que seja fácil reverter a experiência com o DNS.

Utilize um teste local repetível

1. Anote a configuração DNS atual do portátil e o endereço pretendido do Pi-hole.
2. Envie explicitamente uma consulta permitida para o Pi-hole e, em seguida, localize a consulta correspondente no respetivo registo.
3. Teste um domínio que conste da sua lista de bloqueio ativa e confirme o resultado do bloqueio.
4. Defina o Pi-hole como preferência DNS normal do cliente e repita o teste sem selecionar explicitamente um servidor de resolução.
5. Navegue por alguns serviços comuns, incluindo um processo de início de sessão, antes de implementar a alteração através do DHCP.

Por exemplo, nslookup example.com PIHOLE_LAN_IP testa um servidor de resolução especificado; substitua PIHOLE_LAN_IP pelo endereço do seu servidor. Esta consulta explícita verifica o próprio servidor. Em seguida, nslookup example.com verifica o percurso normal de resolução do sistema. Nenhum dos testes, por si só, prova que um navegador com definições DNS próprias siga o mesmo percurso, por isso verifique também um novo pedido dessa aplicação.

Ao procurar a causa de uma falha, distinga a acessibilidade do endereço da resolução de nomes. Um dispositivo pode continuar ligado ao Wi-Fi e, ainda assim, não conseguir abrir sites porque o respetivo servidor DNS está indisponível. Mantenha as definições originais do cliente disponíveis até o novo servidor de resolução funcionar de forma consistente. Após uma alteração de DHCP, renove a concessão ou volte a ligar-se e verifique as definições que o cliente recebeu efetivamente.

Adicione listas de bloqueio de forma a conseguir diagnosticar problemas

A seguir, o criador importa listas de bloqueio adicionais e mostra o aumento do total de domínios bloqueados. Esse número descreve a base de dados de políticas, não a qualidade da experiência de navegação. Uma lista maior pode incluir mais domínios indesejados, mas também pode interferir nos processos de início de sessão, nos leitores multimédia ou noutras funcionalidades que dependem de um serviço partilhado.

Adicione uma lista mantida de cada vez, atualize a base de dados de filtragem e volte a testar os serviços que realmente utiliza. Quando algo deixar de funcionar, consulte o registo de consultas para identificar o nome afetado e teste uma entrada de lista de permissões com âmbito restrito. A documentação da base de dados de domínios do Pi-hole explica como interagem as entradas de permissão e bloqueio. Evite resolver um problema de início de sessão, permitindo de forma abrangente uma coleção de domínios não relacionada.

Guarde o motivo de uma nova lista ou exceção juntamente com a alteração. Uma política sensata deve resistir a uma semana de utilização normal, não apenas a uma captura de ecrã bem-sucedida. Se mantiver o filtro para outras pessoas, dê-lhes uma forma de descrever um serviço avariado e a hora aproximada em que falhou. Isso é mais útil do que um relato genérico de que «a internet está em baixo».

Utilize o Tailscale para aceder ao mesmo filtro fora de casa

A segunda parte adiciona o Tailscale ao servidor e a um telemóvel. Nas definições de DNS da tailnet, The Social Dork introduz o endereço Tailscale do servidor como servidor de nomes, liga o telemóvel e volta a verificar a atividade do Pi-hole. O endpoint DNS continua em casa, enquanto o telemóvel autorizado consegue aceder-lhe através da rede privada.

O guia oficial de integração do Pi-hole do Tailscale apresenta os detalhes de configuração atuais. Confirme que o Pi-hole aceita consultas recebidas através da interface privada pretendida e que a política de acesso da tailnet permite tráfego DNS. Se pretender que os clientes compatíveis deem preferência ao servidor de nomes configurado na tailnet, consulte o comportamento de substituição de DNS do Tailscale e verifique a definição no próprio cliente.

Utilizar um resolvedor DNS doméstico através do Tailscale não encaminha automaticamente todo o tráfego Web pela ligação de casa. A saída completa para a Internet através de um nó de saída doméstico é uma configuração distinta. Este projeto apenas necessita de uma rota privada para o serviço DNS; não é necessário expor à Internet um resolvedor DNS público nem a respetiva página de administração.

Valide o percurso de DNS privado por etapas

1. Confirme que o servidor e o telemóvel estão inscritos na tailnet pretendida e conseguem comunicar entre si.
2. Adicione o endpoint do Pi-hole acessível como servidor de nomes pretendido da tailnet.
3. Reveja a utilização de DNS do Tailscale pelo cliente e a definição de substituição do servidor de nomes, de acordo com o comportamento pretendido.
4. Verifique se o listener e a política de acesso do Pi-hole aceitam tráfego DNS proveniente desse percurso privado.
5. Desligue o Wi-Fi de casa e repita, no telemóvel, uma consulta permitida e outra bloqueada.

Um listener configurado para aceitar apenas uma rede local específica pode explicar por que os dispositivos da rede doméstica funcionam, mas um dispositivo Tailscale não. A referência de configuração do listener DNS do Pi-hole descreve os modos disponíveis. Escolha um modo compatível com o seu contentor e a rede privada, limitando o acesso de entrada aos dispositivos pretendidos. As definições de listener abrangentes exigem limites de firewall igualmente claros.

Distinga também as definições de DNS do acesso de saída à Internet. Um servidor de nomes pode filtrar consultas sem se tornar um nó de saída. Se ativar separadamente um nó de saída, volte a verificar o comportamento do DNS; a Tailscale documenta essa interação na sua referência de DNS e servidores de nomes. Um teste bem-sucedido no Wi-Fi de casa não substitui o teste do mesmo telemóvel com dados móveis.

Faça do percurso, e não apenas de um contador, o foco do teste final

Repita o teste a partir de uma ligação diferente, por exemplo, usando dados móveis com o Wi-Fi desligado. Verifique se uma nova consulta do telemóvel aparece no Pi-hole, se um site permitido continua a abrir e se o nome bloqueado selecionado recebe uma resposta de filtragem. Um total crescente pode incluir pedidos de outros dispositivos; use o cliente relevante e os registos de data e hora para associar a observação ao seu teste.

O próximo passo na série deste criador é uma firewall OPNsense com DNS do Pi-hole para clientes sem fios. Para um exemplo mais abrangente de organização de aplicações e acesso remoto, a configuração modular de laboratório doméstico de kabuto mostra como estes serviços podem integrar uma instalação física bem mantida. Comece com um cliente a funcionar e, em seguida, expanda a política de filtragem depois de verificar os percursos local e remoto. Volte à demonstração de Pi-hole e Tailscale de The Social Dork para consultar a sequência original.

Resolva problemas na primeira camada que falhou

Considere o serviço uma dependência da família assim que outros dispositivos começarem a utilizá-lo. Faça uma cópia de segurança da configuração, mantenha um conjunto funcional de fontes de políticas e teste uma atualização primeiro com um cliente. Após reiniciar o anfitrião, volte a verificar uma consulta permitida e outra bloqueada. O facto de o ícone da aplicação voltar a aparecer no painel é apenas o início dessa verificação.

A documentação de configuração de contentores do Pi-hole explica as opções de persistência e de rede. Guarde esse registo operacional juntamente com a configuração que escolheu, em vez de depender de uma captura de ecrã do endereço de outra pessoa.

Perguntas frequentes

O Pi-hole remove todos os anúncios do YouTube?

A filtragem de DNS não consegue separar de forma fiável os vídeos pretendidos da publicidade quando partilham o mesmo nome de anfitrião. Considere este projeto como filtragem de domínios e verifique as aplicações específicas que utiliza, em vez de prometer a eliminação de anúncios em todo o lado.

Todos os dispositivos da família precisam do Tailscale?

Os dispositivos domésticos podem usar um ponto de acesso LAN ao Pi-hole através das respetivas definições de DNS. Neste projeto, o Tailscale fornece a ligação privada para os dispositivos que precisam do mesmo resolvedor quando estão fora de casa.

Preciso de um nó de saída do Tailscale para esta configuração?

Não, apenas para aceder ao serviço DNS privado. Um nó de saída altera a rota do tráfego da Internet e é uma configuração separada, com o seu próprio comportamento de DNS.

Porque é que a página do Pi-hole abre, mas o DNS não funciona?

A interface Web e o serviço DNS usam portas diferentes e podem ter mapeamentos de contentor ou regras de acesso distintos. Teste diretamente uma consulta DNS para o endereço pretendido e verifique a entrada correspondente no registo.

Porque pode outro servidor DNS contornar o filtro?

Os clientes não tratam necessariamente um segundo servidor de nomes configurado como uma alternativa apenas para emergências. Se um filtragem consistente for importante, verifique todos os resolvedores anunciados e o comportamento real do cliente.

O que devo guardar antes de atualizar a aplicação?

Guarde a configuração funcional da aplicação, as localizações dos dados persistentes, as fontes de políticas e as definições do cliente usadas num teste comprovadamente funcional. Após a atualização, repita esse teste e confirme que as definições foram mantidas.

Conclusão

O projeto do Social Dork liga três decisões: onde o DNS é executado, que clientes o utilizam e como um telemóvel autorizado lhe acede a partir de outra rede. Uma implementação útil torna estas decisões visíveis e testáveis. A prova mais sólida é uma consulta correspondente do cliente, a resposta de política esperada e a navegação normal a continuar a funcionar.

Comece com um cliente, passe para o DHCP depois de o teste local ser bem-sucedido e valide o Tailscale a partir de uma ligação realmente separada. Depois, mantenha o filtro como um serviço de que a família depende. Mantenha o vídeo sobre o Pi-hole e o Tailscale original disponível para acompanhar a sequência do criador, juntamente com a documentação oficial atual das versões instaladas.