¿Pi hole en LXC o en una VM sobre Proxmox?
Pi hole necesita muy poca potencia de proceso, memoria y almacenamiento, lo que lo convierte en un servicio fácil de alojar en Proxmox. La decisión principal es si instalarlo dentro de un contenedor LXC o en una máquina virtual completa.
Las dos opciones pueden ofrecer filtrado DNS para toda la red, resolución de dominios locales y servicios DHCP. Un contenedor LXC consume menos recursos y es más fácil de desplegar para un servicio pequeño y dedicado, mientras que una máquina virtual te da un aislamiento más fuerte y un kernel de sistema operativo propio.
Para la mayoría de los homelabs y redes de pequeñas empresas, un contenedor LXC de Debian sin privilegios es la mejor opción. Una máquina virtual resulta más atractiva cuando el DNS forma parte de un diseño de seguridad más estricto, cuando el equipo quiere gestionar servidores virtuales de la forma convencional o cuando Pi hole va a convivir con otros servicios de red.
¿Qué necesita Pi hole?
Pi hole es ligero. Su documentación oficial indica como requisitos básicos 512 MB de memoria, al menos 2 GB de almacenamiento libre y un sistema operativo compatible. Entre los sistemas compatibles están las versiones con mantenimiento activo de Debian, Ubuntu, Alpine, Fedora y otras distribuciones Linux. Pi hole también necesita una dirección IP estática o una reserva DHCP fiable.
Estos requisitos caben de sobra en un invitado pequeño de Proxmox. Una instalación básica rara vez necesita varios núcleos de procesador o un disco virtual grande.
Importan más la disponibilidad de red y la previsibilidad. Pi hole tiene que escuchar peticiones DNS en el puerto 53 TCP y UDP, y su dirección no debería cambiar, porque los routers y los dispositivos cliente dependen de ella para resolver nombres.
Cuando Pi hole pasa a ser el servidor DNS principal, una caída puede hacer que parezca que internet no funciona aunque el router y la conexión sigan en marcha. Diseña el despliegue pensando primero en la fiabilidad y después en la eficiencia de recursos.
¿Cómo funciona Pi hole en LXC?
Proxmox usa LXC para crear contenedores de sistema. Un contenedor LXC tiene su propio sistema de archivos, procesos, usuarios, configuración de red y límites de recursos, pero comparte el kernel Linux del host de Proxmox.
Eso hace que LXC sea más ligero que una máquina virtual. El contenedor de Pi hole no necesita reservar memoria para otro kernel ni emular un conjunto completo de hardware virtual.
Un despliegue típico usa un contenedor Debian sin privilegios con un procesador virtual, de 512 MB a 1 GB de memoria y un disco virtual pequeño. El contenedor recibe una dirección IP estática y se conecta a la misma red de confianza que los clientes que lo usan como DNS.
Pi hole es compatible oficialmente con Debian, así que puedes instalar la aplicación directamente sin Docker. El proyecto ofrece un instalador automático y también métodos que permiten a los administradores descargar y revisar el script de instalación antes de ejecutarlo.
Una instalación nativa mantiene la arquitectura sencilla: Proxmox gestiona el invitado LXC, Debian gestiona los paquetes del sistema operativo y Pi hole gestiona el filtrado DNS.
¿Qué ventajas tiene LXC?
La mayor ventaja es el bajo consumo de recursos. Como el contenedor comparte el kernel de Proxmox, arranca rápido y consume menos memoria que una máquina virtual completa, algo que se agradece en servidores pequeños donde la memoria se reparte entre varios servicios de infraestructura.
LXC también encaja bien en la gestión de Proxmox. Los administradores pueden iniciar, detener, clonar y hacer copia de seguridad del contenedor de Pi hole desde la misma interfaz que usan para los demás invitados.
Los contenedores sin privilegios mejoran el modelo de seguridad porque asignan el root del contenedor a una identidad sin privilegios en el host de Proxmox. Proxmox explica que así el efecto de muchos problemas de seguridad de los contenedores queda limitado a un usuario sin privilegios del host. El modo sin privilegios es además el predeterminado para los contenedores nuevos.
Pi hole no suele necesitar acceso privilegiado, passthrough de hardware ni funciones complicadas del kernel, así que encaja bien en un contenedor sin privilegios.
¿Qué limitaciones tiene LXC?
LXC comparte el kernel del host de Proxmox, así que ofrece menos aislamiento que una máquina virtual completa. Una vulnerabilidad grave del kernel podría afectar tanto al contenedor como al host. Los contenedores sin privilegios, los namespaces, AppArmor y otras protecciones limitan ese riesgo, pero la frontera del kernel sigue siendo compartida.
Los cambios en el kernel del host de Proxmox o en el entorno LXC también pueden afectar al contenedor. Es poco probable que Pi hole necesite funciones del kernel poco habituales, así que normalmente es una preocupación operativa menor.
Los montajes de almacenamiento requieren atención. Proxmox puede montar directorios del host dentro de un contenedor LXC, pero el contenido de los puntos de montaje bind no se incluye en las copias de seguridad normales de vzdump.
Pi hole guarda normalmente su configuración importante y su base de datos dentro del sistema de archivos del contenedor, así que los montajes bind externos no suelen hacer falta. Mantener los datos de la aplicación en el disco raíz gestionado del LXC hace que el comportamiento de las copias de seguridad sea más fácil de entender.
¿Cómo funciona Pi hole en una VM?
Una máquina virtual de Proxmox usa QEMU y KVM para ofrecer un equipo virtual completo. El invitado ejecuta su propio kernel Linux y gestiona su propio hardware virtual.
Una VM de Pi hole puede ejecutar Debian o Ubuntu y seguir el mismo proceso de instalación nativa que un servidor Linux físico. La arquitectura es convencional y bien conocida: Proxmox gestiona la máquina virtual, Debian o Ubuntu gestiona el sistema operativo invitado y Pi hole se encarga del filtrado DNS.
La VM necesita más memoria y almacenamiento que LXC, aunque Pi hole sigue siendo ligero. Una VM Linux pequeña con 1 GB de memoria y un disco virtual modesto suele bastar para la aplicación.
¿Qué ventajas tiene una VM?
La principal ventaja es un aislamiento más fuerte. La máquina virtual tiene su propio kernel, lo que traza una frontera de seguridad más clara entre Pi hole y el host de Proxmox. Es menos probable que un problema dentro del invitado afecte directamente al hipervisor.
Una VM también es más cómoda para los administradores acostumbrados a gestionar servidores Linux corrientes. La documentación estándar del sistema operativo se aplica tal cual, sin tener que pensar en asignaciones de usuarios de LXC, kernels compartidos ni restricciones propias de los contenedores.
Puedes mover la VM a otra plataforma de virtualización compatible con más facilidad, porque el invitado es un servidor virtual convencional y no un contenedor de sistema muy ligado a la tecnología de contenedores de Linux.
Una máquina virtual también puede ser preferible cuando Pi hole comparte invitado con Unbound, agentes de monitoreo, un servicio VPN u otras aplicaciones de red. Sigue sin ser buena idea combinar demasiados servicios, pero una VM te da un entorno más independiente cuando varias herramientas relacionadas tienen que funcionar juntas.
¿Qué es más fácil de respaldar?
Proxmox puede crear copias de seguridad coherentes de contenedores LXC y máquinas virtuales KVM en ejecución. Su proceso de backup incluye la configuración del invitado y los datos gestionados.
La copia de seguridad de una VM es sencilla porque los discos virtuales del invitado se incluyen normalmente como dispositivos de bloque completos. La de un LXC también es fiable cuando los datos de Pi hole se quedan dentro del sistema de archivos gestionado del contenedor. Los problemas aparecen sobre todo cuando se han colocado datos importantes en montajes bind excluidos.
Pi hole usa bases de datos SQLite para el historial de consultas y la gestión de dominios. Su documentación ofrece un método de copia en línea de SQLite que puede copiar la base de datos de consultas mientras el servicio DNS sigue funcionando.
La estrategia más segura combina las copias de seguridad de Proxmox con copias a nivel de aplicación de la configuración y la base de datos de Pi hole. Guarda al menos una copia fuera del host de Proxmox, porque una copia que solo vive en el mismo servidor no te protege de un fallo del servidor o del almacenamiento.
¿Qué es más fácil de actualizar?
Una instalación nativa de Pi hole se actualiza con el comando de actualización del proyecto. Pi hole aconseja a los administradores leer las notas de la versión antes de actualizar, sobre todo en los cambios de versión mayor.
El proceso es prácticamente el mismo en LXC y en una VM. La diferencia está en la frontera del sistema operativo: un invitado LXC sigue usando el kernel del host de Proxmox, mientras que una VM mantiene su propio kernel invitado y puede seguir un calendario de actualizaciones independiente. Para Pi hole, esto rara vez importa mucho en la práctica, porque la aplicación no suele depender de capacidades del kernel poco habituales.
Antes de una actualización importante de Pi hole, crea una copia de seguridad en Proxmox y confirma que hay un segundo resolvedor DNS disponible. Así, una actualización fallida no interrumpirá la resolución de nombres en toda la red.
¿Debería Pi hole encargarse del DHCP?
Pi hole incluye un servidor DHCP para redes en las que el router no puede repartir una dirección DNS personalizada. Pi hole advierte que hay que desactivar el servidor DHCP del router antes de activar el DHCP de Pi hole, porque dos servidores DHCP compitiendo pueden entregar configuraciones de red contradictorias.
Tanto un LXC como una VM pueden ofrecer DHCP. El invitado tiene que estar conectado directamente a la red de los clientes, porque DHCP depende de tráfico de difusión que normalmente no atraviesa los routers.
Cuando Pi hole ofrece a la vez DNS y DHCP, su disponibilidad importa todavía más. Un fallo puede impedir que los dispositivos nuevos reciban dirección y, además, que los existentes resuelvan nombres de dominio.
En redes complejas con varias VLAN, puede ser mejor poner el DHCP en OPNsense, en otro firewall o en una plataforma de red dedicada, y dejar que Pi hole se concentre en el filtrado DNS.
¿Necesitas dos instancias de Pi hole?
Una red de producción no debería depender de un único invitado DNS. Una segunda instancia de Pi hole permite que los clientes sigan resolviendo dominios cuando el primer invitado o el host de Proxmox no están disponibles. Lo ideal es que funcione en otro nodo de Proxmox, en un dispositivo físico o en otro servidor.
Dos contenedores de Pi hole en el mismo host de Proxmox te protegen de un fallo de la aplicación, pero no sirven de nada ante un fallo del host, del almacenamiento o de la alimentación.
Las dos instancias necesitan reglas de filtrado y registros DNS locales coherentes. Puedes conseguirlo con configuración documentada, automatización o herramientas de sincronización bien controladas.
No uses un resolvedor público como dirección DNS secundaria si todas las peticiones de los clientes tienen que pasar por Pi hole. Muchos sistemas cliente no tratan el segundo servidor DNS como un respaldo pasivo y pueden enviar peticiones a cualquiera de las dos direcciones.
¿Qué elegir, LXC o una VM?
Elige LXC cuando quieras el despliegue más pequeño y sencillo en Proxmox. Pi hole encaja con naturalidad en un contenedor Debian sin privilegios y necesita muy pocos recursos.
Elige una VM cuando el aislamiento más fuerte, la gestión convencional de servidores y la portabilidad importen más que la eficiencia. Una VM también es razonable cuando la política de la organización exige que los servicios de seguridad se ejecuten con un kernel propio.
Para la mayoría de los homelabs y redes pequeñas con Proxmox, LXC es la mejor opción, porque Pi hole no necesita una máquina virtual completa para filtrar bien el DNS. Elijas lo que elijas, la red también necesita una dirección estática, copias de seguridad probadas, un servidor DNS secundario y un camino de recuperación que siga funcionando cuando el host principal de Proxmox no esté disponible, y eso pesa más que el tipo de invitado.