Punto de acceso Pi con Pi-hole y VPN: asigna una tarea a cada servicio

Un teléfono se une al punto de acceso del Pi, obtiene una dirección y la página sigue fallando. El Pi ejecuta un ayudante de punto de acceso, Pi-hole y un cliente de VPN, y cada uno cree que posee parte del camino. La mayoría de estos montajes fallan no porque un componente esté roto, sino porque dos componentes hacen el mismo trabajo. Asigna un dueño por función antes de ajustar cualquiera de ellos.

Asigna un dueño por función

Aquí importan cuatro funciones, y cada una necesita exactamente un dueño. La tabla siguiente nombra la función, un dueño viable y qué falla cuando dos servicios la reclaman.

El solapamiento suele llegar un paquete a la vez. El ayudante del punto de acceso instala su propia instancia de dnsmasq, Pi-hole quiere el puerto 53 y el cliente de VPN añade rutas. Cada paso parece razonable por sí solo, y juntos producen una máquina en la que el segundo servicio que arranca cambia en silencio el comportamiento del primero.

Anota los dueños antes de activar cualquier otra cosa. Una tabla breve en las notas de montaje impide que una instalación posterior asuma una función que ya tenía dueño.

Elige un rango y mantenlo lejos del túnel

Elige el rango del punto de acceso, la dirección del Pi dentro de él, el conjunto de DHCP y el resolutor que reciben los clientes. Mantén ese rango separado de la LAN superior y del rango del túnel VPN, porque las subredes solapadas convierten un problema de enrutamiento en un proyecto de traducción de direcciones. Un rango que se solapa con el túnel hace que el Pi sea un enrutador accidental entre dos prefijos idénticos. Escribe el rango y el conjunto en la configuración del punto de acceso en lugar de dejarlos a un valor predeterminado.

Si el modo compartido de NetworkManager es dueño del punto de acceso, inspecciona la conexión efectiva antes de añadir un servidor DHCP. El modo compartido arranca sus propios ayudantes y activa el reenvío, así que ya es el dueño del plan de direcciones de esa interfaz. Añadir un segundo servidor porque está disponible crea ofertas en competencia en lugar de redundancia.

Decide sobre IPv6 de forma deliberada. Los anuncios de enrutador y DHCPv6 provienen en muchos montajes de un ayudante distinto del de DHCPv4, y dejar IPv6 activo mientras la política de VPN solo cubre IPv4 da a los clientes un camino que evita el túnel. O planificas el lado IPv6 o lo desactivas en la interfaz del punto de acceso con una razón escrita.

Quién responde realmente en el puerto 53

Enumera cada proceso que escucha en el puerto 53 antes de cambiar una configuración. En un Pi que ejecuta un stub de resolutor local, Pi-hole y un ayudante de compartición, la lista de escuchas es el único mapa fiable de quién responde a las consultas:

sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip route

La guía de interfaces de Pi-hole explica que un modo de recepción limitado a una interfaz todavía puede usar un socket comodín y descartar las llegadas en otros lugares. Eso no es lo mismo que enlazar solo las interfaces seleccionadas, que es la disposición prevista cuando otro servicio DNS debe compartir la máquina.

Dos procesos normalmente no pueden enlazar la misma dirección y puerto, aunque SO_REUSEPORT puede hacer que un enlace compartido tenga éxito; aun así, un oyente comodín puede tomar llegadas destinadas al servicio más estrecho. Elige el modo documentado para el papel que quieres y reinicia los servicios en el orden previsto.

Mantén la página de administración de Pi-hole fuera de la red del punto de acceso. Los clientes necesitan un resolutor, no la interfaz web o la API que puede cambiar la configuración del resolutor.

Dos patas de DNS, una política para cada una

Una consulta del cliente viaja del teléfono al Pi, y una consulta separada viaja del Pi a su resolutor superior. Una regla de enrutamiento que coincide con el tráfico reenviado del punto de acceso no se aplica automáticamente a la segunda pata, porque el Pi genera ese tráfico localmente. Si la VPN debe transportar DNS, el camino local necesita su propia política.

Vigila los bucles. Apuntar el resolutor superior de Pi-hole a una dirección que sirve el propio Pi, directamente o mediante un reenvío de puerto, produce consultas que dan vueltas hasta que expiran. Dale un resolutor superior real o un reenviador condicional para los dominios que no puede responder.

Decide qué pasa cuando cae el túnel. Volver al resolutor local mantiene la navegación viva pero puede filtrar nombres fuera de la VPN; bloquear mantiene la política intacta y convierte la interrupción en un error visible. Cualquiera de las dos opciones es defendible, pero debe elegirse en lugar de heredarse de un valor predeterminado.

Demuestra el camino y el comportamiento en la interrupción

Prueba por capas: el cliente obtiene una dirección, el cliente resuelve un nombre a través del Pi, el Pi resuelve a través del resolutor superior previsto y una aplicación completa una petición. Un ping correcto no dice nada sobre DNS, y una consulta correcta no dice nada sobre el reenvío.

dig @192.168.70.1 example.com
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/
ip -4 route get 1.1.1.1

Luego detén el túnel y repite. El comportamiento previsto debería aparecer en unos segundos, no tras un reinicio manual de Pi-hole o del servicio del punto de acceso. Comprueba la configuración del resolutor del cliente durante la interrupción, porque un resolutor público secundario seguirá respondiendo incluso cuando la política esperaba un fallo.

Mantén un solo dueño para el reenvío y NAT y verifícalo desde un cliente, no desde el propio Pi. Una petición que sale del Pi con éxito todavía puede descartarse en el camino de vuelta, y el cliente es el único lugar donde todo el camino es visible.