Seguridad de las cargas de trabajo en servidores nativos Windows Server 2016/2019

El agente NSX-T instalado en los servidores proporciona conectividad y seguridad a las cargas de trabajo nativas.

En este procedimiento, establezca la conectividad entre las cargas de trabajo y NSX Manager. A continuación, configure las reglas de DFW para proteger el tráfico de entrada y salida que se ejecuta entre las cargas de trabajo virtuales o físicas y las nativas de Windows Server 2016 o 2019.

Requisitos previos

• Configure sus propios ajustes de proxy en el servidor físico.

Procedimiento

1. Habilite la Administración remota de Windows (WinRM) en Windows Server 2016 para que el servidor de Windows pueda interoperar con software y hardware de terceros. Para habilitar el servicio WinRM con un certificado autofirmado:
   1. Ejecute PS$ wget -o ConfigureWinRMService.ps1 https://raw.githubusercontent.com/vmware/bare-metal-server-integration-with-nsxt/master/bms-ansible-nsx/windows/ConfigureWinRMService.ps1.
   2. Ejecute PS$ powershell.exe -ExecutionPolicy ByPass -File ConfigureWinRMService.ps1.
2. Configure WinRM para que use HTTPS. El puerto predeterminado utilizado para HTTPS es el 5986.
   1. Ejecute PowerShell como administrador.
   2. Ejecute winrm quickconfig.
   3. Ejecute winrm set winrm/config/service/auth ‘@{Basic=“true”}’.
   4. Ejecute winrm set winrm/config/service ‘@{AllowUnencrypted=“true”}’.
   5. Ejecute winrm create winrm/config/Listener?Address=*+Transport=HTTPS ‘@{Hostname=“win16-colib-001”;CertificateThumbprint=“[output of the 2nd command]"}’.
   6. Verifique la configuración de WinRM. Ejecute winrm e winrm/config/listener.
3. Agregue el servidor nativo como nodo de transporte independiente. Consulte Configurar un servidor físico como nodo de transporte desde la interfaz gráfica de usuario.
4. Verifique si se crean puentes de OVS en el servidor de Windows. El puente de OVS conecta la interfaz virtual de la aplicación con el conmutador de NSX en el nodo de transporte.
   ovs-vsctl show
   El resultado debe mostrar los puentes creados a partir de nsxswitch y el componente de host nsx managed. El puente nsxswitch es para el nodo de transporte creado. El puente nsx managed se crea para la interfaz virtual de la aplicación en el host de Windows. Estas entradas de puentes indican que se estableció el canal de comunicación entre el conmutador de NSX y el agente de escucha remoto de Windows.
5. En el nodo de transporte respaldado por superposición, compruebe lo siguiente:
   • La dirección IP estática se refleja como dirección IP del segmento de superposición al que está conectada la carga de trabajo de Windows Server.
   • Se crean túneles GENEVE entre el conmutador de NSX y el componente de host administrado de NSX en el host de Windows.
   Nota: De forma similar, en un nodo de transporte respaldado por VLAN, compruebe que la dirección IP estática se refleja como dirección IP del segmento de VLAN al que está conectada la carga de trabajo de Windows Server.
6. En Windows, personalice el controlador OVSIM para que el servidor de Windows cree dos nuevos adaptadores de red: las interfaces virtuales de la aplicación y el endpoint de túnel virtual (VTEP) para la carga de trabajo respaldada por superposición.
   $:> Get-NetAdapter
   vEthernet1-VTEP: se utiliza para la interfaz de VTEP respaldada por superposición. No se necesita para una carga de trabajo respaldada por VLAN.
   vEthernet1-VIF1: se utiliza para la interfaz virtual o interfaz de aplicación del servidor de Windows nativo.
7. Para verificar los adaptadores de red, vaya al servidor de Windows y ejecute Get-NetAdapter.
8. Compruebe la conectividad entre la aplicación, el servidor nativo de Windows y NSX Manager.
9. Agregue y publique reglas de DFW de capa 2 o capa 3 para la carga de trabajo nativa respaldada por superposición o VLAN.
10. Compruebe que el tráfico de entrada y salida entre las cargas de trabajo virtuales o físicas y las cargas de trabajo nativas fluye de acuerdo con las reglas de DFW publicadas.