Der NSX-T-Agent, der auf den Servern installiert ist, bietet Konnektivität und Sicherheit für die Bare Metal-Arbeitslasten.
In diesem Verfahren stellen Sie die Verbindung zwischen den Arbeitslasten und NSX Manager her. Konfigurieren Sie anschließend DFW-Regeln, um eingehenden und ausgehenden Datenverkehr zwischen virtuellen oder physischen Arbeitslasten und Bare-Metal-Arbeitslasten unter Windows Server 2016 oder 2019 zu sichern.
Voraussetzungen
- Konfigurieren Sie Ihre eigenen Proxy-Einstellungen auf dem physischen Server.
Prozedur
- Aktivieren Sie die Windows-Remoteverwaltung (WinRM) unter Windows Server 2016, damit der Server unter Windows mit Software und Hardware von Drittanbietern interagieren kann. So aktivieren Sie den WinRM-Dienst mit einem selbstsignierten Zertifikat.
- Konfigurieren Sie WinRM für die Verwendung von HTTPS. Die für HTTPS verwendete Standardport ist 5986.
- Führen Sie PowerShell als Admin aus.
- Führen Sie winrm quickconfig aus.
- Führen Sie winrm set winrm/config/service/auth ‘@{Basic=“true”}’ aus.
- Führen Sie winrm set winrm/config/service ‘@{AllowUnencrypted=“true”}’ aus.
- Führen Sie winrm create winrm/config/Listener?Address=*+Transport=HTTPS ‘@{Hostname=“win16-colib-001”;CertificateThumbprint=“[output of the 2nd command]"}’ aus.
- Überprüfen Sie die Konfiguration von WinRM. Führen Sie winrm e winrm/config/listener aus.
- Fügen Sie den Bare Metal-Server als eigenständigen Transportknoten hinzu. Siehe Konfigurieren eines physischen Servers als Transportknoten über die Benutzeroberfläche.
- Überprüfen Sie, ob OVS-Bridges auf dem Server unter Windows erstellt wurden. Die OVS-Bridge verbindet die virtuelle Anwendungsschnittstelle mit dem NSX-Switch auf dem Transportknoten.
ovs-vsctl show
Die Ausgabe muss die Bridges anzeigen, die von der Hostkomponente
nsxswitch und
nsx managed erstellt wurden. Die Bridge
nsxswitch ist für den erstellten Transportknoten vorgesehen. Die Bridge
nsx managed wird für die virtuelle Anwendungsschnittstelle auf dem Host unter Windows erstellt. Diese Bridge-Einträge geben an, dass der Kommunikationskanal zwischen dem NSX-Switch und Windows-Remote-Listener hergestellt wurde.
- Überprüfen Sie auf dem Overlay-gesicherten Transportknoten Folgendes:
- Die statische IP-Adresse wird als IP-Adresse des Overlay-Segments wiedergegeben, mit dem die Windows Server-Arbeitslast verbunden ist.
- Die GENEVE-Tunnel werden zwischen der Hostkomponente „NSX switch“ und „NSX managed“ auf dem Host unter Windows erstellt.
Hinweis: Überprüfen Sie ebenso auf einem VLAN-gesicherten Transportknoten, ob die statische IP-Adresse als IP-Adresse des VLAN-Segments angezeigt wird, mit dem die Windows Server-Arbeitslast verbunden ist.
- Passen Sie unter Windows den OVSIM-Treiber für den Server unter Windows an, um zwei neue Netzwerkadapter zu erstellen: virtuelle Anwendungsschnittstellen und virtueller Tunnel-Endpoint (VTEP) für die Overlay-gesicherte Arbeitslast.
$:> Get-NetAdapter
vEthernet1-VTEP: Wird für die Overlay-gesicherte VTEP-Schnittstelle verwendet. Bei einer VLAN-gesicherten Arbeitslast nicht erforderlich.
vEthernet1-VIF1: Wird für die virtuelle Schnittstelle oder Anwendungsschnittstelle des Bare Metal-Servers unter Windows verwendet.
- Um Netzwerkadapter zu überprüfen, wechseln Sie zum Server unter Windows und führen Sie Get-NetAdapter aus.
- Überprüfen Sie die Konnektivität zwischen der Anwendung, dem Bare Metal-Server unter Windows und NSX Manager.
- Fügen Sie L2- oder L3-DFW-Regeln für die Overlay- oder VLAN-gesicherte Bare Metal-Arbeitslast hinzu und veröffentlichen Sie die Regeln.
- Überprüfen Sie, ob der eingehende und ausgehende Datenverkehr zwischen virtuellen oder physischen Arbeitslasten und den Bare Metal-Arbeitslasten gemäß der veröffentlichten DFW-Regeln fließt.