Configurar el aislamiento de puerto en el switch virtual de Hyper-V

Si trabajas con virtualización en Windows, tarde o temprano te toca pelearte con el switch virtual de Hyper-V y el aislamiento de puertos. No es solo marcar un par de casillas: de cómo diseñes la red depende que tus máquinas virtuales estén protegidas, rindan bien y no se vean entre ellas cuando no deben.

En este artículo vamos a bajar al barro: veremos cómo funciona la red en Hyper-V, las opciones de aislamiento (puertos, VLAN, PVLAN, ACL y NAT), cómo encaja todo eso con System Center VMM y qué trucos prácticos puedes aplicar para que tu entorno quede limpio, ordenado y seguro tanto en un host casero como en un clúster serio.

Aislamiento de red y espacios de nombres en Windows Server y Hyper-V

En los entornos modernos de Microsoft, gran parte del aislamiento se basa en los espacios de nombres de red y compartimentos de red de la pila TCP/IP. Cada punto de conexión (por ejemplo, el de un contenedor o un adaptador de una VM) puede vivir en su propio compartimento, de forma que su visión de la red queda separada del resto.

El host y su adaptador de red virtual de administración se mantienen en el espacio de nombres de red predeterminado, mientras que cada contenedor Windows Server que se ejecuta con aislamiento de Hyper-V tiene su propio espacio de nombres donde se instala un adaptador virtual específico para ese contenedor.

Los contenedores Windows Server “clásicos” usan un adaptador de red virtual alojado en el host para conectarse al conmutador virtual de Hyper-V, mientras que los contenedores en modo aislamiento de Hyper-V se conectan mediante un adaptador sintético de máquina virtual (no visible para la VM de utilidad), reforzando así la separación entre host, contenedores y resto de cargas de trabajo.

Si quieres ver qué compartimentos de red hay en tu sistema, puedes tirar de PowerShell y listar todo con el cmdlet Get-NetCompartment, muy útil cuando depuras problemas raros de aislamiento o conectividad en entornos con contenedores y NAT.

Seguridad de red y aislamiento mediante ACL, firewall y VFP

La seguridad y el aislamiento de red no dependen solo de Hyper-V; intervienen el Firewall de Windows, las ACL de puerto del switch virtual y Azure Virtual Filtering Platform (VFP), según el tipo de contenedor y el controlador de red que uses.

En contenedores Windows Server, la política predeterminada combina Firewall del host (con espacios de nombres habilitados) y reglas en VFP. La salida suele ser “permitir todo”, mientras que para la entrada se permite tráfico TCP, UDP, ICMP e IGMP no solicitado y se bloquea el resto de protocolos no contemplados.

Para los contenedores que funcionan con aislamiento de Hyper-V, cada uno ejecuta su propia instancia de Firewall de Windows dentro de su núcleo aislado, generalmente con una política por defecto permisiva (Allow All) tanto en ese firewall interno como en VFP, lo que deja en tu mano la responsabilidad de endurecer las reglas si la carga de trabajo lo requiere.

En Kubernetes, la lógica cambia un poco: dentro de un pod se crea primero un contenedor de infraestructura al que se conecta el punto de red, y todos los contenedores del pod comparten el mismo espacio de nombres de red, lo que incluye la dirección IP y el espacio de puertos. El aislamiento entre pods queda entonces en manos de firewall, políticas de red y ACL en los switches virtuales.

Si necesitas modificar las ACL de puerto predefinidas, tienes que revisar la configuración del Servicio de redes de host y ajustar políticas en los distintos controladores de red (Transparente, NAT, L2Bridge, L2Tunnel, Superposición), sabiendo qué componente aplica las reglas en cada caso: Firewall de Windows, VFP o ambos.

Qué es el conmutador virtual de Hyper-V y tipos de switch

El conmutador virtual de Hyper-V es, en esencia, un switch Ethernet de capa 2 definido por software. Su misión es conectar tus máquinas virtuales a redes físicas o lógicas y darte las herramientas de aislamiento, monitorización y seguridad necesarias en un entorno de virtualización.

Lo tienes disponible desde el propio Administrador de Hyper-V (Hyper-V Manager) y, con cada versión de Windows Server, ha ido ganando músculo: rastreo de recursos, nuevas medidas de protección frente a VM maliciosas, opciones avanzadas de aislamiento de tráfico por puerto, soporte de PVLAN, trunk, ACL extendidas, etc.

