Dirigir los clientes OpenVPN a un resolutor Pi-hole en otro host

Poner una dirección de Pi-hole en un perfil de OpenVPN no crea una ruta hacia ella, no concede permiso para consultarla ni garantiza que el cliente la use. Con Pi-hole en una máquina distinta de la LAN, cuatro cosas tienen que alinearse: la ruta desde el cliente, el reenvío desde la puerta de enlace, la ruta de retorno al pool y la política de recepción en el propio Pi-hole. Cada fallo se ve distinto en un registro. Recorrerlos en ese orden es más rápido que arreglar el último primero. El atajo habitual, abrir la recursión a todos los orígenes, cambia un problema pequeño por uno permanente.

Qué hace y qué no hace la opción DNS empujada

El servidor anuncia un resolutor con la directiva siguiente, suponiendo que 192.168.50.53 es el host de Pi-hole. El cliente recibe la opción y, según su plataforma y su integración de resolutor , la aplica a la interfaz del túnel o la ignora en favor de un stub local. La línea de ruta importa tanto como la línea DNS, porque un resolutor al que el cliente no puede llegar no es ningún resolutor. Nada de esto se ve desde el lado del 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 una opción no es lo mismo que usarla. Un cliente Linux con un gestor de resolutores puede aceptar el servidor empujado y enviarle solo ciertos dominios; un cliente que gestiona el DNS por sí mismo puede sobrescribir el ajuste por completo. Las rutas empujadas también están restringidas en algunas plataformas, lo que deja el resolutor inalcanzable aunque la opción se haya aceptado. Comprueba en el cliente qué servidor responde, no en el servidor qué se envió.

La opción tampoco dice nada del lado del servidor. El tráfico DNS todavía tiene que viajar del cliente a la puerta de enlace y de la puerta de enlace a Pi-hole antes de que ninguna opción importe. Una ruta ausente y una consulta rechazada se parecen desde el cliente, así que confirma primero el reenvío en la puerta de enlace.

La ruta de retorno de Pi-hole al pool

Si se conserva la dirección de origen del cliente, Pi-hole responde a una dirección dentro del pool de VPN. Su propia tabla de enrutamiento probablemente no sabe nada de ese pool, así que la respuesta se va a su puerta de enlace predeterminada y desaparece. El registro de consultas muestra una petición sin respuesta correspondiente, algo fácil de malinterpretar como un problema de cortafuegos.

Da al router de la LAN una ruta estática para el pool con la puerta de enlace de OpenVPN como siguiente salto, o traduce el origen en la puerta de enlace antes de reenviar a Pi-hole. La primera mantiene las direcciones de cada cliente visibles en el registro de consultas de Pi-hole. La segunda elimina el requisito de ruta de retorno pero hace que cada consulta parezca venir de la puerta de enlace. Ninguna es incorrecta; responden a preguntas distintas.

Si importan los informes o las políticas por cliente, la ruta estática es el mejor intercambio. Si la LAN la gestiona otra persona y no hay ruta disponible, la traducción es la opción pragmática, con la pérdida de la identidad del cliente documentada. Anota cuál elegiste, porque cada pregunta posterior sobre registros depende de ello.

El modo de escucha de Pi-hole para clientes enrutados

La lista desplegable de comportamiento de escucha de interfaces, en la página de ajustes bajo DNS, decide a qué orígenes responde Pi-hole. Su opción más estricta solo acepta clientes de redes conectadas directamente; la opción que permite dispositivos a un salto como máximo lo extiende a las subredes detrás de un router adyacente, que es justo el aspecto de un cliente VPN enrutado. El paquete sí llega a la interfaz de la LAN, pero su dirección de origen pertenece a otra subred. Es un rechazo por política y no un fallo de enrutamiento, y la diferencia importa al leer registros.

La guía de escucha de Pi-hole separa las fuentes conectadas localmente de los orígenes enrutados, y la interfaz de llegada no es la prueba. Elige un modo que permita el pool de VPN sin permitir todo internet, y combínalo con una regla de cortafuegos que acepte DNS solo desde el pool.

Abrir la recursión a todos los orígenes para que funcione la primera consulta es la reparación equivocada. Convierte un resolutor privado en uno abierto, y la solución es un permiso acotado en lugar de uno global.

Hacer coincidir la respuesta con el registro de consultas

Pregunta al cliente, luego comprueba el servidor y compara los dos. En un cliente con systemd-resolved, los comandos siguientes informan qué resolutor produjo una respuesta y qué servidores están configurados por enlace. Usa un nombre que solo Pi-hole conozca, porque una consulta directa a la dirección de Pi-hole demuestra accesibilidad, no configuración.

resolvectl query intranet.example.lan
resolvectl dns

La respuesta esperada nombra 192.168.50.53 como servidor y devuelve una dirección que solo ese resolutor conocería. Luego mira la vista propia de Pi-hole: pihole -t sigue el registro de consultas en vivo, y cada línea lleva la dirección de origen. Si el origen es la dirección de túnel del cliente, la ruta del pool está intacta. Si es la dirección LAN de la puerta de enlace, hay traducción de origen y la dirección propia del cliente nunca aparecerá.

Si no aparece nada en el registro, la consulta nunca llegó a Pi-hole y el reenvío de la puerta de enlace es lo siguiente que hay que revisar. Si la consulta aparece y no vuelve ninguna respuesta, el problema es la ruta de retorno, que es la sección anterior. Dividir el fallo de esta manera evita que un fallo de enrutamiento se confunda con una regla de cortafuegos.

Comprobar la regla de reenvío de la puerta de enlace

La puerta de enlace tiene que reenviar los paquetes DNS del cliente hacia Pi-hole, y la regla que lo hace merece leerse en lugar de suponerse. Los comandos siguientes listan las reglas que tocan el puerto 53 con contadores, en un host nftables y en un host iptables. Una regla que existe pero muestra cero coincidencias es la señal de que el 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

Lee los contadores, no solo las reglas. Una regla que nunca coincide significa que el paquete sale por otra interfaz, o que el cliente nunca lo envió. Una regla que coincide en cada consulta significa que el reenvío funciona y que el problema está más adelante en la ruta.

Sea cual sea la herramienta que use el host, mantén la comprobación estrecha: el pool como origen, el puerto 53 como destino y Pi-hole como único objetivo permitido. Una regla de reenvío amplia que también permita el puerto 80 es otro problema esperando a ocurrir.