Dieser Abschnitt enthält Informationen zum Verständnis und zur Fehlerbehebung für die verteilte Firewall von VMware NSX 6.x.

Problem

  • Die Veröffentlichung von Regeln für die verteilte Firewall scheitert.
  • Die Aktualisierung von Regeln für die verteilte Firewall scheitert.

Ursache

Überprüfen Sie, ob die einzelnen unten angegebenen Fehlerbehebungsschritte für Ihre Umgebung gelten. Jeder Schritt enthält Anleitungen oder einen Link zu einem Dokument, mit denen Sie mögliche Ursachen beseitigen und korrigierende Maßnahmen wie erforderlich vornehmen können. Die Schritte werden in der für die Isolierung des Problems und für die Ermittlung der entsprechenden Lösung am geeignetsten erscheinenden Reihenfolge aufgeführt. Versuchen Sie nach jedem Schritt erneut, die Regeln für die verteilte Firewall zu aktualisieren bzw. zu veröffentlichen.

Lösung

  1. Stellen Sie sicher, dass die NSX-VIBs auf jedem ESXi-Host im Cluster erfolgreich installiert worden sind. Dazu führen Sie auf jedem ESXi-Host im Cluster die nachfolgend aufgeführten Befehle aus. 
    # esxcli software vib list | grep vsip
esx-vsip                       6.0.0-0.0.4744062  VMware  VMwareCertified   2017-01-04 

# esxcli software vib list | grep vxlan
esx-vxlan                      6.0.0-0.0.4744062  VMware  VMwareCertified   2017-01-04
    Ab NSX 6.3.3 mit ESXi 6.0 oder höher werden die VIBs „esx-vxlan“ und „esx-vsip“ durch „esx-nsxv“ ersetzt. 
    # esxcli software vib list | grep nsxv
esx-nsxv                       6.0.0-0.0.6216823  VMware  VMwareCertified   2017-08-10
  2. Überprüfen Sie, ob auf den ESXi-Hosts der vShield-Stateful-Firewall-Dienst ausgeführt wird.
    Beispiel: 
    # /etc/init.d/vShield-Stateful-Firewall status

vShield-Stateful-Firewall is running
  3. Überprüfen Sie, ob der Nachrichtenbus ordnungsgemäß mit dem NSX Manager kommuniziert.
    Dieser Vorgang wird automatisch vom Watchdog-Skript gestartet, das den Vorgang auch neu startet, wenn er aus einem unbekannten Grund beendet wird. Führen Sie diesen Befehl auf jedem ESXi-Host im Cluster aus.
    Beispiel: 
    # ps | grep vsfwd

107557 107557 vsfwd /usr/lib/vmware/vsfw/vsfwd

    Es sollten mindestens 12 ausgeführte vsfwd-Vorgänge in der Befehlsausgabe vorhanden sein. Wenn weniger ausgeführte Vorgänge vorhanden sind (wahrscheinlich nur 2), wird vsfwd nicht ordnungsgemäß ausgeführt.

  4. Überprüfen Sie, ob Port 5671 in der Firewallkonfiguration für die Kommunikation geöffnet ist.
    Dieser Befehl stellt die VSFWD-Konnektivität zum RabbitMQ-Broker dar. Führen Sie diesen Befehl auf den ESXi-Hosts aus, um eine Liste der Verbindungen zwischen dem vsfwd-Vorgang auf dem ESXi-Host und dem NSX Manager anzuzeigen. Stellen Sie sicher, dass der Port 5671 in jeder externen Firewall der Umgebung für die Kommunikation geöffnet ist. Zudem sollten mindestens zwei Verbindungen an Port 5671 vorhanden sein. An Port 5671 können mehr Verbindungen bestehen, da auf dem ESXi-Host virtuelle NSX Edge-Maschinen bereitgestellt sind, die auch Verbindungen mit dem RMQ-Broker herstellen.
    Beispiel: 
    # esxcli network ip connection list |grep 5671

