Problema

Los ingenieros de sistemas que gestionan entornos productivos a menudo carecen de un espacio seguro donde experimentar con cambios de arquitectura, políticas de grupo (GPO) o procesos de recuperación sin afectar a usuarios reales. Un servidor de gran capacidad (96 GB RAM, 48 núcleos) que ya no sirve a producción se convierte en una oportunidad para montar un laboratorio interno que reproduzca la complejidad de una infraestructura empresarial: firewall, controlador de dominio, servidores de archivos, clientes y conexión a servicios en la nube como Azure Entra. El reto consiste en diseñar una topología aislada, reproducir servicios críticos y mantener la flexibilidad para probar escenarios de fallos y actualizaciones.

Causa

  1. Falta de aislamiento – Ejecutar pruebas directamente en la red de producción expone a usuarios a interrupciones y a datos sensibles a riesgos de corrupción.
  2. Infraestructura monolítica – Cuando todos los servicios corren en la misma host sin segmentación, cualquier error de configuración (por ejemplo, una regla de firewall equivocada) colapsa todo el entorno.
  3. Escasez de herramientas de orquestación – Sin una capa de virtualización que permita snapshots y clones rápidos, la recuperación tras un experimento fallido se vuelve lenta y propensa a errores.
  4. Integración parcial con la nube – Simular Azure AD/Entra sin una conexión real impide validar flujos de autenticación híbrida y políticas de Conditional Access.

Solución

Construir un laboratorio modular usando Proxmox VE como hipervisor y OPNsense como firewall/router virtual. Cada servicio (DC, file server, clientes) se despliega en máquinas virtuales (VM) independientes, lo que permite snapshots y restauraciones instantáneas. La red se segmenta en tres subredes:

  • LAN interna (192.168.10.0/24) para DC, servidores y clientes.
  • DMZ (192.168.20.0/24) para OPNsense y acceso a internet.
  • Management (192.168.30.0/24) para la consola de Proxmox y herramientas de monitorización.

Paso 1: Preparar Proxmox

Instala Proxmox VE en el hardware disponible. Usa la ISO oficial y sigue el instalador estándar. Al terminar, habilita el repositorio pve-enterprise o pve-no-subscription según tu licencia y actualiza:

apt update && apt full-upgrade -y
reboot

Paso 2: Crear la red virtual

En la interfaz web de Proxmox, crea un Linux Bridge llamado vmbr0 (DMZ) y otro vmbr1 (LAN). Asigna vmbr0 a la NIC física que conecta a tu router de casa y vmbr1 a una NIC interna o a la misma NIC con VLAN 10.

Paso 3: Desplegar OPNsense

  1. Descarga la OVA de OPNsense y conviértela a formato QCOW2:
qemu-img convert -f vmdk -O qcow2 OPNsense-*.ova opnsense.qcow2
  1. Crea la VM en Proxmox (2 vCPU, 4 GB RAM, disco 20 GB) y conecta la primera interfaz a vmbr0 (WAN) y la segunda a vmbr1 (LAN).
  2. Durante el primer arranque, configura la WAN con DHCP (o IP estática) y la LAN con 192.168.20.1/24. Habilita DHCP en la LAN para que las VMs reciban direcciones en 192.168.20.x.

Paso 4: Controlador de dominio (Windows Server)

  1. Crea una VM Windows Server 2022 (4 vCPU, 8 GB RAM, disco 60 GB).
  2. Conéctala a vmbr1.
  3. Instala AD DS, promueve a controlador de dominio y asigna la zona corp.local.
  4. Configura la zona DNS para que apunte a sí mismo y a OPNsense como reenviador externo.

Paso 5: Servidor de archivos (Linux Samba)

  1. VM Linux (Debian/Ubuntu) con 2 vCPU, 4 GB RAM, disco 100 GB.
  2. Únete al dominio usando realmd y configura un share Samba con ACLs basadas en grupos AD.
  3. Habilita snapshots diarios para pruebas de restauración.

