Servidor real, Múltiples direcciones IP, Servidor virtual HyperV, Cómo particionar direcciones IP entre NIC reales y virtuales

Servidor real, Múltiples direcciones IP, Servidor virtual HyperV, Cómo particionar direcciones IP entre NIC reales y virtuales

Este es un problema un poco difícil de explicar sin la misma información básica básica. Intentaré perfeccionar la pregunta más adelante según sea necesario.


Originalmente, tengo un único servidor alojado (Win 2008R2) con el siguiente rango de 8 direcciones IP.

- Single NIC ( IP: x.x.128.72 -> x.x.128.79 // Subnet: x.x.255.192 // GW: x.x.128.65 )

Después de instalar Hyper-V y configurar un único servidor virtual en la misma caja, quise asignar una de las direcciones IP al servidor virtual, dejando todo lo demás funcionando normalmente.

--

En primer lugar, intenté usar la red "Externa", pero (incluso después de configurar las direcciones IP en el "Adaptador virtual", similar aAquípero tuvo problemas para poner en funcionamiento la red).

Necesitaba mantener el servidor en funcionamiento (de lo contrario, habría dedicado más tiempo a seguir este enfoque)

P1... ¿Fue esto algo sensato? ¿Debería haber seguido por este camino?

--

Luego decidí probar un enfoque diferente: configurar la red HyperV en "Interna" (visible para el sistema operativo de administración)

- Physical NIC ( IP: x.x.128.72 to .75 // Subnet: x.x.255.192 // GW: x.x.128.65 )
- Virtual NIC ( IP: x.x.128.78 // Subnet: x.x.255.252 // GW: x.x.128.72 ) 
     - Gateway was the same as the IP of the physical NIC )
- Virtual OS-NIC ( IP: x.x.128.77 // Subnet: x.x.255.252 //  GW: x.x.128.78 ) 
     - Gateway was the same as the IP of the host virtual-NIC )

--

Sorprendentemente, este enfoque realmente funcionó y pude conectarme desde todo lo siguiente: - Internet hacia/desde la NIC física (xx128.72) - NIC física (xx128.72) a NIC-OS-virtual (xx128.77) por ejemplo, prueba mediante ping + FTP - Internet hacia/desde virtual-OS-NIC (xx128.72)

--

El problema que tengo es que este enfoque parece durar poco tiempo (unas pocas horas).

Después de este tiempo, parece que pierdo la capacidad de conectarme desde Virtual-OS-NIC hacia/desde Internet (pero aún puedo conectarme desde el sistema operativo host al sistema operativo virtual y desde el sistema operativo host a Internet)

He vuelto a probar esto un par de veces con los mismos resultados... Dejo el servidor encendido durante unas horas (por ejemplo, durante la noche) y cuando vuelvo por la mañana, el sistema operativo virtual pierde la capacidad de enrutar a La Internet

--

No estoy muy seguro de qué mirar a continuación (o si estoy haciendo esto de manera completamente equivocada)

Un "posible elemento relevante" es que el sistema operativo host también ejecuta RRAS (enrutamiento y acceso remoto), pero esto es solo para ejecutar una VPN simple.

--

P2: ¿Debería considerar el trigo a continuación? (Algunas buenas referencias/recomendaciones sobre qué probar)

Agradecería cualquier idea o comentario (incluso si me dices que estoy haciendo esto de manera incorrecta)

--

*EDITAR - Segundo intento de usar "Externo" *

Después de volver a intentarlo con el enfoque "Externo", nuevamente NO obtuve acceso a la red...

Luego desmarqué "Habilitar identificación de LAN virtual para el sistema operativo de administración"... Hola, listo, todo cobró vida.

La redacción crítica estaba oculta en el enlace "más sobre la gestión de redes virtuales" que dice

Especifica un número de identificación que se puede utilizar para aislar el tráfico de red del sistema operativo de administración.

Resultado final...ÉXITO(pero sin respuesta de por qué funcionó PARCIALMENTE por tiempo limitado)

Más tarde encontré interesante la siguiente publicación de blog de MSDN...Comprender las VLAN de Hyper-V

Respuesta1

Hyper-V no es en realidad un complemento de Windows, sino un hipervisor completo que toma el control. El sistema operativo instalado originalmente se convierte en una partición raíz, subordinada a Hyper-V. Entonces, lo que era el sistema operativo base ahora es técnicamente una máquina virtual especial. En esa medida, se puede pasar hardware a la máquina virtual "especial" (para dar la apariencia de ser un sistema operativo normal). Esta es la configuración predeterminada para casi todo el hardware después de habilitar Hyper-V. Sin embargo, cuando crea una red virtual para Hyper-V que está conectada a una NIC física, Hyper-V toma posesión de la NIC y ya no pasa a través de ella.

La configuración de su NIC debe ser la siguiente:

La NIC física debe tener habilitado únicamente el protocolo "Microsoft Virtual Network Switch" (la única excepción es cuando no se trata de una NIC física real, como un equipo configurado por software, por lo general tendrá algún tipo de otro protocolo que no se puede desactivado).

En el Administrador de red virtual de Hyper-V Manager; cree una "Red", esto creará un conmutador de red virtual en Hyper-V. Conviértalo en uno externo, conectado a la NIC física; también marque la casilla para permitir el acceso al sistema operativo de administración. Esto creará una nueva vNIC para el sistema operativo base (recuerde que en realidad es una VM especial, por lo que está agregando una vNIC a esta VM...). Es posible que la nueva NIC deba configurarse para las IP extraídas de la antigua NIC física (depende de la versión de Hyper-V que esté usando, si lo hará automáticamente o no).

Cree máquinas virtuales como desee, agrégueles vNIC y adjunte esas vNIC a la red virtual adecuada.

Las redes virtuales externas están conectadas a una NIC física. Permiten que las máquinas virtuales se conecten a las NIC físicas. Las redes virtuales internas siempre crean una nueva vNIC para el sistema operativo de administración (no hay ninguna casilla de verificación, simplemente siempre se hace). Esto permite que las máquinas virtuales se comuniquen con el sistema operativo base, pero no con ninguna NIC física. Las redes virtuales privadas son solo para máquinas virtuales y no se conectan al sistema operativo de administración de ninguna manera.

También mencionaste problemas para mantener todo funcionando. Si no está utilizando chips NIC de calidad de servidor (particularmente Intel, Broadcom, QLogic, Emulex, NexGen, Mellanox, etc.), espere problemas. Del mismo modo, asegúrese de tener el firmware más reciente. Si está ejecutando chips Via o Realtek, puede ahorrar tiempo y deshacerse de la idea de hipervisores confiables de nivel 1 (Hyper-V, ESXi, KVM, etc.).

información relacionada