Apontar clientes OpenVPN para um resolvedor Pi-hole noutro host

Pôr um endereço de Pi-hole num perfil OpenVPN não cria um caminho até ele, não concede permissão para o consultar nem garante que o cliente o use. Com o Pi-hole numa máquina separada da LAN, quatro coisas têm de alinhar-se: a rota a partir do cliente, o encaminhamento a partir do gateway, o caminho de retorno para o pool e a política de receção no próprio Pi-hole. Cada falha aparece de forma diferente num registo. Tratá-las por essa ordem é mais rápido do que corrigir a última primeiro. O atalho habitual, abrir a recursão a todas as origens, troca um problema pequeno por um permanente.

O que a opção DNS empurrada faz e não faz

O servidor anuncia um resolvedor com a diretiva abaixo, assumindo que 192.168.50.53 é o host do Pi-hole. O cliente recebe a opção e, consoante a plataforma e a integração do resolvedor , aplica-a à interface do túnel ou ignora-a em favor de um stub local. A linha da rota importa tanto como a linha DNS, porque um resolvedor que o cliente não consegue alcançar não é resolvedor nenhum. Nada disto é visível do lado do servidor.

server 10.90.0.0 255.255.255.0
push "dhcp-option DNS 192.168.50.53"
push "route 192.168.50.0 255.255.255.0"

Receber uma opção não é o mesmo que usá-la. Um cliente Linux com um gestor de resolvedores pode aceitar o servidor empurrado e enviar-lhe apenas certos domínios; um cliente que gere o DNS sozinho pode substituir a definição por completo. As rotas empurradas também são restringidas em algumas plataformas, o que deixa o resolvedor inalcançável mesmo que a opção tenha sido aceite. Verifique no cliente qual servidor responde, não no servidor o que foi enviado.

A opção também não diz nada sobre o lado do servidor. O tráfego DNS continua a ter de viajar do cliente para o gateway e do gateway para o Pi-hole antes de qualquer opção importar. Uma rota em falta e uma consulta recusada parecem iguais do lado do cliente, por isso confirme primeiro o encaminhamento no gateway.

O caminho de retorno do Pi-hole para o pool

Se o endereço de origem do cliente for preservado, o Pi-hole responde para um endereço dentro do pool VPN. A sua própria tabela de rotas provavelmente nada sabe desse pool, por isso a resposta vai para o gateway predefinido e desaparece. O registo de consultas mostra um pedido sem resposta correspondente, o que é fácil de confundir com um problema de firewall.

Dê ao router da LAN uma rota estática para o pool com o gateway OpenVPN como próximo salto, ou traduza a origem no gateway antes de encaminhar para o Pi-hole. A primeira mantém os endereços de cada cliente visíveis no registo de consultas do Pi-hole. A segunda elimina o requisito de rota de retorno mas faz cada consulta parecer vir do gateway. Nenhuma está errada; respondem a perguntas diferentes.

Se os relatórios ou as políticas por cliente importarem, a rota estática é a melhor troca. Se a LAN for gerida por outra pessoa e não houver rota disponível, a tradução é a opção pragmática, com a perda da identidade do cliente registada. Anote qual escolheu, porque cada pergunta posterior sobre registos depende disso.

O modo de escuta do Pi-hole para clientes encaminhados

A lista pendente do comportamento de escuta das interfaces, na página de definições em DNS, decide a que origens o Pi-hole responde. A opção mais estrita aceita apenas clientes em redes ligadas diretamente; a opção que permite dispositivos a no máximo um salto estende isso às sub-redes atrás de um router adjacente, que é exatamente o aspeto de um cliente VPN encaminhado. O pacote chega de facto à interface da LAN, mas o endereço de origem pertence a outra sub-rede. É uma recusa de política e não uma falha de encaminhamento, e a diferença importa quando se leem registos.

O guia de escuta do Pi-hole separa as origens ligadas localmente das origens encaminhadas, e a interface de chegada não é o critério. Escolha um modo que permita o pool VPN sem permitir toda a internet, e combine-o com uma regra de firewall que aceite DNS apenas do pool.

Abrir a recursão a todas as origens para a primeira consulta funcionar é a reparação errada. Transforma um resolvedor privado num aberto, e a correção é uma permissão delimitada em vez de global.

Fazer corresponder a resposta ao registo de consultas

Pergunte ao cliente, depois verifique o servidor e compare os dois. Num cliente systemd-resolved, os comandos abaixo indicam que resolvedor produziu uma resposta e que servidores estão configurados por ligação. Use um nome que só o Pi-hole conhece, porque uma consulta direta ao endereço do Pi-hole prova alcançabilidade e não configuração.

resolvectl query intranet.example.lan
resolvectl dns

A resposta esperada nomeia 192.168.50.53 como servidor e devolve um endereço que só esse resolvedor conheceria. Depois veja a vista do próprio Pi-hole: pihole -t segue o registo de consultas em direto, e cada linha traz o endereço de origem. Se a origem for o endereço de túnel do cliente, a rota do pool está intacta. Se for o endereço LAN do gateway, há tradução de origem e o endereço do próprio cliente nunca aparecerá.

Se nada aparecer no registo, a consulta nunca chegou ao Pi-hole e o encaminhamento no gateway é a próxima coisa a verificar. Se a consulta aparecer e não voltar resposta, o caminho de retorno é o problema, ou seja, a secção anterior. Dividir a falha desta forma evita que uma falha de encaminhamento seja tomada por uma regra de firewall.

Verificar a regra de encaminhamento do gateway

O gateway tem de encaminhar os pacotes DNS do cliente para o Pi-hole, e a regra que o faz merece ser lida em vez de assumida. Os comandos abaixo listam as regras que tocam a porta 53 com contadores, num host nftables e num host iptables. Uma regra que existe mas mostra zero correspondências é o sinal de que o tráfego está a ser descartado antes de ser traduzido.

sudo nft list ruleset | grep -A3 'dport 53'
sudo iptables -t nat -L POSTROUTING -n -v | grep 53

Leia os contadores, não apenas as regras. Uma regra que nunca corresponde significa que o pacote sai por outra interface, ou que o cliente nunca o enviou. Uma regra que corresponde a cada consulta significa que o encaminhamento funciona e que o problema está mais adiante no caminho.

Seja qual for a ferramenta usada pelo host, mantenha a verificação estreita: o pool como origem, a porta 53 como destino e o Pi-hole como único alvo permitido. Uma regra de encaminhamento ampla que também permita a porta 80 é outro problema à espera de acontecer.