Problema

Muchos entusiastas de homelab reciben equipos de segunda mano con generaciones y arquitecturas distintas: servidores Dell R330, R610, discos SAS, y puntos de acceso Cisco. El reto consiste en convertir ese hardware heterogéneo en una plataforma unificada que ofrezca enrutamiento fiable, almacenamiento resiliente y conectividad Wi‑Fi gestionada, sin incurrir en licencias costosas ni depender de soluciones propietarias. El patrón típico es: integrar servidores antiguos bajo un hipervisor ligero, exponer servicios críticos mediante VLAN y NFS, y mantener la red Wi‑Fi independiente del controlador original. Cuando la arquitectura no está planificada, aparecen cuellos de botella en I/O, conflictos de VLAN y falta de redundancia en los discos.

Causa

  1. Hardware mixto sin planificación de roles – Usar un servidor antiguo para tareas que requieren alta I/O (por ejemplo, bases de datos) genera latencia.
  2. Almacenamiento sin nivel de redundancia – Discos SAS de segunda mano pueden fallar; sin RAIDZ2 o espejo, la pérdida de datos es inevitable.
  3. Controlador de APs acoplado a Cisco DNA – Los APs 1702i vienen con firmware “lightweight” que obliga a un controlador externo, limitando la flexibilidad.
  4. Falta de segmentación de red – Sin VLAN, el tráfico de IoT y de invitados comparte la misma subred, lo que complica la seguridad y el monitoreo.
  5. Gestión remota limitada – No habilitar iDRAC o IPMI impide el acceso al hardware cuando el nodo falla.

Solución

1. Definir roles de servidor

  • Servidor de enrutamiento y servicios ligeros (ej. Dell R330). Instalar Proxmox VE y crear una VM de OPNsense que gestione routing, firewall y VLAN. Mantener los contenedores ligeros (AdGuard, Caddy) como LXC para reducir overhead.
  • Servidor de almacenamiento y carga de trabajo (ej. Dell R610). Proxmox en modo “bare metal” con una unidad dedicada al boot de Proxmox y el resto de discos pasados directamente a una VM de TrueNAS. Los LXCs que consumen datos (Home Assistant, Nextcloud) se ejecutan aquí y acceden vía NFS.

2. Configurar Proxmox y TrueNAS

  1. Instalación de Proxmox – Utilizar la ISO oficial, crear un ZFS pool rpool en el disco de arranque para aprovechar snapshots.
  2. Passthrough de discos – En el R610, marcar los cinco discos SAS como “Unused Disk” y asignarlos a la VM de TrueNAS con el parámetro scsi0: /dev/disk/by-id/....
  3. Crear RAIDZ2 – Dentro de TrueNAS, crear un pool tank con los cinco discos en modo RAIDZ2. Esto brinda tolerancia a fallos de dos discos y aproximadamente 3.6 TB de espacio útil.
  4. Exponer NFS – Crear datasets dedicados (/mnt/tank/homeassistant, /mnt/tank/nextcloud) y habilitar NFS con maproot=user.

3. Desplegar OPNsense y VLAN

  1. VM de OPNsense – Asignar dos interfaces virtuales: WAN (conexión a ISP) y LAN (conmutador interno).
  2. Crear VLANs – En la interfaz LAN, definir:
    • VLAN 10 → main (red doméstica)
    • VLAN 20 → iot (dispositivos IoT)
    • VLAN 30 → guest (invitados)
  3. Asignar DHCP por VLAN y aplicar reglas de firewall que aíslen iot y guest del main.
  4. WireGuard – Configurar un túnel a ProtonVPN para tráfico saliente sensible.

4. Convertir APs Cisco a modo autónomo

  • Descargar la versión “autonomous” de Cisco AIR‑CAP1702i.
  • Flashar cada AP con TFTP: 
    tftp 192.168.1.10 PUT flash:/c1702i-universalk9-mz.152-4.JB6.bin
  • Configurar SSID único, habilitar 802.11r y asignar VLAN 10. El cuarto AP se alimenta con un inyector POE externo para no consumir el presupuesto del switch.

5. Orquestar servicios con Ansible (opcional)

Crear playbooks que:

  • Instalen paquetes LXC.
  • Monten los puntos NFS.
  • Configuren certificados en Caddy. Esto permite reproducir el entorno en caso de un desastre.

Cuándo aplicar esta solución

  • Entorno mixto de servidores Dell (R330, R610, R710) con capacidad de virtualización y suficiente RAM.
  • Necesidad de separar tráfico (IoT, invitados) sin comprar hardware de firewall dedicado.
  • Disponibilidad de APs Cisco que pueden operar en modo autónomo.
  • Presupuesto limitado: se prioriza software libre (Proxmox, OPNsense, TrueNAS) y reutiliza discos de segunda mano.

No es adecuada cuando:

  • Se requiere alta disponibilidad de nivel empresarial (clustering de OPNsense, replicación de TrueNAS).
  • Los discos no pasan pruebas SMART o provienen de fuentes no confiables.
  • El hardware no soporta VT‑d/AMD‑V para passthrough.

Código

# Proxmox: crear ZFS pool en el disco de arranque (ejemplo /dev/sda)
zpool create -f rpool /dev/disk/by-id/ata-XXXX

# TrueNAS: crear pool RAIDZ2 (ejemplo dentro de la VM)
zpool create tank raidz2 /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf

# OPNsense: crear VLAN 10 en la interfaz LAN (CLI)
ifconfig em0 vlan 10 vlandev em0

Verificación

  1. Ping entre VLAN – Desde una máquina en main ping a 192.168.20.1 (gateway de iot). Debería fallar si el firewall está activo.
  2. Montaje NFS – En el R610, ejecutar showmount -e 192.168.10.2 (IP de TrueNAS) y montar un dataset: 
    mount -t nfs 192.168.10.2:/mnt/tank/nextcloud /mnt/nextcloud
  3. Roaming Wi‑Fi – Conectar un cliente, caminar de una zona a otra y observar que la IP no cambia y la reconexión es <1 s (802.11r).
  4. Respaldo Proxmox – Ejecutar pve-backup-client backup <VMID> y confirmar que el archivo aparece en el dataset de backup en TrueNAS.

Notas adicionales

  • SMART antes de usar: ejecuta smartctl -a /dev/sdX y rechaza cualquier disco con atributos reallocated sector > 0.
  • iDRAC firmware: mantén la versión más reciente para evitar problemas de KVM sobre IP.
  • Ajuste de POE: verifica que el inyector TP‑Link entrega 802.3af (15.4 W) suficiente para el AP; de lo contrario, la señal puede degradarse.
  • Backblaze B2: usa la herramienta rclone para replicar snapshots de TrueNAS a la nube, garantizando una copia fuera del sitio.
  • Actualizaciones de OPNsense: prueba en una VM de prueba antes de aplicar al entorno productivo; los cambios de firewall pueden romper la conectividad si no se revisan las reglas.