Por defecto, tras instalar el rol de Hyper-V, no se crea ningún switch. Hasta que no configuras uno, tus VMs no pueden salir a ninguna parte. Para gestionarlos a golpe de clic, abres el Administrador del conmutador virtual (Virtual Switch Manager) desde el panel de acciones del host.

Hyper-V permite tres tipos de conmutador virtual, cada uno con implicaciones directas en el aislamiento de red y en cómo se comportan los puertos del switch:

• Conmutador externo: enlaza un NIC físico del host con un NIC virtual, proporcionando acceso a la red física (e Internet si la red lo permite). Las VMs, el host y el exterior comparten esta conectividad.
• Conmutador interno: ofrece una red virtual en la que pueden hablar entre sí las VMs conectadas y el propio host, pero sin salir a redes externas.
• Conmutador privado: crea una red totalmente aislada en la que las VMs solo se ven entre ellas; ni el host ni otras redes pueden interactuar con esa “sandbox”.

Configuración de un switch virtual y opciones clave de aislamiento

Cuando creas un conmutador externo, un asistente te guía por varias opciones que afectan a la seguridad y al aislamiento de puertos. La primera es seleccionar qué adaptador físico será el uplink del vSwitch; si tienes varios NIC, aquí decides por dónde va a salir el tráfico.

Otra casilla importante es la de permitir que el sistema operativo de administración comparta el adaptador. Activada por defecto, hace que el host use ese mismo NIC para su propia conectividad. Si la desmarcas, dejas al host sin red por ese camino. Esto es muy delicado cuando lo haces de forma remota, porque te puedes quedar sin acceso al servidor en un clic.

El switch también puede habilitar SR-IOV (Single Root I/O Virtualization), una tecnología que, si el hardware lo soporta, desvía parte del tráfico directamente desde la NIC física a las VMs, saltándose buena parte del plano de datos del vSwitch y reduciendo latencia y uso de CPU. Eso sí, SR-IOV no puede activarse a posteriori en un switch ya creado, y exige compatibilidad de BIOS, CPU (SLAT) y tarjeta de red.

Por último, puedes activar la opción de VLAN ID para el sistema operativo de gestión. Esto mete el tráfico del host en una VLAN concreta, algo muy útil si quieres separar de forma estricta la gestión del resto del tráfico, tanto a nivel de switch físico como de puertos virtuales del vSwitch.

Tras aplicar los cambios, el host puede perder conectividad unos segundos mientras se apaga el NIC físico, se engancha al switch virtual y se levanta todo de nuevo. Es normal, pero conviene tenerlo en cuenta si estás operando en remoto para no entrar en pánico.

Tipos de conmutador y aislamiento entre host, VMs e Internet

Si te preocupa que ciertas VMs no tengan visibilidad hacia el host o hacia Internet, la elección del tipo de switch virtual es clave para el aislamiento de puerto en Hyper-V.

Con un conmutador privado, las máquinas virtuales comparten una red aislada entre sí, pero no ven al host ni a redes externas. El host tampoco ve a las VMs conectadas ahí. Es ideal para entornos de pruebas o para cargas altamente sensibles que solo necesitan hablar entre ellas.

Con un conmutador interno, las VMs pueden hablar con otras VMs y con el host, pero siguen sin tener salida directa al exterior. Aquí no se configura puerta de enlace en la IP de las VMs (no hace falta), salvo que metas un router virtual o NAT por tu cuenta.

Con un conmutador externo, las VMs, el host y la red física comparten el mismo enlace. Es la opción habitual cuando necesitas conectividad “real”, pero también es la que menos aislamiento aporta por defecto, por lo que suele requerir un poco más de disciplina con VLAN, ACL de puertos y firewall.

Además de elegir el tipo de switch, puedes jugar con varias NIC virtuales por VM, asignando cada adaptador a un switch diferente y, si quieres, a VLAN diferentes, combinando así aislamiento lógico con control detallado por puerto.

NAT interno en Hyper-V: red aislada con salida al exterior

Durante años, si querías que una red interna aislada tuviera salida a Internet, tenías que montar una VM que hiciera de router o firewall. Desde Windows Server 2016 y Windows 10 modernas, puedes crear un switch interno con NAT integrado en el propio sistema operativo, sin necesidad de máquinas adicionales.

