Cómo crear redes virtuales para pruebas en Windows

Montar redes virtuales en Windows para hacer pruebas de seguridad, laboratorio o teletrabajo es una de las mejores formas de trastear sin miedo a romper nada en tu red real. Puedes levantar máquinas, simular un pequeño centro de datos, jugar con cortafuegos o incluso crear tu propia VPN casera usando solo herramientas del sistema, todo dentro de un entorno controlado.

El objetivo de esta guía es juntar en un único artículo todo lo que necesitas para crear “edes” o redes virtuales para pruebas en Windows: desde cómo aislar entornos completos con Hyper-V y SCVMM, hasta cómo levantar una VPN doméstica, pasando por ejemplos sencillos con VirtualBox y por simuladores de red para hacer diseños complejos sin gastar un euro en hardware.

Qué es una red virtual de pruebas en Windows y para qué sirve

Una red virtual de pruebas es un entorno de red simulado o aislado que se ejecuta sobre tu hardware físico, normalmente mediante máquinas virtuales y tecnologías de virtualización de red. En lugar de conectar equipos físicos a switches y routers reales, lo haces todo en software: VMs, switches virtuales, redes lógicas y, si hace falta, una VPN.

Este tipo de entornos son ideales para practicar seguridad, diseño de redes y despliegues sin tocar la red “de verdad”. Puedes probar reglas de firewall, configurar un IPS, desplegar un SIEM, levantar un servidor web vulnerable como DVWA, montar un pequeño Active Directory, romperlo a gusto y luego volver a empezar. También es útil apoyarse en herramientas de análisis y auditoría de redes para evaluar resultados de las pruebas.

En entornos corporativos grandes se usan laboratorios que replican la red de producción casi al milímetro: mismos routers, switches, firewalls y servidores, pero en un entorno de staging. En casa o en pequeñas empresas no suele haber presupuesto para eso, así que tirar de máquinas virtuales, simuladores y redes virtuales en Windows es la alternativa lógica.

La ventaja principal es que puedes automatizar el despliegue de estos entornos con herramientas como SCVMM y Azure Pipelines, o con scripts y Ansible si trabajas más en clave “infraestructura como código”. Así, compartes la “plantilla” de tu laboratorio y cualquiera puede levantarlo en su propio equipo, hacer cambios y que esos cambios sean persistentes.

Virtualización de red en Windows con Hyper-V y SCVMM

Si quieres crear redes virtuales complejas, aisladas y reutilizables en un entorno Windows profesional, el combo Hyper-V + System Center Virtual Machine Manager (SCVMM) es lo más potente. Permite superponer varias redes virtuales distintas sobre la misma red física sin que se “vean” entre ellas.

La idea es que puedas tener varias redes aisladas compartiendo los mismos hosts Hyper-V: máquinas virtuales de distintos entornos pueden convivir en el mismo servidor físico pero cada grupo de VMs solo “ve” su propia red virtual. Eso es perfecto para laboratorios de pruebas, escenarios de build-deploy-test y entornos temporales de QA.

SCVMM usa dos conceptos clave: redes lógicas y redes de máquina virtual. La red lógica representa la estructura de red física y el direccionamiento IP enrutable, mientras que las redes de máquina virtual (VM networks) son las redes “superpuestas” que usan las VMs. Con la virtualización de red de Hyper-V, cada VM puede tener una IP “virtual” independiente del rango IP físico subyacente.

Entre las capacidades más útiles para tus pruebas de Windows están las siguientes: puedes crear redes aisladas que abarcan varios hosts de un mismo clúster o nube privada, alojar VMs de redes distintas en el mismo host sin que se comuniquen entre sí, y asignarles direcciones IP desde cualquier grupo o pool de IP que definas en SCVMM.

Requisitos previos para montar redes virtuales aisladas con SCVMM

Antes de lanzarte a crear tu laboratorio aislado con Hyper-V y SCVMM, necesitas cumplir una serie de condiciones mínimas de infraestructura. Si te falta alguna, es bastante probable que la virtualización de red no funcione como debería.

Como base, vas a necesitar un servidor SCVMM 2012 R2 o superior, que será el cerebro desde el que gestionas las redes lógicas, los switches lógicos y el aprovisionamiento de máquinas virtuales en los hosts Hyper-V.

