Problema

Muchos entusiastas construyen su primer homelab combinando virtualización, routing y varios servicios sin una arquitectura clara. El resultado suele ser una red con VLANs mal aisladas, reglas de firewall inconsistentes y una gestión de credenciales que se vuelve difícil de auditar. Además, la transición a contenedores (Docker) y orquestadores (Kubernetes) se hace sin una base de pruebas adecuada, lo que genera cuellos de botella de hardware y problemas de seguridad que aparecen después de meses de operación.

Causa

  1. Segmentación insuficiente – Colocar la interfaz de gestión de Proxmox en la misma VLAN que los servicios expone la capa de administración a ataques internos y externos.
  2. Políticas de firewall implícitas – Un enfoque “allow‑all” en la primera fase lleva a que tráfico no deseado circule entre VLANs.
  3. Gestión de claves y secretos – Deploy keys con permisos de escritura o archivos .env con permisos laxos son vectores de escalada.
  4. Hardware subdimensionado para orquestación – Ejecutar Kubernetes directamente sobre el nodo de Proxmox sin reservar recursos provoca sobrecarga de CPU y memoria.
  5. Falta de monitoreo y logging centralizado – Sin un punto único de observabilidad, los fallos de red o de contenedores pasan desapercibidos hasta que impactan el servicio.
  6. Configuración de DNS parcial – Usar un único resolver (AdGuard Home) sin fallback y sin validar respuestas DNSSEC puede romper la resolución cuando el servicio se cae.

Solución

1. Arquitectura de red con aislamiento por función

  • VLAN de gestión (MGMT): solo acceso a Proxmox, OPNsense GUI y herramientas de administración. No permite tráfico saliente a puertos distintos de 22/443.
  • VLAN de servicios (SVCS): alberga contenedores y VMs que ofrecen APIs, webs, etc. Permite salida a Internet únicamente por puertos necesarios (80/443).
  • VLAN de automatización (AUTO): máquinas que ejecutan scripts, CI/CD, agentes de monitoreo. Bloquea todo el tráfico entrante; solo salida a SVCS y MGMT según ACLs.
  • VLAN de IoT y LAN: manténlas totalmente separadas; usa reglas de “allow‑only‑required” en OPNsense.

2. Políticas de firewall de “default‑deny”

En OPNsense configura la regla base Block all en cada interfaz y añade excepciones explícitas. Un ejemplo típico:

# OPNsense UI > Firewall > Rules > MGMT
# Permitir SSH y HTTPS desde la LAN a la interfaz MGMT
# (Regla de ejemplo en formato pfSense/OPNsense)
pass in quick on em1 proto tcp from 10.0.10.0/24 to any port {22,443} keep state

3. Gestión de credenciales

  • Usa deploy keys de solo lectura por repositorio y restringe su uso a la IP de la VLAN de servicios.
  • Aplica chmod 600 a todos los archivos de configuración sensibles y almacénalos en un vault ligero (e.g., pass o sops).
  • Habilita 2FA con aplicaciones de código abierto como Aegis o andOTP para iOS/Android.

4. Ruta de aprendizaje Docker → K3s

  1. Docker Compose: crea un docker-compose.yml para cada servicio (AdGuard, Nginx, etc.). Mantén los volúmenes en discos SSD dedicados para evitar I/O contention.
  2. Validación de recursos: usa docker stats y htop para medir consumo; si la carga supera el 70 % de CPU o RAM, planifica migrar a K3s.
  3. K3s en VM dedicada: reserva al menos 2 vCPU y 4 GB RAM en Proxmox para la VM que ejecutará K3s. Instala k3s con --disable=traefik si ya tienes un Ingress propio.
  4. Helm charts: aprovecha los charts oficiales para Jellyfin, Home Assistant y otras apps. Mantén los charts en un repositorio privado y usa helm upgrade --install.

5. Monitoreo y logging centralizado

  • Prometheus + node_exporter en cada host (Proxmox, OPNsense VM, AUTO VM).
  • Grafana en la VLAN de servicios para dashboards de uso de CPU, latencia de red y estado de contenedores.
  • Loki como backend de logs; configura systemd-journald para reenviar logs de OPNsense y Proxmox.

6. Redundancia de DNS

Mantén un segundo resolvedor (por ejemplo, Unbound en una VM) que reenvíe a Quad9 y Cloudflare. Configura forward-zone con forward-first para que, si AdGuard falla, el fallback tome el control sin interrupciones.

Cuándo aplicar esta solución

  • Escenarios de homelab con múltiples VLANs y al menos una capa de routing virtualizada (OPNsense, pfSense).
  • Necesidad de acceso remoto seguro mediante Tailscale o VPN; la solución de ACLs en Tailscale se vuelve trivial cuando las VLAN están bien definidas.
  • Plan de crecimiento que incluya contenedores y orquestación; la separación de recursos evita que Docker y K3s compitan por CPU/memoria.
  • Entornos donde la seguridad es prioridad (exposición de servicios a internet, datos personales, etc.).

No es necesario si el homelab es monolítico (una sola LAN sin segmentación) y no se planea escalar a Kubernetes; en ese caso, una configuración mínima de firewall puede ser suficiente.

Código

# Docker Compose básico para AdGuard Home en la VLAN MGMT
cat > docker-compose.yml <<'EOF'
version: "3.8"
services:
  adguard:
    image: adguard/adguardhome
    container_name: adguard
    restart: unless-stopped
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "80:80/tcp"
      - "443:443/tcp"
    volumes:
      - ./adguard/work:/opt/adguardhome/work
      - ./adguard/conf:/opt/adguardhome/conf
    networks:
      mgmt:
        ipv4_address: 10.0.10.10
networks:
  mgmt:
    driver: bridge
    ipam:
      config:
        - subnet: 10.0.10.0/24
EOF
docker compose up -d

Verificación

  1. Ping interno: desde una VM en la VLAN AUTO, ejecuta ping -c 3 10.0.10.10. La respuesta solo debe llegar si la regla de firewall lo permite.
  2. Registros de OPNsense: revisa Firewall > Log Files y confirma que los paquetes de la VLAN AUTO a MGMT aparecen como “pass”.
  3. Estado de Docker: docker compose ps debe mostrar el contenedor adguard en Running.
  4. Prometheus targets: abre Grafana → Status > Targets y verifica que node_exporter y k3s aparecen sin errores.
  5. Tailscale ACL: en la consola de Tailscale, revisa que los subnets anunciados coinciden con los rangos de VLAN y que los dispositivos remotos pueden resolver nombres internos.

Notas adicionales

  • IPv6: habilitar IPv6 solo en VLAN que lo requieran evita sorpresas de tráfico inesperado.
  • Backups: programa snapshots de Proxmox y exporta configuraciones de OPNsense (config.xml) a un repositorio cifrado.
  • Actualizaciones: prueba siempre en una VM de pruebas antes de aplicar cambios de versión a OPNsense o Proxmox.
  • Documentación viva: mantén el diagrama de topología en un repositorio Git y usa GitHub Pages para que cualquier cambio quede versionado.
  • Hardware futuro: si planeas escalar a varios nodos K3s, considera servidores con al menos 8 vCPU y 32 GB RAM, y discos NVMe para almacenamiento de contenedores.

Con una red segmentada, políticas de firewall estrictas y una ruta de aprendizaje estructurada, el homelab pasa de ser un experimento frágil a una plataforma fiable para pruebas, automatización y consumo de medios.