El esquema es sencillo: creas un conmutador interno, le asignas una IP en el host que actuará como puerta de enlace de esa red, y luego defines una red NAT con PowerShell para ese prefijo. Las VMs que conectes a ese switch, con IPs de esa subred y apuntando a esa puerta de enlace, podrán salir hacia fuera, pero la red interna no se enruta directamente desde el exterior.

Los pasos básicos son:

• Crear el switch interno: New-VMSwitch -SwitchName «swNAT» -SwitchType Internal.
• Ubicar el adaptador asociado al vSwitch y ponerle la IP de puerta de enlace, por ejemplo: New-NetIPAddress -IPAddress 192.168.254.1 -PrefixLength 24 -InterfaceIndex <ifIndex>.
• Crear la red NAT: New-NetNat -Name netNAT -InternalIPInterfaceAddressPrefix 192.168.254.0/24.

Las VMs se conectan a ese switch, se les asigna una IP estática en la subred (por ejemplo 192.168.254.2, 254.3…) con puerta de enlace 192.168.254.1 y DNS externos, y listo, ya pueden navegar. El host conoce esa red interna porque tiene una IP en ella, pero desde fuera no se ve directamente esa subred; solo se expone la IP del host.

Para publicar servicios de una VM interna (por ejemplo, un IIS en el puerto 80) al exterior, defines reglas de mapping estático de puertos sobre la red NAT, tipo: Add-NetNatStaticMapping -NatName «netNAT» -Protocol TCP -ExternalIPAddress 0.0.0.0 -InternalIPAddress 192.168.254.2 -ExternalPort 80 -InternalPort 80. El acceso se hace contra la IP del host, no contra la IP interna.

Aislar una VM del host y de la red física usando NAT y firewall

Un caso bastante típico es el de querer una VM “de trabajo” que no pueda ver el host ni la red doméstica, pero que sí hable con Internet o con una VPN corporativa. Con NAT interno y firewall puedes acercarte mucho a ese escenario, aunque hay matices importantes.

Si configuras un switch interno con NAT como en el ejemplo (red 172.168.100.0/24 o 192.168.254.0/24) y conectas la VM ahí, a priori la VM no debería ver la red 192.168.x.x del host salvo por rutas que existan en el sistema o reglas de firewall permisivas.

Si la VM puede hacer ping a la red 192.168.x.x, es que hay rutas que permiten el reenvío entre la red NAT interna y la red física, o reglas de firewall demasiado abiertas. Para endurecer el aislamiento, puedes:

• Comprobar y limpiar rutas en el host que permitan el reenvío entre interfaces (Get-NetRoute y eliminación de rutas estáticas sospechosas).
• Crear reglas de Firewall de Windows en el host para bloquear tráfico origen desde la red interna (por ejemplo 172.168.100.0/24) hacia la red física 192.168.0.0/16, excepto hacia el propio host si lo necesitas.
• Filtrar tráfico en la VM, restringiendo todo lo que no salga hacia la VPN o hacia los destinos estrictamente necesarios, usando perfiles de firewall y reglas de salida restringidas.

Si lo que quieres es que la VM no vea en absoluto al host por IP, una alternativa más radical es usar un switch privado en lugar de interno y proporcionar la salida a Internet a través de una VM firewall/UTM intermedia que haga NAT, manteniendo totalmente desconectado al host de ese segmento.

Otra herramienta de aislamiento muy potente, especialmente cuando compartes el mismo vSwitch para muchas VMs, son las ACL de puerto del switch virtual, que te permiten bloquear tráfico entre VMs que comparten red (aislamiento este-oeste) sin cambiar la topología ni usar VLAN adicionales.

Perfiles de puerto y clasificación de puertos en System Center VMM

Cuando gestionas Hyper-V con System Center Virtual Machine Manager (VMM) o con Windows Admin Center, en lugar de configurar puerto a puerto, puedes usar perfiles de puerto y clasificaciones que definen políticas de red reutilizables.

Los perfiles de puerto de vínculo superior se aplican a adaptadores físicos al desplegar conmutadores lógicos. Ahí defines el algoritmo de equilibrio de carga (basado en puerto de Hyper-V, IPs, puertos de transporte, MAC, o equilibrio dinámico), así como el modo de teaming (Switch Independent, LACP o estático) y qué redes lógicas y sitios de red están asociados al uplink.

