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.
- 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.
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 |
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. |
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. |
- 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.
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.