Los hosts Hyper-V deben ser Windows Server 2012 R2 o posterior, con el rol de Hyper-V instalado y al menos dos tarjetas de red físicas (NIC) conectadas. Una NIC se usará normalmente para la red corporativa o salida a Internet; la otra se configurará en modo troncal (trunk) para la capa de virtualización de red. Si necesitas gestionar y depurar esas interfaces virtuales verás útil la guía sobre adaptadores de red virtuales en Windows.

La NIC de troncal debe ir con una VLAN concreta (por ejemplo, 991) y con subredes IP enrutables asignadas (como 10.10.30.1/24). El administrador de red del entorno donde trabajes se encargará normalmente de preparar esa configuración de VLAN y routing en el switch físico.

Otro requisito importante es que todos los hosts Hyper-V del mismo grupo host compartan el mismo identificador de VLAN de troncal y el mismo diseño de subredes enrutables. Ese grupo host será el que se use para desplegar las redes aisladas que montarás desde SCVMM.

Comprobar la conectividad de la virtualización de red

Una vez configuradas las NIC en troncal y los hosts en Hyper-V, hay que validar que las máquinas físicas “se ven” correctamente a través de la red de proveedor (la red física que soporta las redes virtuales). Si esto falla, el resto ni arrancará.

En cada host Hyper-V abre una sesión RDP y luego PowerShell como administrador. Allí, ejecuta el cmdlet Get-NetVirtualizationProviderAddress para obtener la dirección del proveedor asociada a la NIC física configurada en modo troncal con su VLAN correspondiente.

Después, desde otro host Hyper-V, vuelve a abrir PowerShell con privilegios elevados y lanza un ping -p <ProviderAddress> hacia la dirección de proveedor del primer host. Repite el proceso en todos los sentidos para asegurarte de que todos los hosts se alcanzan entre sí a través de la red troncal.

Si alguno de esos ping da error, toca revisar la configuración de VLAN, routing o firewall en la red física. En ese caso, lo suyo es coordinarse con la persona que administra la red corporativa antes de seguir con la capa de virtualización.

Crear la capa de virtualización de red en SCVMM

La “capa de virtualización” en SCVMM se construye en varios pasos encadenados: crear redes lógicas, definir perfiles de puerto, configurar conmutadores lógicos y, por último, aplicar esos conmutadores a los hosts Hyper-V. Esta parte se hace una sola vez por grupo de hosts.

Empiezas iniciando sesión en la consola de administración de SCVMM. Desde ahí, en la vista de “Tejido” (Fabric), entras en la sección de Redes y accedes al apartado de Redes lógicas para empezar a crear las estructuras de red base.

La primera red lógica que debes crear será la que soporte la virtualización de red. Al crearla, puedes seleccionar la opción de “One Connected Network” y marcar que las nuevas redes creadas sobre ella puedan usar virtualización de red Hyper-V, de modo que todas las VM networks que aparezcan encima se beneficien de ello.

A continuación se agrega un sitio de red (network site) asociado al grupo host adecuado. En ese sitio se indica el identificador de VLAN usado en la NIC troncal de los hosts y las subredes IP enrutables asociadas. Conviene ponerle un nombre reconocible al sitio para no confundirse después.

Después se crea un pool de direcciones IP para esa red lógica, indicando el rango IP enrutado que tengas disponible para la VLAN; si existen varias subredes, puedes crear un pool por cada una. También se especifica la puerta de enlace (normalmente la primera IP del rango) y se dejan, si procede, las configuraciones de DNS o WINS por defecto.

Una vez tienes lista la red lógica interna, creas otra red lógica para el acceso externo, pensada para la salida a Internet. En este caso, se selecciona la opción de “Una red conectada” y se marca que se cree automáticamente una red de máquina virtual con el mismo nombre para que las VMs puedan engancharse directamente a ella.

En la red lógica externa se añade de nuevo un sitio de red para el mismo grupo host, pero esta vez con VLAN 0, lo que indica que el tráfico va por la NIC en modo de acceso normal hacia la red externa o Internet, sin virtualización de red encima.

Perfiles de puerto y conmutadores lógicos para las redes de prueba

Con las redes lógicas ya definidas en SCVMM, el siguiente paso es crear perfiles de puerto que describan cómo se conectan los adaptadores físicos de los hosts a esas redes y después agruparlos dentro de conmutadores lógicos.

En la sección de Redes del tejido de SCVMM puedes crear un nuevo perfil de puerto Hyper-V. Para el entorno de virtualización de red se selecciona el tipo de “Perfil de puerto de vínculo superior” y se escoge el algoritmo de equilibrio de carga “Hyper-V Port”, marcando además la casilla que habilita la virtualización de red de Hyper-V.