tcp         0       0  192.168.110.51:30133            192.168.110.15:5671   ESTABLISHED  10949155  newreno  vsfwd
tcp         0       0  192.168.110.51:39156            192.168.110.15:5671   ESTABLISHED  10949155  newreno  vsfwd
  5. Stellen Sie sicher, dass VSFWD konfiguriert ist.

    Dieser Befehl sollte die IP-Adresse des NSX Manager anzeigen. 

    # esxcfg-advcfg -g /UserVars/RmqIpAddress
  6. Wenn Sie für diesen ESXi-Host ein Hostprofil verwenden, stellen Sie sicher, dass die RabbitMQ-Konfiguration nicht im Hostprofil festgelegt ist.
    Siehe:
  7. Überprüfen Sie, ob die RabbitMQ-Anmeldedaten des ESXi-Hosts nicht mit denen von NSX Manager synchronisiert sind. Laden Sie die Tech-Support-Protokolle für NSX Manager herunter. Nachdem Sie alle Tech-Support-Protokolle für NSX Manager erfasst haben, suchen Sie in den Protokollen nach Einträgen folgender Art:
    Replace host-420 with the host-id of the suspect host (Host-420 durch Host-ID des verdächtigen Hosts ersetzen). 
    PLAIN login refused: user 'uw-host-420' - invalid credentials.
  8. Wenn Sie solche Einträge in den Protokollen für den verdächtigen ESXi-Host finden, synchronisieren Sie den Nachrichtenbus erneut.

    Verwenden Sie zum erneuten Synchronisieren des Nachrichtenbus die REST-API. Erfassen Sie die Protokolle unmittelbar nach der erneuten Synchronisierung des Nachrichtenbus, um das Problem besser verstehen zu können. 

    HTTP Method : POST 
Headers , 
Authorization : base64encoded value of username password
Accept : application/xml
Content-Type : application/xml
Request:

POST https://NSX_Manager_IP/api/2.0/nwfabric/configure?action=synchronize

Request Body:

<nwFabricFeatureConfig>
<featureId>com.vmware.vshield.vsm.messagingInfra</featureId>
<resourceConfig>
<resourceId>{HOST/CLUSTER MOID}</resourceId>
</resourceConfig>
</nwFabricFeatureConfig>
  9. Verwenden Sie den Befehl export host-tech-support <host-id> scp <uid@ip:/path> zum Erfassen hostspezifischer Firewallprotokolle.
    Beispiel: 
    nsxmgr# export host-tech-support host-28 scp [email protected]
Generating logs for Host: host-28...
  10. Überprüfen Sie mit dem Befehl show dfw host host-id summarize-dvfilter, ob die Firewallregeln auf einem Host bereitgestellt sind und auf die virtuellen Maschinen angewendet werden.
    In der Ausgabe zeigt der Eintrag module: vsip an, dass das Modul „verteilte Firewall“ geladen wurde und ausgeführt wird. Der Eintrag name gibt die Firewall an, die auf jeder vNIC ausgeführt wird.

    Zur Ermittlung der Host-IDs können Sie mit dem Befehl show dfw cluster all die IDs der Cluster-Domäne und anschließend mit dem Befehl show dfw cluster domain-id die Host-IDs abrufen.

    Beispiel: 
    # show dfw host host-28 summarize-dvfilter

Fastpaths:
agent: dvfilter-faulter, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: dvfilter
agent: ESXi-Firewall, refCount: 5, rev: 0x1010000, apiRev: 0x1010000, module: esxfw
agent: dvfilter-generic-vmware, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: dvfilter-generic-fastpath
agent: dvfilter-generic-vmware-swsec, refCount: 4, rev: 0x1010000, apiRev: 0x1010000, module: dvfilter-switch-security
agent: bridgelearningfilter, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: vdrb
agent: dvfg-igmp, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: dvfg-igmp
agent: vmware-sfw, refCount: 4, rev: 0x1010000, apiRev: 0x1010000, module: vsip

