Sie können ein HTTPS-Anwendungsprofil für drei HTTPS-Datenverkehrstypen erstellen: SSL Passthrough, HTTPS Offloading und HTTPS End-to-End. Der Workflow für das Erstellen des Anwendungsprofil variiert für jeden HTTPS-Datenverkehrstyp.

Hinweis:
  • Ab NSX 6.4.5 enthält das Dropdown-Menü Anwendungsprofil-Typ (Application Profile Type) separate Optionen zum Erstellen eines Profils für jeden der drei HTTPS-Datenverkehrstypen.
  • In NSX 6.4.4 und früher enthält das Dropdown-Menü Typ (Type) nur eine einzelne HTTPS-Option. Um ein Profil für jeden der drei HTTPS-Datenverkehrstypen zu erstellen, müssen Sie die entsprechenden Profilparameter angeben.
  • NSX Load Balancer unterstützt kein Proxy-SSL-Passthrough.
Ab NSX 6.4.5 wurde die Benutzeroberflächen-Terminologie für eine Reihe von HTTPS-Profilparametern geändert. In der folgenden Tabelle sind die Änderungen aufgelistet.
NSX 6.4.4 und früher NSX 6.4.5 und später
Zertifikate für den virtuellen Server Client-SSL
Poolzertifikate Server-SSL
Die folgende Tabelle beschreibt die drei Arten der HTTPS-Datenverkehrstypen.
Tabelle 1. HTTPS-Datenverkehrstypen
HTTPS-Datenverkehrstyp Beschreibung
SSL-Passthrough

Anwendungsregeln im Zusammenhang mit SSL-Attributen sind zulässig, ohne dass die SSL-Terminierung am Load Balancer erforderlich ist.

Das Datenverkehrsmuster ist: Client -> HTTPS-> LB (SSL Passthrough) -> HTTPS -> Server.

HTTPS Offloading

HTTP-basiertes Load Balancing wird durchgeführt. SSL endet auf dem Load Balancer und HTTP wird zwischen Load Balancer und Serverpool verwendet.

Das Datenverkehrsmuster ist: Client -> HTTPS-> LB (SSL-Ende) -> HTTP -> Server.

HTTPS End-to-End

HTTP-basiertes Load Balancing wird durchgeführt. SSL endet auf dem Load Balancer und HTTPS wird zwischen Load Balancer und Serverpool verwendet.

Das Datenverkehrsmuster ist: Client -> HTTPS-> LB (SSL-Ende) -> HTTPS -> Server.

Die folgende Tabelle beschreibt die Persistenz, die von den HTTPS-Datenverkehrstypen unterstützt wird.
Tabelle 2. Unterstützte Persistenztypen
Persistenz Beschreibung
Quell-IP

Dieser Persistenztyp verfolgt Sitzungen auf der Grundlage der Quell-IP-Adresse.

Wenn ein Client eine Verbindung zu einem virtuellen Server anfordert, der eine Quell-IP-Adresse-Persistenz unterstützt, überprüft der Load-Balancer, ob dieser Client bereits verbunden war. Wenn ja, gibt der Load-Balancer den Client an dasselbe Poolmitglied zurück.

SSL-Sitzungs-ID

Dieser Persistenztyp ist verfügbar, wenn Sie ein Profil für den SSL Passthrough-Datenverkehrstyp erstellen.

Durch die SSL-Sitzungs-ID-Persistenz wird gewährleistet, dass wiederholte Verbindungen vom selben Client an denselben Server gesendet werden. Die Sitzungs-ID-Persistenz ermöglicht die Wiederaufnahme von SSL-Sitzungen, bei der die Prozessorzeit für den Client sowie den Server gespeichert wird.

Cookie

Durch diesen Persistenztyp wird ein eindeutiges Cookie zur Identifizierung einer Sitzung beim ersten Zugriff eines Clients auf die Site eingefügt.

Auf das Cookie wird in den folgenden Anforderungen zur Aufrechterhaltung der Verbindung mit dem jeweiligen Server Bezug genommen.

Für die Persistenztypen Quell-IP (Source IP) und SSL-Sitzungs-ID (SSL Session ID) können Sie den Zeitraum für die Persistenz bis zum Ablauf in Sekunden eingeben. Der Standardwert für die Persistenz beträgt 300 Sekunden (fünf Minuten).
Nicht vergessen: Die Größe der Persistenztabelle ist begrenzt. Wenn der Datenverkehr hoch ist, kann die Persistenztabelle durch einen erhöhten Zeitüberschreitungswert schnell gefüllt werden. Wenn die Persistenztabelle voll ist, wird für den aktuellen Eintrag der älteste Eintrag gelöscht.
Die Persistenztabelle des Load Balancer enthält Einträge, die die Weiterleitung von Clientanforderungen zum selben Poolmitglied aufzeichnen.
  • Wenn von demselben Client keine neuen Verbindungsanforderungen innerhalb des festgelegten Zeitraums empfangen werden, verfällt der Persistenzeintrag und wird gelöscht.
  • Geht von demselben Client innerhalb des festgelegten Zeitraums eine neue Verbindungsanforderung ein, wird der Timer zurückgesetzt und die Clientanforderung an ein verfügbares Poolmitglied gesendet.
  • Nach Ablauf des festgelegten Zeitraums wird eine Verbindungsanforderung an ein über den Load-Balancing-Algorithmus bestimmtes Poolmitglied gesendet.