Para diseñarlos bien, es aconsejable tener al menos un perfil de uplink por red física o ubicación que tenga VLAN y subredes propias. Si restringes redes lógicas a ciertos grupos de hosts, deberás crear perfiles específicos para esos grupos, garantizando que las VLAN y subredes definidas sean válidas y enrutables desde las NIC a las que se aplican.

Los perfiles de puerto del adaptador de red virtual se aplican a NIC virtuales de las VMs y permiten definir capacidades como ancho de banda mínimo/máximo, descarga de tareas (VMQ, IPsec offload, SR-IOV) y opciones de seguridad (suplantación MAC, protección DHCP, protección de router, etiquetado IEEE 802.1p, direcciones IP gestionadas por invitado, teaming en invitado, etc.).

Sobre esos perfiles se construyen las clasificaciones de puerto, que son etiquetas amigables (por ejemplo, FAST, SLOW, SR-IOV) asociadas a un perfil de puerto concreto. Los administradores o inquilinos, al desplegar una VM, eligen una clasificación y VMM se encarga de aplicar el perfil adecuado al adaptador de red virtual, unificando así el comportamiento de los puertos sin tener que recordar todos los parámetros.

Creación de perfiles de puerto de vínculo superior en VMM

Para definir un perfil de puerto de uplink en VMM, te mueves en el área de Tejido > Redes > Perfiles de puerto y lanzas el asistente para crear un nuevo perfil de puerto de Hyper-V, marcando la opción de vínculo superior.

Dentro del asistente eliges el método de equilibrio de carga: puede ser el predeterminado de host (Hyper-V Port o Dynamic según versión) o forzar uno concreto (puerto de Hyper-V, direcciones IP, puertos de transporte, MAC). Cada opción reparte el tráfico de forma distinta en los miembros del equipo de NIC, lo que impacta en cómo se distribuye la carga entre puertos.

Después seleccionas el modo de formación de equipos: Switch Independent (sin configuraciones específicas en el switch físico), LACP (negociación dinámica) o teaming estático (configuración manual en host y switch). Para muchos escenarios de Hyper-V, Switch Independent es la opción recomendada por su simplicidad y robustez.

En la sección de configuración de red asocias uno o varios sitios de red al perfil de uplink; cada uno enlaza con una red lógica distinta. Es crucial que los sitios compartan el mismo ámbito de grupo de hosts y que las VLAN y subredes sean coherentes con lo que hay realmente en la infraestructura física.

Al aplicar ese perfil a un adaptador físico en un host, estarás determinando qué redes lógicas y qué rangos de VLAN e IP estarán disponibles para las VMs y servicios conectados al conmutador lógico que utilice ese uplink.

Perfiles de puerto del adaptador de red virtual y opciones de seguridad

Crear un perfil de puerto para adaptadores virtuales en VMM implica, además de nombrarlo, pasar por varias secciones de configuración que afectan directamente al aislamiento y comportamiento de los puertos de las VMs.

En la parte de descarga de tráfico puedes habilitar VMQ (Virtual Machine Queue) para que los paquetes destinados a un NIC virtual se dirijan a una cola específica en la NIC física, reducir copias entre el host y la VM, permitir IPsec Task Offload para descargar criptografía a la NIC y activar SR-IOV si tu entorno lo soporta y lo has activado también en el conmutador lógico.

En la pestaña de seguridad del perfil controlas aspectos críticos para el aislamiento como la suplantación de MAC (MAC spoofing), que deberías habilitar solo para casos muy concretos (balanceadores, escenarios de clustering); la protección DHCP, que bloquea servidores DHCP maliciosos dentro de una red de VMs; y la protección de router, que evita anuncios de router no autorizados.

También decides si permites teaming en invitado (para que el sistema operativo invitado agrupe varias NIC virtuales), si autorizarás el etiquetado IEEE 802.1p de prioridad en paquetes salientes y si dejas que la VM gestione direcciones IP adicionales sobre ese adaptador (algo necesario en ciertos clústeres invitados sobre redes virtualizadas).

Por último, configuras el ancho de banda: puedes fijar mínimos y máximos en Mbps o pesos relativos para que el vSwitch priorice unas NIC virtuales frente a otras en entornos sobre-suscritos, otro mecanismo más de control y aislamiento del uso de red por puerto.

