IP externa invitada de HyperV: ¿RRAS NAT en el host VS acceso directo a la red externa con Microsoft Virtual Switch?

IP externa invitada de HyperV: ¿RRAS NAT en el host VS acceso directo a la red externa con Microsoft Virtual Switch?

Tengo un host Win2008 R2 HyperV con un adaptador físico que ejecuta varias máquinas virtuales. Tengo una subred de direcciones IP externas: xxx208/255.255.255.240

Solía ​​tener la siguiente configuración:

El sistema operativo host tendría funciones AD DC, HyperV, RRAS, DHCP y DNS. Al adaptador físico se le asignarían explícitamente todas las direcciones IP disponibles:

xxx210 / 255.255.255.240

...

xxx221 / 255.255.255.240

La red HyperV tendría una red externa creada, pero con la opción "Permitir que el sistema operativo de administración comparta el adaptador" activada; de esta manera también podría asignar una IP pública al sistema operativo host:

ingrese la descripción de la imagen aquí

HyperV creó otro adaptador de red que usé para la LAN interna (192.168.2.0/255). RRAS se configuró para enrutamiento NAT y LAN, y realiza NAT para invitados de la siguiente manera:

xxx210 -> 192.168.2.10, Permitir sesiones entrantes = SÍ

...

xxx221 -> 192.168.2.21, Permitir sesiones entrantes = SÍ

Básicamente, todas las máquinas virtuales invitadas no tenían una dirección IP externa, pero para ellas esto no importaba: todavía tenían acceso a Internet y eran accesibles desde el exterior.

luego comenzamos a tener problemas con RRAS, VPN, etc., etc., así que leí un poco y leí que el esquema NAT no es bueno ( could someone comment on this btw?) y que debería virtualizar el adaptador físico para dar a las máquinas virtuales invitadas acceso directo a la red externa. Muy bien, hice esto.

Aquí está la configuración actual:

Eliminé "Permitir que el sistema operativo de administración comparta el adaptador" del adaptador externo y agregué una segunda red interna a HyperV.

ingrese la descripción de la imagen aquí

Luego tuve que agregar un segundo adaptador de red a cada VM invitada y luego establecer explícitamente la dirección IP pública para cada una. Eso se hizo y funciona bien. La función RRAS se eliminó del host.

preguntas:

  1. ¿Hice lo correcto? Mi sentimiento interno dice que sí, ya que aquí tenemos menos "piezas" (o al menos eso parece), pero sólo quiero obtener algunas opiniones autorizadas.

  2. ¿Algún problema que deba tener en cuenta con la configuración actual frente a la anterior? ¿Alguna práctica recomendada que deba seguir después de configurar la red como se describe anteriormente?

  3. Probablemente la pregunta más importante para mí. En ambos escenarios, el firewall se ejecuta en la máquina virtual invitada y nada ha cambiado después del cambio. Y tengo entendido que NAT no filtra el tráfico: todo va directamente a los invitados. SIN EMBARGO, justo después del cambio, empiezo a recibir los siguientes errores en el registro (en nuestro servidor VM de Exchange):

La autenticación entrante falló con el error LogonDenied para el EXCHANGE predeterminado del conector de recepción. El mecanismo de autenticación es Ntlm. La dirección IP de origen del cliente que intentó autenticarse en Microsoft Exchange es [200.195.42.7].

Esto implica para mí que en la nueva configuración la máquina virtual quedó "más" expuesta a amenazas externas, pero no entiendo por qué este no fue el caso para el escenario NATed. Lo verifiqué: no hay NINGUNO error como ese antes del cambio. ¿Por qué recibo esos errores ahora? ¿Qué ha cambiado desde el punto de vista de la red?

información relacionada