Luego se crea un segundo perfil de puerto para la red lógica externa, también como perfil de vínculo superior, pero esta vez se deja como algoritmo de equilibrio “Host predeterminado” y no se activa la virtualización de red. Este será el perfil asociado a la salida a Internet o red corporativa normal.

A continuación se generan los conmutadores lógicos, uno para cada tipo de tráfico. El primero será el conmutador “interno” que usará el perfil de puerto con virtualización de red; el segundo, el conmutador “externo” para la comunicación con Internet.

Cuando creas el conmutador lógico seleccionas el perfil de puerto de vínculo superior adecuado en la pestaña correspondiente, de modo que todos los hosts que se unan a ese conmutador compartan las mismas características de red y balanceo.

El último paso de esta parte es añadir estos conmutadores lógicos a todos los hosts Hyper-V del grupo host. Se entra en “VM y servicios”, se elige cada host, se van a las propiedades y en la pestaña de “Conmutadores virtuales” se asocian los adaptadores físicos correctos a los conmutadores lógicos interno y externo.

Topologías de redes virtuales para pruebas en Windows

Una vez montada la infraestructura de virtualización de red, toca decidir el tipo de topología que quieres para tu laboratorio de pruebas. Con SCVMM y la extensión de Azure Pipelines puedes automatizar varias configuraciones típicas para escenarios de build-deploy-test.

Una primera opción es una red aislada respaldada por un dominio Active Directory. En este caso, el laboratorio incluye una máquina “de borde” con conectividad hacia Internet o hacia el servidor TFS/Azure DevOps y un agente de despliegue, una VM con AD y DNS para el dominio interno y varias VMs de aplicación donde desplegar y probar el software.

Otra topología posible es una red aislada sin Active Directory local. Aquí sigues teniendo la VM de borde con el agente de despliegue y conectividad hacia el exterior, pero las máquinas de aplicación no se integran en un dominio interno; funcionan simplemente como equipos aislados accesibles desde ese punto de entrada.

Finalmente puedes optar por una red no aislada pero con AD, conectada a una red externa. Las VMs de aplicación se enchufan también a la red externa, de forma que comparten parte del tráfico con otras máquinas físicas, pero mantienes una VM de borde, un dominio local y un flujo controlado de despliegue.

La extensión de SCVMM para Azure Pipelines permite definir cualquiera de estas topologías dentro de una canalización de build o release: se aprovisionan las VMs a partir de plantillas o VHDs, se crean o asignan redes de VM y se conectan los agentes que se usarán en las fases de despliegue y test.

Automatizar entornos de laboratorio con Azure Pipelines y SCVMM

Si quieres que tu red de pruebas en Windows se levante “a demanda” cada vez que lanzas una compilación o una versión, la combinación de Azure Pipelines con la extensión SCVMM es muy potente. Te permite tratar el laboratorio como si fuera parte del pipeline.

El proceso típico arranca instalando la extensión SCVMM en tu instancia de Azure DevOps. Esta extensión añade una tarea específica a las canalizaciones de build y release que sirve para gestionar entornos SCVMM: crear VMs, configurar redes virtuales aisladas y preparar escenarios de build-deploy-test de forma automatizada.

Dentro de una pipeline añades una tarea de tipo SCVMM y configuras la conexión de servicio al servidor SCVMM que va a alojar las VMs. En la tarea eliges si quieres crear VMs nuevas a partir de plantillas, máquinas almacenadas o discos virtuales (VHD/VHDX) existentes.

En los escenarios donde quieres redes aisladas, normalmente borras cualquier red de VM previa en las máquinas que se crean, dejando vacío el campo de red de VM para topologías internas. Si, en cambio, necesitas que las máquinas estén también en la red externa (como en la topología no aislada), indicas la red de VM externa correspondiente.

Hay que indicar también la nube de host de SCVMM donde se desplegarán las VMs. Si usas una nube privada, los hosts que pertenezcan a esa nube deben estar ya configurados con los conmutadores lógicos interno y externo que creaste antes, para que todo cuadre.

La propia tarea SCVMM permite marcar que quieres usar virtualización de red y definir, si procede, una máquina VM específica para Active Directory: se indica el nombre de la VM, la imagen origen, la IP estática configurada en ese origen y el sufijo DNS del dominio interno.