Adaptadores de red Hyper-V: tipos, VLAN y opciones avanzadas

Dentro de cada VM de Hyper-V, el adaptador de red que ves en el sistema operativo invitado no es más que la parte visible de un adaptador de red virtual conectado a un puerto del vSwitch. Tienes dos grandes familias: adaptadores sintéticos y adaptadores heredados.

Los adaptadores sintéticos son los recomendados: funcionan con servicios de integración de Hyper-V, ofrecen mejor rendimiento y soportan funciones avanzadas como VLAN etiquetadas o SR-IOV. Son el tipo estándar en VMs de Generación 2 y en la mayoría de sistemas operativos modernos.

Los adaptadores heredados emulan una NIC antigua (tipo Intel 21140) y se usan básicamente para arranques PXE o instalación de sistemas que no tienen drivers para el adaptador sintético. Una vez instalado el sistema y los servicios de integración, lo normal es añadir un adaptador sintético y retirar el heredado.

Para segmentar el tráfico puedes asignar VLAN a nivel de adaptador de red virtual, tanto desde la interfaz gráfica como con PowerShell (Set-VMNetworkAdapter -VMName VM -VlanId ID). De esta forma, cada puerto del switch puede llevar tráfico de VLAN distintas incluso estando conectado al mismo vSwitch.

Entre las funciones avanzadas del adaptador están SR-IOV, VMQ, RSS y varias descargas (checksum TCP, segmentación, etc.), que ayudan a reducir la carga de CPU del host y de las VMs en entornos de alto rendimiento. Como siempre, conviene probar su impacto en tu infraestructura antes de activarlas en masa.

Buenas prácticas de red Hyper-V para rendimiento y aislamiento

Para que todo esto no acabe en un caos, merece la pena seguir algunas buenas prácticas específicas de red en Hyper-V. La primera es usar siempre los drivers más recientes para tus NIC físicas, preferiblemente del fabricante, para aprovechar todas las funciones de hardware y evitar bugs conocidos.

Otra recomendación clara es emplear direcciones IP estáticas en los adaptadores de red de los hosts Hyper-V (y también en las VMs que actúan como servidores) para garantizar que siempre puedes localizarlos y que los registros DNS o dependencias no se rompan tras una renovación DHCP.

En entornos con más de un host, conviene separar físicamente o mediante VLAN los distintos tipos de tráfico: gestión, migración en vivo, almacenamiento (iSCSI o SMB 3.0), tráfico de VMs y pulsos de clúster (CSV/Heartbeat). Cada red debería tener su propio conmutador virtual dedicado o, como mínimo, una VLAN bien definida.

El teaming de NIC (ya sea LBFO clásico o SET -Switch Embedded Teaming-) es otro pilar importante: agrupar varias tarjetas permite repartir tráfico y mejorar la tolerancia a fallos, siempre que no se trate de redes de almacenamiento iSCSI o SMB 3.0 donde se recomienda MPIO u otras estrategias específicas.

Para redes de almacenamiento, Live Migration y CSV, puede ser muy interesante habilitar tramas jumbo (MTU 9000) en todos los dispositivos implicados (NIC, switches, routers) para reducir overhead y mejorar el rendimiento en transferencias grandes y sostenidas.

En las VMs, siempre que el sistema operativo lo permita, utiliza adaptadores sintéticos, limita el uso de adaptadores heredados a escenarios de arranque PXE, y no olvides actualizar los servicios de integración o drivers de Linux Integration Services para sacarles todo el partido.

Por último, mantén un equilibrio razonable entre el ancho de banda de red disponible y la capacidad del almacenamiento compartido. Una SAN rápida con una red lenta o, al revés, una red de 10 Gb con discos lentos, acaban convirtiéndose en cuellos de botella igualmente molestos.

Al combinar correctamente switches virtuales (externos, internos y privados), NAT interno, VLAN, PVLAN, ACL de puerto, perfiles y clasificaciones de puerto en VMM y las opciones de firewall a nivel de host y de VM, puedes construir un entorno Hyper-V en el que cada puerto del switch virtual tiene muy claro qué puede ver y a dónde puede hablar, manteniendo al mismo tiempo un rendimiento sólido y una administración razonable sin volverte loco cada vez que añades una máquina más.