Paso 6: Clientes de prueba

Despliega al menos dos VMs: una Windows 10 y una Ubuntu Desktop. Conéctalas a vmbr1 y verifica que reciben IP vía DHCP de OPNsense y que pueden autenticarse contra el DC.

Paso 7: Integración con Azure Entra

  1. Registra una Azure AD Connect en el DC y sincroniza usuarios con Azure Entra.
  2. Configura Hybrid Azure AD Join para que los equipos Windows se registren automáticamente en Azure.
  3. Prueba una política de Conditional Access que requiera MFA para acceso a una aplicación SaaS.

Paso 8: Automatización y snapshots

Utiliza pveam para crear plantillas de VM y qm clone para generar clones rápidos. Programa snapshots antes de cada cambio crítico:

qm snapshot 101 pre-gpo-change

Si algo falla, restaura con:

qm rollback 101 pre-gpo-change

Cuándo aplicar esta solución

  • Necesitas un entorno seguro para validar cambios de red, GPO o procesos de backup sin impactar producción.
  • Cuentas con hardware sobrante (CPU, RAM) que pueda alojar varias VMs simultáneas.
  • Requieres integración híbrida con Azure AD/Entra para probar flujos de autenticación.
  • No deseas invertir en equipos de laboratorio costosos; la virtualización cubre la mayoría de los casos.

No es adecuada cuando:

  • El hardware es limitado y no soporta la carga de varias VMs.
  • Se necesita emular hardware específico (por ejemplo, NIC de 10 GbE) que no está disponible en la virtualización.
  • El objetivo es probar rendimiento a nivel de hardware (latencia de disco, I/O intensivo).

Código

# Crear bridge vmbr0 (DMZ) y vmbr1 (LAN) en /etc/network/interfaces
cat <<EOF >> /etc/network/interfaces

auto vmbr0
iface vmbr0 inet static
    address 192.168.20.1/24
    bridge_ports eth0
    bridge_stp off
    bridge_fd 0

auto vmbr1
iface vmbr1 inet static
    address 192.168.10.1/24
    bridge_ports none
    bridge_stp off
    bridge_fd 0
EOF

systemctl restart networking

Verificación

  1. Conectividad – Desde un cliente, ping 192.168.20.1 (OPNsense) y ping <DC_IP>.
  2. Resolución DNS – nslookup dc.corp.local debe devolver la IP del controlador.
  3. Autenticación – Inicia sesión en Windows 10 con credenciales AD; verifica que el perfil se carga.
  4. Azure Entra – En Azure portal, confirma que el dispositivo aparece bajo Devices > All devices.
  5. Snapshot – Realiza un cambio de GPO, verifica el comportamiento, y si algo falla, ejecuta qm rollback y revisa que el estado vuelve a la línea base.

Notas adicionales

  • Snapshots y espacio en disco: Cada snapshot duplica bloques modificados; monitoriza el uso de almacenamiento para evitar sobresaturación.
  • OPNsense reglas: En entornos de laboratorio, es fácil olvidar desactivar NAT o firewall entre LAN y DMZ; revisa la tabla de reglas después de cada cambio.
  • Sincronización de tiempo: Asegúrate de que todas las VMs usen NTP (por ejemplo, pool.ntp.org). Desincronizaciones pueden romper la autenticación Kerberos.
  • Backup de la configuración de OPNsense: Exporta la configuración (System > Configuration > Backups) antes de experimentar con interfaces o VPNs.
  • Licenciamiento: Proxmox es libre bajo GPL, pero si usas la suscripción empresarial, mantén la clave actualizada para recibir actualizaciones de seguridad.

Con esta arquitectura, cualquier ingeniero de sistemas puede recrear un entorno de producción completo, probar políticas, simular desastres y afinar procesos de recuperación sin comprometer la infraestructura real.