Pi-hole y VPN en un solo Pi: ¿sigue teniendo soporte el sistema operativo?

En una caja combinada de Pi-hole y VPN se mezclan dos cosas: la familia de distribución que instaló y la versión más la arquitectura que los componentes admiten en realidad. Una placa que arranca una imagen demuestra que el núcleo funciona; no demuestra que el binario FTL de Pi-hole y su instalador de VPN apunten al mismo espacio de usuario. La prueba real es una superposición cuádruple de soporte de placa, rama de versión, arquitectura de paquetes y una ruta de actualización que usted mismo pueda manejar. Pierda cualquiera de esas cuatro patas y el aparato funciona esta semana, para dejarle tirado en la siguiente actualización de seguridad.

La rama de versión fija el soporte, no el nombre de la familia

Pregunte contra qué versión sigue probando el proyecto y escriba la respuesta como una cadena de versión, no como Debian. La página de requisitos de Pi-hole enumera los sistemas operativos admitidos y las arquitecturas FTL precompiladas como dos requisitos separados, limita el soporte a las versiones que la propia distribución aún mantiene y advierte de que las variantes o configuraciones inusuales pueden fallar incluso dentro de la lista admitida. Esa formulación importa: una familia admitida no cubre a todos sus miembros.

Una imagen antigua que todavía arranca en su Pi no es prueba de soporte. La placa está bien, el índice de paquetes está obsoleto, y la discrepancia aparece más tarde, cuando un instalador arrastra una dependencia que la versión ya no puede satisfacer.

El lado de la VPN tiene más piezas, cada una con su propia ventana: el demonio del túnel, el asistente de instalación que escribe su configuración, la aplicación cliente del proveedor y el paquete de integración de la distribución son cuatro proyectos separados. Un instalador que reconoce su distribución y un instalador que produce un servicio que la versión puede mantener en marcha son afirmaciones distintas. Consulte la lista de plataformas propia del demonio y luego si el asistente que piensa ejecutar se ha tocado desde que salió esa versión. Cuando un proyecto declara soporte solo hasta una versión concreta, trate la siguiente como no probada hasta que la haya arrancado usted.

Haga coincidir el objetivo binario con el espacio de usuario que tiene

La arquitectura es el fallo más silencioso. Un núcleo de 64 bits con un espacio de usuario de 32 bits es una combinación real y admitida en varias placas, y ejecuta un binario FTL de 32 bits sin quejarse, justo hasta el momento en que instala algo publicado solo para arm64. Imprima ambas mitades antes de elegir una imagen y guarde la salida junto a sus notas.

uname -m
dpkg --print-architecture
grep -E '^(PRETTY_NAME|VERSION_ID)=' /etc/os-release
apt-cache policy pihole-ftl

Si esas dos líneas de arquitectura no coinciden, está en una configuración mixta: viable para Pi-hole solo, frágil en cuanto un segundo servicio quiere bibliotecas nativas. Volver a flashear una imagen limpia de 64 bits suele ser más rápido que reconstruir la cadena de herramientas que produjo la discrepancia.

El marketing de la placa tampoco lo resuelve. El tamaño de la memoria y el modelo de CPU no dicen nada sobre contra qué libc enlazan sus paquetes, así que decida por los valores impresos, nunca por la página del producto.

Una caja, dos servicios, un dueño de la red

Decida quién posee el direccionamiento, el resolutor y el túnel antes de que entre el primer paquete, porque de lo contrario dos servicios acabarán reclamando el mismo deber y ninguno ganará limpio. Dé al Pi una dirección estática fuera del grupo DHCP que reparte su router y mantenga el túnel en su propia subred: 192.168.50.10 para el Pi y 10.42.0.0/24 para el túnel es una división viable, y los números en sí son arbitrarios mientras no choquen con lo que su router ya sirve. Luego anote qué componente responde en el puerto 53, cuál reparte DHCP si lo usa y cuál posee la ruta predeterminada mientras el túnel está activo. En una imagen sin entorno gráfico, esa última tarea pertenece a NetworkManager o systemd-networkd, y instalar un cliente de proveedor que también reescribe la configuración del resolutor es como la gente acaba con un túnel vivo y un DNS muerto.

Compartir la caja está bien. Compartir un rol no. Pi-hole quiere ser el único oyente en el puerto 53, y el demonio VPN quiere empujar su propia configuración de DNS a los clientes, así que elija en cuál de los dos deben confiar los clientes y configure el otro para que no estorbe.

Mantenga la ruta de administración fuera del túnel cuando pueda. Si el resolutor y el túnel fallan juntos, usted sigue queriendo SSH accesible en la dirección LAN, y eso significa que el servicio de gestión no debe depender de ninguno de los dos.

Haga de la próxima actualización parte de la elección

Una versión que no puede actualizar es un techo de soporte que ya ha aceptado. Pruebe la mecánica de actualización en una tarjeta de repuesto antes de que el aparato lleve el DNS de su hogar, y lea lo que dicen los proyectos sobre saltar entre ramas en lugar de suponer que basta con actualizar un paquete.

sudo apt update
apt-mark showhold
sudo apt full-upgrade
pihole -up

Los paquetes retenidos son la razón habitual de que una actualización parezca exitosa y no cambie nada. Libere las retenciones a propósito, una a una, y anote qué servicio necesitaba la fijación.

Antes del salto, exporte la configuración de Pi-hole, las concesiones estáticas y cualquier perfil de túnel, y confirme que puede restaurarlos en una imagen nueva. Después del salto, pruebe el DNS normal de los clientes, el recurso privado detrás del túnel, una reconexión y cualquier regla de reenvío en la puerta de enlace. Una caja que arranca y responde a ping no ha superado casi nada.

Cuando ninguna versión única encaja con los dos servicios

A veces la superposición está vacía: el asistente de VPN ha pasado a una versión más nueva que el paquete de Pi-hole que puede instalar, o la imagen del fabricante de la placa va por detrás de ambas. En ese caso separe los roles en lugar de editar metadatos de versión para satisfacer a un instalador. Dos dispositivos pequeños, o un dispositivo más un contenedor para el segundo servicio, cuestan menos que un aparato cuya historia de soporte depende de una mentira.

Falsificar la versión es el único atajo que conviene rechazar de plano. Los gestores de paquetes confían en lo que dice el archivo de versión, así que un identificador falsificado le da una instalación que ninguno de los dos proyectos le ayudará a depurar.

Si dos versiones actuales lo satisfacen todo, elija la que pueda seguir sus notas de actualización sin adivinar, y deje de buscar. Luego registre la versión, la arquitectura, los dueños de los servicios y el paso de restauración en un solo lugar, porque la siguiente persona que toque la tarjeta SD necesitará las cuatro cosas.