Problema

Los entusiastas de homelab suelen combinar servidores, contenedores y máquinas virtuales bajo una única red física. Cuando la cantidad de servicios crece (AD, VOIP, bases de datos, proxies, etc.) la topología se vuelve difícil de gestionar: múltiples VLAN, servidores DNS internos y externos, y reglas de firewall que cambian constantemente. El síntoma típico es una caída intermitente de resolución DNS, tráfico bloqueado inesperado o dificultades al añadir nuevas máquinas. En entornos donde la disponibilidad de los servicios internos es tan crítica como la exposición pública, la falta de una arquitectura de red y de automatización coherente genera tiempo de inactividad y sobrecarga operativa.

Causa

  1. Diseño de VLAN ad‑hoc – Crear VLAN sin un esquema de numeración y sin documentar los flujos de tráfico lleva a reglas de firewall superpuestas y a puentes innecesarios.
  2. DNS sin redundancia – Ejecutar solo Pi‑Hole o Technitium en una única instancia hace que cualquier caída del proceso o del host provoque fallos de resolución en toda la red.
  3. Provisionamiento manual – Copiar imágenes de VM y modificar configuraciones a mano genera “drift” entre entornos y dificulta la replicación de cambios.
  4. Monitorización fragmentada – Herramientas aisladas (CheckMK, Wazuh, scripts propios) sin correlación centralizada hacen que la causa raíz se pierda entre alertas.
  5. Hardware heterogéneo sin planificación de capacidad – Mezclar servidores DDR3 y DDR4, diferentes tipos de storage y enlaces de 1 GbE con planes de 10 GbE sin pruebas de carga crea cuellos de botella que aparecen solo bajo carga real.

Solución

Adoptar una arquitectura modular basada en tres pilares: segmentación de red planificada, DNS redundante con failover automático y aprovisionamiento declarativo.

1. Segmentación de red con numeración lógica

Define un rango de VLAN que refleje la función, no el número de equipos. Por ejemplo: 10‑20 para infraestructura, 30‑40 para usuarios, 50‑60 para servicios externos, 70‑80 para laboratorio. Usa un switch de capa 3 (o un router con capacidades de routing entre VLAN) para interconectar solo los flujos necesarios. Documenta cada regla de firewall con comentarios que indiquen origen, destino y puerto.

2. DNS con pares maestros‑esclavo y health‑check

Despliega al menos dos instancias de Technitium (o CoreDNS) en modo maestro‑esclavo y dos Pi‑Hole como caché delante de ellas. Configura forward a los pares maestros y habilita healthcheck mediante un script que verifique la respuesta a consultas críticas (nslookup google.com). Cuando una instancia falla, el script actualiza la tabla de resolvers en los clientes mediante DHCP o Ansible.

3. Aprovisionamiento con Ansible y golden images

Mantén una única imagen base (golden) para Debian/Ubuntu con usuario ansible y claves SSH. Usa playbooks para instalar paquetes, aplicar políticas de seguridad y registrar los hosts en el inventario dinámico. Cada nuevo VM o LXC se crea a partir de la imagen y se registra automáticamente con ansible-inventory.

4. Monitorización centralizada

Integra CheckMK y Wazuh en un único dashboard (Grafana + Loki) y exporta métricas de DNS monitor a Prometheus. Configura alertas basadas en umbrales de latencia DNS y en cambios de estado de las interfaces VLAN.

5. Plan de capacidad y pruebas de estrés

Antes de añadir enlaces de 10 GbE, ejecuta iperf3 entre los nodos críticos y registra throughput y jitter. Ajusta la configuración de LACP en los switches y verifica que el balanceo de carga sigue la política de hash de origen/destino.

Cuándo aplicar esta solución

  • Síntomas de DNS intermitente: consultas que fallan solo en ciertos dispositivos o VLAN.
  • Reglas de firewall confusas: cuando el equipo de soporte pasa más tiempo leyendo listas de ACL que resolviendo incidentes.
  • Crecimiento de servicios: al superar 20‑30 VMs o contenedores y la gestión manual se vuelve impráctica.
  • Planificación de expansión de red: antes de introducir enlaces de 10 GbE o migrar a un nuevo rack.

No es necesario si la infraestructura consta de menos de cinco máquinas y una sola VLAN; la complejidad añadida superaría el beneficio.

Código

# Inventario estático de Ansible con grupos por VLAN
[vlans:children]
vlan10_infra
vlan30_user
vlan50_public

[vlan10_infra]
proxmox01 ansible_host=10.0.10.10
dh1 ansible_host=10.0.10.20

[vlan30_user]
desktop01 ansible_host=10.0.30.10
laptop01 ansible_host=10.0.30.11

[vlan50_public]
pubwsrv1 ansible_host=203.0.113.10
pubwprx1 ansible_host=203.0.113.11

# Playbook para asegurar que todos los hosts usan los mismos resolvers DNS
- hosts: all
  become: true
  tasks:
    - name: Configurar resolv.conf con los pares de DNS internos
      lineinfile:
        path: /etc/resolv.conf
        regexp: '^nameserver'
        line: "nameserver {{ dns_primary }}\nnameserver {{ dns_secondary }}"
      vars:
        dns_primary: 10.0.10.101   # Technitium master
        dns_secondary: 10.0.10.102 # Technitium slave

Verificación

  1. Ejecuta dig @10.0.10.101 example.com desde una máquina en cada VLAN; la respuesta debe ser idéntica y sin timeout.
  2. En el dashboard de Grafana verifica que la métrica dns_query_latency_seconds está por debajo de 0.05 s para todas las zonas.
  3. Usa ansible -m ping all para confirmar que el inventario está actualizado y que los hosts responden.
  4. Simula la caída de una instancia DNS (systemctl stop technitium) y comprueba que los clientes cambian automáticamente al segundo resolutor sin perder conectividad.

Notas adicionales

  • Mantén los archivos de configuración de firewall en un repositorio Git; cualquier cambio debe pasar por revisión de código.
  • Cuando añadas un nuevo VLAN, actualiza tanto la tabla de rutas del router como el ansible_inventory antes de lanzar cualquier playbook.
  • Los scripts de health‑check para DNS pueden enviarse a un webhook de Slack o Discord; evita el spam de email configurando un umbral de alerta (p.ej., 3 fallos consecutivos).
  • Si utilizas contenedores para servicios críticos (SQL, Redis), considera desplegarlos en modo statefulset dentro de Kubernetes para obtener auto‑healing y persistencia de datos.
  • Revisa periódicamente los logs de wazuh en busca de “DNS server down” o “firewall deny” para detectar patrones antes de que se conviertan en incidentes mayores.