Slowpaths:

Filters:
world 342296 vmm0:2-vm_RHEL63_srv_64-shared-846-3f435476-8f54-4e5a-8d01-59654a4e9979 vcUuid:'3f 43 54 76 8f 54 4e 5a-8d 01 59 65 4a 4e 99 79'
 port 50331660 2-vm_RHEL63_srv_64-shared-846-3f435476-8f54-4e5a-8d01-59654a4e9979.eth1
  vNic slot 2
   name: nic-342296-eth1-vmware-sfw.2
   agentName: vmware-sfw
   state: IOChain Attached
   vmState: Detached
   failurePolicy: failClosed
   slowPathID: none
   filter source: Dynamic Filter Creation
  vNic slot 1
   name: nic-342296-eth1-dvfilter-generic-vmware-swsec.1
   agentName: dvfilter-generic-vmware-swsec
   state: IOChain Attached
   vmState: Detached
   failurePolicy: failClosed
   slowPathID: none
   filter source: Alternate Opaque Channel
 port 50331661 (disconnected)
  vNic slot 2
   name: nic-342296-eth2-vmware-sfw.2 <======= DFW filter
   agentName: vmware-sfw       
   state: IOChain Detached
   vmState: Detached
   failurePolicy: failClosed
   slowPathID: none
   filter source: Dynamic Filter Creation
 port 33554441 2-vm_RHEL63_srv_64-shared-846-3f435476-8f54-4e5a-8d01-59654a4e9979
  vNic slot 2
   name: nic-342296-eth0-vmware-sfw.2<========= DFW filter
   agentName: vmware-sfw    
   state: IOChain Attached
   vmState: Detached
   failurePolicy: failClosed
   slowPathID: none
   filter source: Dynamic Filter Creation
  11. Führen Sie den Befehl show dfw host hostID filter filterID rules aus.
    Beispiel: 
    # show dfw host host-28 filter nic-79396-eth0-vmware-sfw.2 rules
 
ruleset domain-c33 {
  # Filter rules
  rule 1012 at 1 inout protocol any from addrset ip-securitygroup-10 to addrset ip-securitygroup-10 drop with log;
  rule 1013 at 2 inout protocol any from addrset src1013 to addrset src1013 drop;
  rule 1011 at 3 inout protocol tcp from any to addrset dst1011 port 443 accept;
  rule 1011 at 4 inout protocol icmp icmptype 8 from any to addrset dst1011 accept;
  rule 1010 at 5 inout protocol tcp from addrset ip-securitygroup-10 to addrset ip-securitygroup-11 port 8443 accept;
  rule 1010 at 6 inout protocol icmp icmptype 8 from addrset ip-securitygroup-10 to addrset ip-securitygroup-11 accept;
  rule 1009 at 7 inout protocol tcp from addrset ip-securitygroup-11 to addrset ip-securitygroup-12 port 3306 accept;
  rule 1009 at 8 inout protocol icmp icmptype 8 from addrset ip-securitygroup-11 to addrset ip-securitygroup-12 accept;
  rule 1003 at 9 inout protocol ipv6-icmp icmptype 136 from any to any accept;
  rule 1003 at 10 inout protocol ipv6-icmp icmptype 135 from any to any accept;
  rule 1002 at 11 inout protocol udp from any to any port 67 accept;
  rule 1002 at 12 inout protocol udp from any to any port 68 accept;
  rule 1001 at 13 inout protocol any from any to any accept;
}