También defines el nombre de la red de máquina virtual a crear y su subred interna, enganchándolas a la red lógica adecuada. Conviene usar nombres únicos, por ejemplo incluyendo el número de versión, para que sea fácil rastrear de qué despliegue viene cada entorno.

Por último se configura la VM de borde, que será la encargada de hablar con Azure Pipelines o TFS. Se elige su plantilla de origen (que debe tener ya predescargados los ficheros del agente) y se especifica la red de VM externa que usará para salir fuera. Sobre esa máquina se instalará el agente de despliegue o de automatización con un nombre o etiqueta únicos.

Habilitar el escenario build-deploy-test sobre la red virtual

Una vez la tarea de SCVMM ha levantado el entorno de red virtual, lo normal es encadenar otro trabajo en la pipeline que se ejecute sobre los agentes desplegados en la VM de borde y, desde ahí, haga el despliegue a las VMs de aplicación.

En Azure Pipelines puedes escoger entre un trabajo de grupo de implementación (deployment group job) o un trabajo de agente clásico según el tipo de agente instalado en la VM de borde. En las propiedades del trabajo se selecciona el grupo de despliegue o el pool de agentes apropiado.

Si usas un agente de automatización, puedes añadir una “demanda” sobre Agent.Name para que la pipeline busque exactamente el agente cuyo nombre definiste al aprovisionar la VM de borde. En el caso de grupos de implementación, se usan etiquetas en las propiedades de las máquinas del grupo.

Dentro de ese trabajo añades ya las tareas de despliegue de aplicaciones y de pruebas: instalación de tu app en las VMs, ejecución de baterías de test funcionales, de rendimiento, de seguridad, etc. Al terminar, puedes decidir si quieres destruir las VMs marcando la opción de eliminación en la tarea de SCVMM.

El resultado es que cada ejecución de la pipeline puede crear un entorno aislado nuevo, desplegar ahí la versión que estás probando, lanzar los tests y, si todo va bien, desmontar el entorno automáticamente, quedándote solo con los resultados de las pruebas y los logs.

Crear una VPN doméstica en Windows sin software de terceros

Además de redes internas de laboratorio, muchos usuarios quieren montar una VPN propia en Windows para conectarse desde fuera a su red doméstica o de oficina. Esto no sirve tanto para “simular” que navegas desde otro país, sino para ganar privacidad y acceso remoto seguro.

Una VPN casera en Windows crea un túnel cifrado entre el dispositivo cliente y tu equipo servidor. Todo el tráfico (búsquedas, correos, acceso a carpetas compartidas…) se cifra y viaja primero hasta el servidor VPN, que es quien se comunica después con Internet o con la red local. De cara a las webs, la IP visible será la del servidor VPN, no la del cliente.

Este tipo de VPN también te permite acceder a recursos de tu red local como si estuvieses físicamente en casa: impresoras, servidores de ficheros, equipos de sobremesa con Escritorio remoto, etc. Es una solución muy apañada para teletrabajo sencillo.

En Windows 10 y 11 puedes montar un pequeño servidor VPN PPTP sin instalar nada adicional, tirando únicamente de las opciones de Conexiones entrantes del sistema. No es la solución más sofisticada del mundo, pero para laboratorios caseros y redes de pruebas suele ser suficiente.

Configurar un servidor VPN en Windows paso a paso

Para levantar tu propio servidor VPN en un PC con Windows tienes que activar primero una conexión entrante y luego ajustar el rango de IPs que se asignarán a los clientes VPN, además de abrir el puerto correspondiente en el router y ajustar el firewall.

Desde la Configuración de Windows entra en “Red e Internet”. En Windows 10 ve al apartado Estado y haz clic en “Cambiar opciones del adaptador”; en Windows 11 entra en “Configuración de red avanzada” y luego en “Más opciones del adaptador de red”, que abre la vieja ventana de conexiones de Windows.

En esa ventana, donde se ven las interfaces tipo Ethernet o Wi-Fi, pulsa F10 para sacar el menú clásico, entra en Archivo y selecciona “Nueva conexión entrante”. Eso le dice a Windows que quieres permitir que otros usuarios se conecten al equipo a través de la red.

A continuación eliges qué cuentas de usuario podrán usar la VPN. Puedes marcar una existente o, más recomendable, crear un usuario nuevo específico para la VPN, con un nombre y contraseña que después utilizarás al conectarte desde otros dispositivos.

Más adelante el asistente te ofrecerá elegir el modo de conexión. Asegúrate de que está marcada la opción “A través de Internet”, que es lo que convierte esta conexión entrante en un servidor VPN accesible desde fuera de tu red local.

