Dirixir os clientes OpenVPN a un resolvedor Pi-hole noutro servidor

Pór un enderezo de Pi-hole nun perfil de OpenVPN non crea un camiño cara a el, non concede permiso para consultalo nin garante que o cliente o use. Cando Pi-hole está nunha máquina LAN separada, catro cousas deben aliñarse: a ruta desde o cliente, o reenvío desde a pasarela, o camiño de volta ao pool e a política de recepción no propio Pi-hole. Cada fallo ten un aspecto distinto nun rexistro. Tratalos nesa orde é máis rápido que arranxar o último primeiro. O atallo habitual, abrir a recursión a todas as orixes, troca un problema pequeno por un permanente.

Que fai e que non fai a opción DNS empurrada

O servidor anuncia un resolvedor coa directiva de abaixo, supoñendo que 192.168.50.53 é o servidor de Pi-hole. O cliente recibe a opción e, segundo a súa plataforma e a integración do resolvedor , aplícaa á interface do túnel ou ignóraa en favor dun stub local. A liña de ruta importa tanto como a liña DNS, porque un resolvedor ao que o cliente non chega non é ningún resolvedor. Nada disto é visible desde o 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"

Recibir unha opción non é o mesmo que usala. Un cliente Linux cun xestor de resolvedores pode aceptar o servidor empurrado e enviarlle só certos dominios; un cliente que xestiona o DNS por si mesmo pode sobrescribir o axuste por completo. As rutas empurradas tamén están restrinxidas nalgunhas plataformas, o que deixa o resolvedor inalcanzable aínda que a opción fose aceptada. Comproba no cliente que servidor responde, non no servidor que se enviou.

A opción tampouco di nada sobre o lado do servidor. O tráfico DNS aínda ten que viaxar do cliente á pasarela e da pasarela a Pi-hole antes de que calquera opción importe. Unha ruta que falta e unha consulta rexeitada vense iguais desde o cliente, así que confirma primeiro o reenvío na pasarela.

O camiño de volta de Pi-hole ao pool

Se se conserva o enderezo de orixe do cliente, Pi-hole responde a un enderezo dentro do pool VPN. A súa propia táboa de rutas probablemente non sabe nada dese pool, así que a resposta vai á súa pasarela predeterminada e desaparece. O rexistro de consultas mostra unha petición sen resposta correspondente, algo fácil de malinterpretar como un problema de devasas.

Dalle ao router da LAN unha ruta estática para o pool coa pasarela OpenVPN como seguinte salto, ou traduce a orixe na pasarela antes de reenviar a Pi-hole. A primeira mantén os enderezos de cada cliente visibles no rexistro de consultas de Pi-hole. A segunda elimina o requisito de ruta de volta pero fai que cada consulta pareza vir da pasarela. Ningunha é incorrecta; responden a preguntas distintas.

Se importan os informes ou as políticas por cliente, a ruta estática é o mellor intercambio. Se a LAN a xestiona outra persoa e non hai ruta dispoñible, a tradución é a opción pragmática, coa perda da identidade do cliente documentada. Anota cal escolliches, porque cada pregunta posterior sobre rexistros depende diso.

O modo de escoita de Pi-hole para clientes encamiñados

A lista despregable do comportamento de escoita das interfaces, na páxina de axustes baixo DNS, decide a que orixes responde Pi-hole. A opción máis estrita só acepta clientes en redes conectadas directamente; a opción que permite dispositivos a un salto como máximo esténdeo ás subredes detrás dun router adxacente, e así é exactamente como se ve un cliente VPN encamiñado. O paquete chega de feito á interface LAN, pero o seu enderezo de orixe pertence a outra subrede. Isto é un rexeitamento de política e non un fallo de encamiñamento, e a diferenza importa cando les rexistros.

A guía de escoita de Pi-hole separa as orixes conectadas localmente das orixes encamiñadas, e a interface de chegada non é o criterio. Escolle un modo que permita o pool VPN sen permitir toda a internet, e despois combínao cunha regra de devasas que acepte DNS só desde o pool.

Abrir a recursión a todas as orixes para que funcione a primeira consulta é a reparación incorrecta. Converte un resolvedor privado nun aberto, e a corrección é un permiso limitado, non global.

Fai coincidir a resposta co rexistro de consultas

Pregunta ao cliente, despois comproba o servidor e compara os dous. Nun cliente con systemd-resolved os comandos de abaixo informan que resolvedor produciu unha resposta e que servidores están configurados por ligazón. Usa un nome que só coñeza Pi-hole, porque unha consulta directa ao enderezo de Pi-hole demostra alcanzabilidade, non configuración.

resolvectl query intranet.example.lan
resolvectl dns

A resposta esperada nomea 192.168.50.53 como servidor e devolve un enderezo que só ese resolvedor coñecería. Despois mira a vista do propio Pi-hole: pihole -t segue o rexistro de consultas en directo, e cada liña leva o enderezo de orixe. Se a orixe é o enderezo do túnel do cliente, a ruta do pool está intacta. Se é o enderezo LAN da pasarela, hai tradución de orixe e o enderezo do propio cliente nunca aparecerá.

Se non aparece nada no rexistro, a consulta nunca chegou a Pi-hole e o seguinte que hai que comprobar é o reenvío na pasarela. Se a consulta aparece e non volve ningunha resposta, o problema é o camiño de volta, é dicir, a sección anterior. Dividir o fallo deste xeito evita que un erro de encamiñamento se confunda cunha regra de devasas.

Comproba a regra de reenvío da pasarela

A pasarela ten que reenviar os paquetes DNS do cliente cara a Pi-hole, e a regra que o fai merece lerse en vez de supoñerse. Os comandos de abaixo listan as regras que tocan o porto 53 con contadores, nun servidor nftables e nun servidor iptables. Unha regra que existe pero mostra cero coincidencias é o sinal de que o tráfico se descarta antes de traducirse.

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

Le os contadores, non só as regras. Unha regra que nunca coincide significa que o paquete sae por outra interface, ou que o cliente nunca o enviou. Unha regra que coincide en cada consulta significa que o reenvío funciona e que o problema está máis adiante na ruta.

Calquera que sexa a ferramenta que use o servidor, mantén a comprobación estreita: o pool como orixe, o porto 53 como destino e Pi-hole como único obxectivo permitido. Unha regra de reenvío ampla que tamén permita o porto 80 é outro problema que espera a ocorrer.