ruleset domain-c33_L2 {
  # Filter rules
  rule 1004 at 1 inout ethertype any from any to any accept;
  12. Führen Sie den Befehl show dfw host hostID filter filterID addrsets aus.
    Beispiel: 
    # show dfw host host-28 filter nic-342296-eth2-vmware-sfw.2 addrsets 

addrset dst1011 {
ip 172.16.10.10,
ip 172.16.10.11,
ip 172.16.10.12,
ip fe80::250:56ff:feae:3e3d,
ip fe80::250:56ff:feae:f86b,
}
addrset ip-securitygroup-10 {
ip 172.16.10.11,
ip 172.16.10.12,
ip fe80::250:56ff:feae:3e3d,
ip fe80::250:56ff:feae:f86b,
}
addrset ip-securitygroup-11 {
ip 172.16.20.11,
ip fe80::250:56ff:feae:23b9,
}
addrset ip-securitygroup-12 {
ip 172.16.30.11,
ip fe80::250:56ff:feae:d42b,
}
addrset src1013 {
ip 172.16.10.12,
ip 172.17.10.11,
ip fe80::250:56ff:feae:cf88,
ip fe80::250:56ff:feae:f86b,
}
  13. Wenn Sie die obigen Schritte zur Fehlerbehebung durchgeführt haben und dennoch keine Firewallregeln auf den virtuellen Hostmaschinen veröffentlichen können, erzwingen Sie über die Benutzeroberfläche von NSX Manager oder über den nachfolgend aufgeführten REST-API-Aufruf eine Synchronisierung auf Hostebene. 
    URL : [https:]https://<nsx-mgr-ip>/api/4.0/firewall/forceSync/<host-id>
HTTP Method : POST 
Headers , 
Authorization : base64encoded value of username password
Accept : application/xml
Content-Type : application/xml

Lösung

Anmerkungen:

  • Stellen Sie sicher, dass VMware Tools auf den virtuellen Maschinen ausgeführt wird, wenn in den Firewallregeln keine IP-Adressen verwendet werden. Weitere Informationen finden Sie unter https://kb.vmware.com/kb/2084048.

    In VMware NSX 6.2.0 wurde die Option zur Erkennung der IP-Adresse der VM mithilfe von DHCP-Snooping oder ARP-Snooping eingeführt. Mit diesen neuen Erkennungsmechanismen kann NSX die auf IP-Adressen basierten Sicherheitsregeln auf virtuellen Maschinen erzwingen, auf denen VMware Tools nicht installiert ist. Weitere Informationen finden Sie in den Versionshinweisen zu NSX 6.2.0.

    Die verteilte Firewall wird aktiviert, sobald der Hostvorbereitungsvorgang abgeschlossen ist. Wenn eine virtuelle Maschine grundsätzlich keine verteilte Firewall benötigt, kann sie der Ausschlussliste hinzugefügt werden (standardmäßig werden NSX Manager, NSX Controller und Edge Services Gateways automatisch von der Funktion der Verteilten Firewall ausgeschlossen). Es besteht die Möglichkeit, dass der Zugriff auf vCenter Server nach dem Erstellen einer Deny-All-Regel (Alles-Verweigern-Regel) in der Verteilten Firewall blockiert wird. Weitere Informationen finden Sie unter https://kb.vmware.com/kb/2079620.

  • Wenn Sie für die Fehlerbehebung der Verteilten Firewall von NSX 6.x von VMware Unterstützung vom technischen Support von VMware benötigen, ist Folgendes erforderlich:
    • Ausgabe des Befehls show dfw host hostID summarize-dvfilter auf jedem ESXi-Host im Cluster.
    • verteilte Firewall-Konfiguration der Registerkarte Networking and Security > Firewall > Allgemein (Networking and Security > Firewall > General) durch Klicken auf Konfiguration exportieren (Export Configuration). Damit wird die verteilte Firewall-Konfiguration in ein XML-Format exportiert.
    • NSX Manager-Protokolle. Weitere Informationen finden Sie unter https://kb.vmware.com/kb/2074678.
    • vCenter Server-Protokolle. Weitere Informationen finden Sie unter https://kb.vmware.com/kb/1011641.