En la parte de configuración de software de red selecciona “Protocolo de Internet versión 4” y entra en Propiedades. De forma predeterminada, el servidor usará la misma red IP local, pero lo ideal es definir un rango específico de direcciones IP que se asignarán a los clientes VPN.

Marca la opción de especificar un rango de IP y define unas cuantas direcciones que encajen en la subred de tu router. Por ejemplo, si la puerta de enlace es 192.168.1.1, podrías reservar del 192.168.1.20 al 192.168.1.30 para clientes VPN. Las tres primeras secciones del rango deben coincidir con las de la IP del router.

Cuando termines de configurar el rango, vuelve al asistente y pulsa “Permitir acceso”. En ese momento, Windows creará el servidor VPN y quedará listo a la espera de conexiones entrantes usando ese usuario y ese conjunto de direcciones IP.

Abrir el puerto en el router y ajustar el firewall de Windows

Para que los clientes remotos puedan llegar a tu servidor VPN a través de Internet no basta con configurarlo en el PC; hace falta abrir el puerto correspondiente en el router y asegurarse de que el firewall de Windows permite el tráfico.

El puerto estándar para este tipo de VPN PPTP en Windows es el 1723. Debes entrar en la interfaz de configuración de tu router (habitualmente tecleando 192.168.1.1 o 192.168.0.1 en el navegador) y crear una regla de redirección de puertos (port forwarding) que envíe el tráfico entrante en el 1723 a la IP local de tu PC.

Para saber la IP local de tu equipo abre una consola de Símbolo de sistema y ejecuta “ipconfig”. La dirección que aparece como IPv4 será la que tengas que poner en la regla del router. No la confundas con la “Puerta de enlace predeterminada”, que es la IP del router.

En el lado de Windows, abre el Panel de control clásico y entra en “Sistema y seguridad”, luego en “Firewall de Windows Defender”. Allí selecciona la opción de “Permitir que una aplicación o una característica a través de Firewall de Windows Defender”.

Pulsa en “Cambiar la configuración” y busca la entrada “Enrutamiento y acceso remoto” en la lista. Marca las casillas de red Privada y Pública para esa aplicación y guarda los cambios. Con eso le estás diciendo al firewall que deje pasar el tráfico relacionado con el servidor VPN.

Conectarse a la VPN desde Windows y otros dispositivos

Cuando tu servidor VPN está listo y el puerto abierto, puedes conectarte desde otro Windows o desde un móvil Android/iOS con soporte para PPTP (ten en cuenta que algunos sistemas van retirando soporte por seguridad, así que para pruebas conviene revisar las opciones disponibles).

En el equipo cliente, ve a Configuración > Red e Internet > VPN y pulsa “Agregar VPN”. En proveedor de VPN elige “Windows”, ponle un nombre identificativo a la conexión y, en nombre de servidor o dirección, escribe la IP pública de tu router o el dominio dinámico si usas un servicio tipo No-IP.

En los campos de usuario y contraseña introduce las credenciales del usuario VPN que creaste al configurar la conexión entrante. Guarda la configuración, selecciona la VPN en la lista y pulsa “Conectar”. Si todo está bien, el equipo obtendrá una de las IP del rango que definiste y tendrás acceso a la red remota.

Desde Android o iOS el procedimiento es similar: añades una nueva VPN, eliges PPTP (si sigue disponible), indicas la IP o dominio del servidor y las credenciales. Una vez conectados, todos los servicios que dependan de la red local o del túnel cifrado funcionarán como si estuvieran dentro de tu LAN.

Red local de pruebas con Windows y VirtualBox

Si lo que buscas es algo aún más sencillo para empezar a jugar con redes en Windows, una opción muy práctica es montar un mini laboratorio con dos máquinas virtuales de Windows en VirtualBox, dentro de una red interna.

Empiezas clonando una máquina base de Windows 10 que tengas ya instalada. Al clonar, es crucial marcar la opción de “Reiniciar MAC” para que la tarjeta de red virtual de la VM clonada tenga una dirección física distinta; si no, ambas tendrían la misma MAC y tendrías conflictos de red.

En cada VM puedes configurar el nombre de equipo y el grupo de trabajo desde las propiedades del sistema: das nombres distintos a las máquinas (por ejemplo cliente1 y cliente2) pero las metes en el mismo grupo de trabajo, algo tipo “Empresa_TuNombre”, y reinicias para que los cambios tomen efecto.