Für den Fall einer TCP-Quell-IP-Persistenz mit dem L7-Load-Balancer legt der Persistenzeintrag den Zeitpunkt fest, ab dem keine neuen TCP-Verbindungen für einen bestimmten Zeitraum erstellt werden, auch wenn die vorhandenen Verbindungen weiterhin aktiv sind.

Die folgende Tabelle listet die genehmigten Verschlüsselungs-Suites auf, die zum Aushandeln der Sicherheitseinstellungen während eines SSL- oder TLS-Handshakes verwendet werden können.

Tabelle 3. Genehmigte Verschlüsselungs-Suites
Verschlüsselungswert Verschlüsselungsname
DEFAULT DEFAULT
ECDHE-RSA-AES128-GCM-SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
ECDHE-RSA-AES256-GCM-SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
ECDHE-RSA-AES256-SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
ECDHE-ECDSA-AES256-SHA TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
ECDH-ECDSA-AES256-SHA TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
ECDH-RSA-AES256-SHA TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
AES256-SHA TLS_RSA_WITH_AES_256_CBC_SHA
AES128-SHA TLS_RSA_WITH_AES_128_CBC_SHA
DES-CBC3-SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA
ECDHE-RSA-AES128-SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
ECDHE-RSA-AES128-SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
ECDHE-RSA-AES256-SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
AES128-SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256
AES128-GCM-SHA256 TLS_RSA_WITH_AES_128_GCM_SHA256
AES256-SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256
AES256-GCM-SHA384 TLS_RSA_WITH_AES_256_GCM_SHA384

Das folgende Verfahren erläutert die Schritte zum Erstellen eines Anwendungsprofils für jeden der drei HTTPS-Datenverkehrstypen.

