Problema

Muchos profesionales en transición hacia IT o Security carecen de acceso a entornos reales. La única forma de demostrar competencias a reclutadores es a través de laboratorios caseros que reproduzcan una infraestructura de red, virtualización y monitoreo. El reto consiste en armar un entorno completo (router, VLAN, SIEM, monitoring, honeypot, ticketing) con un presupuesto limitado y sin depender de hardware de última generación. Además, el laboratorio debe ser lo suficientemente modular para añadir o remover componentes sin romper la arquitectura.

Causa

Los fallos más habituales en este tipo de setups provienen de tres áreas:

  1. Diseño de red fragmentado – VLANs sin trunk coherente, switches no gestionados que no replican etiquetas 802.1Q, o routers caseros que pierden paquetes de gestión.
  2. Virtualización inconsistente – mezcla de hipervisores (Proxmox, LXC, Docker) sin una política clara de asignación de recursos, lo que genera cuellos de botella de CPU/RAM y colisiones de puertos.
  3. Monitoreo y logging descoordinados – agentes Wazuh o node_exporter instalados de forma manual en cada VM, sin un playbook de despliegue, dificultan la correlación de eventos y el mantenimiento.

Solución

Una arquitectura modular basada en tres capas simplifica la expansión y reduce los puntos de falla:

1. Capa de red física

  • Switch gestionado (por ejemplo, Netgear GS308E) como punto de agregación. Configura un trunk 802.1Q que transporte todas las VLAN necesarias (DMZ, MGMT, TRUSTED). Usa el mismo ID de VLAN en OPNsense y en los puertos del switch que conectan a los hosts.
  • Router/firewall (OPNsense) en modo router on a stick. Asigna interfaces virtuales a cada VLAN y habilita DHCP solo en la VLAN de gestión. Activa NAT y reglas de firewall básicas para aislar la DMZ del resto.

2. Capa de virtualización

  • Proxmox VE como hipervisor principal. Crea dos resource pools: uno para servicios críticos (SIEM, monitoring) y otro para laboratorios (Kali, honeypots). Reserva al menos 4 GB de RAM y 2 vCPU para cada pool para evitar contención.
  • Docker Swarm en los Raspberry Pi. Usa Portainer como UI ligera y despliega los contenedores de Zammad, Juice Shop y Cowrie mediante stack files versionados en Git. Mantén los nodos en la misma VLAN de trusted para que el tráfico interno no cruce el firewall.

3. Capa de observabilidad

  • Wazuh como SIEM central. Instala el agente en cada VM/contendor mediante un script de cloud‑init o ansible para asegurar versiones idénticas.
  • Prometheus + node_exporter para métricas de hardware y contenedores. Configura scrape configs que apunten a los rangos de IP de cada VLAN.
  • Grafana con dashboards predefinidos (CPU, RAM, tráfico de Zeek). Usa variables de plantilla para cambiar rápidamente de origen de datos.

4. Orquestación de configuración

Un pequeño repositorio Git con Ansible o Terraform permite recrear el entorno en minutos. Define:

  • hosts.yml con IP estáticas de los switches y del OPNsense.
  • playbooks/ que instalen agentes Wazuh, configuren VLANs en OPNsense y desplieguen stacks Docker.
  • Variables de presupuesto (max_ram: 32GB, max_storage: 6TB) para que el mismo código sirva en hardware más modesto o más potente.

5. Documentación y ticketing

  • Zammad como ticketing interno. Cada incidente (login fallido, alerta de Wazuh) genera automáticamente un ticket. Usa la API de Zammad para crear plantillas de reporte y enlazarlas a los dashboards de Grafana.

Cuándo aplicar esta solución

  • Síntomas típicos: múltiples VLAN sin comunicación, agentes de monitoreo que no reportan, o recursos de VM que se saturan inesperadamente.
  • Entornos: laboratorios de certificación (CCNA, Sec+), pruebas de vulnerabilidades, o proyectos de documentación de procesos.
  • Exclusiones: infraestructuras que requieren alta disponibilidad a nivel de datacenter (cluster de Proxmox con Ceph) o que dependen de hardware propietario (firewalls de nivel empresarial). En esos casos la arquitectura debe escalar a soluciones de high‑availability y storage‑area networks.

Código

# Configuración de trunk en OPNsense (CLI)
opnsense-shell -c "
ifconfig em0 vlan 10 vlandev em0 inet 192.168.10.1/24
ifconfig em0 vlan 20 vlandev em0 inet 192.168.20.1/24
ifconfig em0 vlan 30 vlandev em0 inet 192.168.30.1/24
"

# Deploy de stack Docker con Portainer
docker stack deploy -c docker-compose.yml security-lab

Verificación

  1. Conectividad VLAN – Desde una VM en la VLAN trusted, ejecuta ping 192.168.20.1 (gateway OPNsense) y verifica que el ping a la VLAN dmz responde.
  2. Agentes activos – En Grafana, abre el dashboard Wazuh Alerts y confirma que aparecen eventos de al menos dos hosts diferentes.
  3. Ticket automático – Fuerza un login fallido en una VM (ssh user@host con credencial incorrecta) y comprueba que Zammad crea un ticket con la etiqueta security.
  4. Uso de recursos – En Proxmox, revisa la tabla de resource pools; cada pool debe mantener <70 % de CPU y RAM asignados.

Notas adicionales

  • Presupuesto: reutiliza discos duros de 3–4 TB como almacenamiento de respaldo para VM. Un RAID‑1 software en Proxmox protege contra fallos sin costo adicional.
  • Seguridad: desactiva el UPnP en el router doméstico y limita el acceso a la UI de Portainer a la VLAN mgmt mediante reglas de firewall.
  • Escalabilidad: cuando el presupuesto lo permita, agrega un segundo NIC al host Proxmox y conecta directamente la VLAN dmz al switch, evitando el paso por OPNsense para tráfico de alta velocidad.
  • Documentación: mantén un README.md en el repositorio Git con diagramas de red (draw.io) y versiones de cada componente. Los reclutadores valoran la trazabilidad de cambios.

Con esta arquitectura, cualquier profesional en transición puede montar un homelab robusto, demostrar habilidades de networking, virtualización, seguridad y monitoreo, y presentar un portafolio que habla por sí mismo.