En cada una creas dos cuentas: una con rol de administrador y otra estándar, lo que te permite probar permisos, acceso a recursos compartidos, etc. Por ejemplo, un usuario Supervisor en el grupo Administradores y otro super1/super2 en el grupo Usuarios.

Por defecto VirtualBox suele poner la red de las VMs en modo NAT, de forma que ambas salen a Internet a través del host, pero realmente no están “en la misma red” entre sí, por eso pueden tener la misma IP interna y seguir funcionando.

Para simular una red local real, apaga las VMs y cambia el adaptador de red a “Red interna”. Esto equivale a conectarlas a un switch virtual. Al volver a iniciar, ya no tendrán salida a Internet y la interfaz aparecerá sin IP asignada.

En cada Windows configuras ahora una IP fija en la misma subred, por ejemplo 192.168.100.101 y 192.168.100.102 con máscara 255.255.255.0, sin puerta de enlace ni DNS, para tener una red puramente local de laboratorio sin salida al exterior.

Si intentas hacer ping entre las máquinas verás que al principio no responde, porque el firewall de Windows bloquea por defecto las peticiones ICMP. Tienes dos opciones: desactivar el firewall para pruebas o crear una regla de entrada personalizada que permita el tipo ICMP “Petición de eco”.

Creando esa regla en cada VM podrás usar ping para verificar la conectividad y, a partir de ahí, empezar a compartir carpetas, probar autenticaciones, jugar con políticas de firewall más avanzadas, etc., todo dentro de una red muy sencilla pero bastante realista.

Simuladores y emuladores de redes para diseñar laboratorios complejos

Cuando tu laboratorio de Windows se te queda corto y quieres modelar redes más grandes, con routers, switches, firewalls e incluso dispositivos de varios fabricantes, entra en juego otro tipo de herramientas: los simuladores y emuladores de redes.

Un simulador (tipo Cisco Packet Tracer) recrea el comportamiento de la red por software sin ejecutar el sistema operativo real de los dispositivos. Es ideal para aprender conceptos básicos de routing y switching, preparar certificaciones iniciales y hacer pruebas con muy pocos recursos de CPU y RAM. Si quieres empezar con esa opción, el tutorial de Packet Tracer es un buen punto de partida.

Un emulador (como GNS3 o EVE-NG) ejecuta directamente la imagen del sistema operativo de routers, switches, firewalls y otros equipos, consiguiendo una fidelidad casi total respecto al hardware real. Esto es lo que se suele usar para certificaciones avanzadas (CCNP, CCIE) y pruebas cercanas a producción.

Estos programas te permiten diseñar la red antes de montarla físicamente: definen el mapa lógico, el direccionamiento IP, la ubicación de cada dispositivo, la arquitectura de seguridad, etc. Muchas empresas con poco presupuesto usan estos laboratorios virtuales en lugar de montar un laboratorio físico completo.

Eso sí, los emuladores serios consumen bastantes recursos y exigen cierta curva de aprendizaje. Algunos requieren imágenes de sistema operativo que son de pago, otros necesitan algo de maña para integrar máquinas virtuales adicionales (Windows o Linux) dentro de las topologías de red.

Entre las opciones más usadas para complementar tus pruebas en Windows están Cisco Packet Tracer (muy accesible para empezar), GNS3 (código abierto y muy potente, integra VirtualBox y QEMU), EVE-NG (ideal para entornos multifabricante), VIRL de Cisco (de pago y pensado para certificaciones avanzadas) o soluciones como OMNeT++, QualNet y MIMIC, más orientadas a simulaciones a gran escala y entornos de investigación.

Aunque estos simuladores son una maravilla para aprender y planificar redes, conviene recordar sus limitaciones: no siempre reflejan el 100 % del comportamiento real, necesitan hardware decente para topologías grandes, algunos tienen costes de licencia y todos exigen dedicar tiempo a dominarlos como es debido.

Juntando todo esto —Hyper-V, SCVMM, VPN en Windows, redes internas con VirtualBox y simuladores de red— puedes montar desde casa o desde una pequeña oficina un ecosistema muy completo para diseñar, desplegar y probar redes virtuales en Windows: desde labs sencillos con dos clientes hasta entornos aislados multinodo con AD, firewall, SIEM, servidores web vulnerables y pipelines de CI/CD que levantan y destruyen el laboratorio automáticamente cada vez que necesitas poner a prueba tu seguridad o tu infraestructura.