Prozedur

  1. Melden Sie sich beim vSphere Web Client an.
  2. Klicken Sie auf Netzwerk und Sicherheit (Networking & Security) > NSX Edges.
  3. Doppelklicken Sie auf eine NSX Edge-Instanz.
  4. Klicken Sie auf Verwalten (Manage) > Load Balancer > Anwendungsprofile (Application Profiles).
  5. Klicken Sie auf Hinzufügen (Add).
    Das Fenster Neues Anwendungsprofil wird geöffnet.
  6. Geben Sie die Anwendungsprofil-Parameter an.

    Schritte für den Datenverkehrstyp SSL Passthrough

    NSX-Version Vorgehensweise
    6.4.5 und höher
    1. Wählen Sie im Dropdown-Menü Anwendungsprofil-Typ (Application Profile Type) SSL Passthrough .
    2. Geben Sie den Namen des Profils ein.
    3. Wählen Sie den Persistenztyp.
    4. Geben Sie den Ablaufzeitraum für die Persistenz ein.
    5. Klicken Sie auf Hinzufügen (Add).
    6.4.4 und früher
    1. Geben Sie den Namen des Profils ein.
    2. Wählen Sie im Dropdown-Menü Typ (Type) HTTPS.
    3. Aktivieren Sie das Kontrollkästchen SSL-Passthrough aktivieren (Enable SSL Passthrough).
    4. Wählen Sie den Persistenztyp.
    5. Geben Sie den Ablaufzeitraum für die Persistenz ein.
    6. Klicken Sie auf OK.

    Schritte für den Datenverkehrstyp HTTPS Offloading

    NSX-Version Vorgehensweise
    6.4.5 und höher
    1. Wählen Sie im Dropdown-Menü Anwendungsprofil-Typ (Application Profile Type) HTTPS-Offloading (HTTPS Offloading) aus.
    2. Geben Sie den Namen des Profils ein.
    3. Geben Sie die URL ein, zu der Sie den HTTP-Datenverkehr umleiten möchten.
    4. Wählen Sie den Persistenztyp.
      • Geben Sie für Cookie-Persistenz den Cookie-Namen ein und wählen Sie den Modus zum Einfügen des Cookies. Eine Beschreibung zu jedem Cookie-Modus finden Sie unter Erstellen eines HTTP-Anwendungsprofils.
      • Geben Sie für Quell-IP-Persistenz den Zeitraum für die Persistenz bis zum Ablauf ein.
    5. Optional: Um die Ursprungs-IP-Adresse eines Clients zu identifizieren, der eine Verbindung zu einem Webserver über den Load Balancer herstellt, aktivieren Sie die Option HTTP-Header „X-Forwarded-For“ einfügen (Insert X-Forwarded-For HTTP header).
    6. Klicken Sie auf die Registerkarte Client-SSL (Client SSL).
    7. Wählen Sie mindestens einen Verschlüsselungsalgorithmus oder mindestens eine Verschlüsselungs-Suite, der/die während des SSL-Handshakes verwendet werden soll. Stellen Sie sicher, dass die genehmigte Verschlüsselungs-Suite DH-Schlüssellängen von mindestens 1024 Bit enthält.
    8. Geben Sie an, ob die Client-Authentifizierung ignoriert oder angefordert werden soll. Falls erforderlich muss der Client nach der Anforderung ein Zertifikat liefern oder der Handshake wird abgebrochen.
    9. Wählen Sie das erforderliche Dienstzertifikat, CA-Zertifikat und den CRL, die das Profil verwenden muss, um den HTTPS-Datenverkehr vom Client auf dem Load Balancer zu beenden.
    10. Klicken Sie auf Hinzufügen (Add).
    6.4.4 und früher
    1. Geben Sie den Namen des Profils ein.
    2. Wählen Sie im Dropdown-Menü Typ (Type) HTTPS.
    3. Befolgen Sie die Schritte in dieser Tabelle für NSX 6.4.5 und höher, um die folgenden Anwendungsprofil-Parameter zu definieren:
      • HTTP-Umleitungs-URL
      • Persistenz
      • HTTP-Header „X-Forwarded-For“ einfügen
    4. Klicken Sie auf die Registerkarte Zertifikate für den virtuellen Server (Virtual Server Certificates).
    5. Befolgen Sie die Schritte, die in dieser Tabelle für NSX 6.4.5 und später zur Definition von Verschlüsselungsalgorithmen und zur Client-Authentifizierung enthalten sind.
    6. Klicken Sie auf Dienstzertifikate konfigurieren (Configure Service Certificates) und wählen Sie das erforderliche Dienstzertifikat, CA-Zertifikat und den CRL, die das Profil verwenden muss, um den HTTPS-Datenverkehr vom Client auf dem Load Balancer zu beenden.
    7. Klicken Sie auf OK.

    Schritte für den Datenverkehrstyp HTTPS End-to-End

    In diesem Anwendungsprofil-Typ geben Sie sowohl die Client-SSL- (Zertifikate für den virtuellen Server) als auch die Server-SSL-Parameter (Pool Side SSL) an.

    Die Server-SSL-Parameter werden zum Authentifizieren des Load Balancers von Serverseite verwendet. Wenn der Edge-Load Balancer über ein CA-Zertifikat verfügt, ein CRL bereits konfiguriert ist und der Load Balancer ein Dienstzertifikat von den Backend-Servern überprüfen muss, wählen Sie das Dienstzertifikat. Sie können das Load Balancer-Zertifikat auch für den Backend-Server bereitstellen, wenn der Backend-Server das Load Balancer-Dienstzertifikat überprüfen muss.

    NSX-Version Vorgehensweise
    6.4.5 und höher
    1. Wählen Sie im Dropdown-Menü Anwendungsprofil-Typ (Application Profile Type) HTTPS End-to-End aus.
    2. Geben Sie den Namen des Profils ein.
    3. Befolgen Sie die Schritte, die in der Tabelle für die Erstellung eines HTTPS Offloading-Profils enthalten sind, um die folgenden Anwendungsprofil-Parameter zu definieren:
      • HTTP-Umleitungs-URL
      • Persistenz
      • HTTP-Header „X-Forwarded-For“ einfügen
      • Client-SSL: Verschlüsselungsalgorithmen, Client-Authentifizierung, Dienstzertifikat, CA-Zertifikat und CRL
    4. Klicken Sie auf die Registerkarte Server-SSL (Server SSL) und wählen Sie die Verschlüsselungsalgorithmen, das erforderliche Dienstzertifikat, das CA-Zertifikat und den CRL zur Authentifizierung des Load Balancers von Serverseite.
    5. Klicken Sie auf Hinzufügen (Add).
    6.4.4 und früher
    1. Geben Sie den Namen des Profils ein.
    2. Wählen Sie im Dropdown-Menü Typ (Type) HTTPS.
    3. Befolgen Sie die Schritte, die in der Tabelle für die Erstellung eines HTTPS Offloading-Profils enthalten sind, um die folgenden Anwendungsprofil-Parameter zu definieren:
      • HTTP-Umleitungs-URL
      • Persistenz
      • HTTP-Header „X-Forwarded-For“ einfügen
      • Zertifikate für den virtuellen Server: Verschlüsselungsalgorithmen, Client-Authentifizierung, Dienstzertifikat, CA-Zertifikat und CRL
    4. Aktivieren Sie das Kontrollkästchen Pool Side SSL aktivieren (Enable Pool Side SSL) zur Aktivierung der HTTPS-Kommunikation zwischen dem Load Balancer und den Backend-Servern.
    5. Wählen Sie die Verschlüsselungsalgorithmen und das erforderliche Dienstzertifikat, CA-Zertifikat und den CRL zur Authentifizierung des Load Balancers von der Serverseite.
    6. Klicken Sie auf OK.