L'agente di NSX-T installato nei server fornisce connettività e sicurezza ai carichi di lavoro bare-metal.

Utilizzare Ansible per configurare le interfacce virtuali e NSX-T in Windows Server 2016 e proteggere i carichi di lavoro tramite NSX-T.

In questa procedura, stabilire la connettività tra i carichi di lavoro e NSX Manager. Configurare quindi le regole DFW per proteggere il traffico in ingresso e uscita in esecuzione tra i carichi di lavoro bare-metal virtuali o fisici e Windows Server 2016 o 2019.

Prerequisiti

  • Configurare le impostazioni del proxy sul server fisico.

Procedura

  1. Abilitare Windows Remote Management (WinRM) su Windows Server 2016 per consentire al Windows Server di interagire con software e hardware di terze parti. Per abilitare il servizio WinRM con un certificato autofirmato.
    1. Eseguire PS$ wget -o ConfigureWinRMService.ps1 https://raw.githubusercontent.com/vmware/bare-metal-server-integration-with-nsxt/master/bms-ansible-nsx/windows/ConfigureWinRMService.ps1.
    2. Eseguire PS$ powershell.exe -ExecutionPolicy ByPass -File ConfigureWinRMService.ps1.
  2. Configurare WinRM per l'utilizzo di HTTPS. La porta predefinita utilizzata per HTTPS è 5986.
    1. Eseguire PowerShell come amministratore.
    2. Eseguire winrm quickconfig.
    3. Eseguire winrm set winrm/config/service/auth ‘@{Basic=“true”}’.
    4. Eseguire winrm set winrm/config/service ‘@{AllowUnencrypted=“true”}’.
    5. Eseguire winrm create winrm/config/Listener?Address=*+Transport=HTTPS ‘@{Hostname=“win16-colib-001”;CertificateThumbprint=“[output of the 2nd command]"}’.
    6. Verificare la configurazione di WinRM. Eseguire winrm e winrm/config/listener.
  3. Aggiungere il server bare-metal come nodo di trasporto autonomo. Vedere Configurazione di un server fisico come nodo di trasporto dalla GUI.
  4. Verificare se in Windows Server vengono creati bridge OVS. Il bridge OVS connette l'interfaccia virtuale dell'applicazione al commutatore NSX nel nodo di trasporto.
    ovs-vsctl show
    L'output deve mostrare i bridge creati dal componente host nsxswitch e nsx managed. Il bridge nsxswitch corrisponde al nodo di trasporto creato. Il bridge nsx managed viene creato per l'interfaccia virtuale dell'applicazione nell'host di Windows. Queste voci di bridge indicano che viene stabilito un canale di comunicazione tra il commutatore NSX e il listener remoto di Windows.
  5. Nel nodo di trasporto con supporto overlay, verificare:
    • L'indirizzo IP statico viene riportato come indirizzo IP del segmento di overlay a cui è connesso il carico di lavoro del Windows Server.
    • I tunnel GENEVE vengono creati tra il commutatore NSX e il componente host gestito da NSX nell'host Windows.
    Nota: Allo stesso modo, in un nodo di trasporto con supporto VLAN, verificare che l'indirizzo IP statico venga riportato come indirizzo IP del segmento VLAN a cui è connesso il carico di lavoro del Windows Server.
  6. In Windows, personalizzare il driver OVSIM per Windows Server per creare due nuove schede di rete, ovvero interfacce virtuali dell'applicazione ed endpoint del tunnel virtuale (VTEP) per il carico di lavoro con supporto overlay.
    $:> Get-NetAdapter
    vEthernet1-VTEP: utilizzato per l'interfaccia VTEP con supporto overlay. Non necessario per un carico di lavoro con supporto VLAN.
    vEthernet1-VIF1: utilizzato per l'interfaccia virtuale o l'interfaccia dell'applicazione del Windows Server bare-metal.
  7. Per verificare le schede di rete, passare a Windows Server ed eseguire Get-NetAdapter.
  8. Verificare la connettività tra l'applicazione, Windows Server bare-metal e NSX Manager.
  9. Aggiungere e pubblicare regole DFW L2 o L3 per il carico di lavoro bare-metal con overlay o supporto VLAN.
  10. Verificare che il traffico in ingresso e in uscita tra carichi di lavoro virtuali o fisici e i carichi di lavoro bare-metal si muova in base alle regole DFW pubblicate.