Wir freuen uns, die Verfügbarkeit von NGINX Plus Release 28 (R28) bekannt zu geben . NGINX Plus basiert auf NGINX Open Source und ist der einzige All-in-One- Software-Webserver, Load Balancer, Reverse-Proxy, Inhaltscache und API-Gateway.
Zu den neuen und erweiterten Funktionen in NGINX Plus R28 gehören:
Zusätzliche TLS-Metriken – NGINX Plus R28 erfasst zusätzliche TLS-Statistiken auf systemweiter, clientseitiger und serverseitiger Ebene und bietet so wichtige Erkenntnisse bei der Behebung von SSL-/TLS-bezogenen Fehlern in der Proxy-Konfiguration und bei Verbindungen mit Clients und Upstream-Servern.
Das Dashboard zur Live-Aktivitätsüberwachung von NGINX Plus wird aktualisiert, um die neuen SSL-Sitzungsdaten anzuzeigen.
HTTP-
und Stream
-Kontexte ein, die das TLV dekodieren und eine Variable zur Weiterleitung der Clientkennung an Backend-Dienste definieren.Samesite-
Parameter – In NGINX Plus R28 kann der Wert des Samesite-
Parameters der Sticky
-Cookie-
Direktive eine Variable sein. Diese Verbesserung ermöglicht eine einfachere Verkehrsverwaltung und mehr Sicherheit.Abgerundet wird die Version durch neue Funktionen und Fehlerbehebungen, die von NGINX Open Source übernommen wurden, sowie Updates für das NGINX JavaScript-Modul.
Notiz: Wenn Sie von einer anderen Version als NGINX Plus R27 aktualisieren, lesen Sie unbedingt den Abschnitt „Wichtige Verhaltensänderungen“ in den Ankündigungsblogs für alle Versionen zwischen Ihrer aktuellen und dieser.
Unterstützte neue Betriebssysteme und Architekturen:
Ältere Betriebssysteme entfernt:
Ältere Betriebssysteme und Architekturen, die veraltet sind und deren Entfernung in NGINX Plus R29 vorgesehen ist:
Content-Length-
und Transfer-Encoding-
Header werden jetzt abgelehnt, ebenso wie Antworten mit ungültigen Content-Length-
oder Transfer-Encoding-
Headern oder wenn sowohl Content-Length
als auch Transfer-Encoding
in der Antwort vorhanden sind.Die Beobachtbarkeit von SSL/TLS-Ereignissen und -Fehlern ist bei der Behebung von TLS-bezogenen Problemen mit der Proxy-Konfiguration, Upstream-Servern und Clients wichtig. Seit der Einführung der NGINX Plus-API in NGINX Plus R13 hat NGINX Plus drei TLS-Metriken auf systemweiter Ebene erfasst:
Handshakes
– Anzahl erfolgreicher SSL-Handshakeshandshakes_failed
– Anzahl der fehlgeschlagenen SSL-Handshakes (ohne fehlgeschlagene Zertifikatsüberprüfungen, die nach dem SSL-Handshake auftreten)session_reuses
– Anzahl der Wiederverwendungen von SSL-SitzungenIn NGINX Plus R27<.htmla> und höher können Sie die Erfassung der drei Metriken für einzelne Upstream-Server und virtuelle Server konfigurieren.
NGINX Plus R28 erweitert den Satz der TLS-Metriken um neue Zähler für Handshake-Fehler und fehlgeschlagene Zertifikatsvalidierungen sowohl in HTTP- als auch in Stream-Modulen (hier stellen wir nur Beispiele für HTTP-Module bereit, aber die verfügbaren Stream-Metriken sind ähnlich). Einzelheiten zum Konfigurieren der Metrikerfassung für einzelne Upstream-Server und virtuelle Server finden Sie im Ankündigungsblog zu NGINX Plus R27<.htmlspan> .
Zähler für die folgenden Handshake-Fehler sind neu in NGINX Plus R28 :
handshake_timeout
– Anzahl der Handshake-Fehler aufgrund eines Handshake-Timeoutsno_common_cipher
– Anzahl der Handshake-Fehler aufgrund des Fehlens einer gemeinsamen Chiffre zwischen den Parteien im Handshake (wird für Verbindungen zu Upstream-Servern nicht erfasst, da nicht zutreffend)no_common_protocol
– Anzahl der Handshake-Fehler aufgrund des Fehlens eines gemeinsamen Protokolls zwischen den Parteienpeer_rejected_cert
– Anzahl der Handshake-Fehler, da die Gegenpartei das von NGINX Plus vorgelegte Zertifikat ablehnt und die entsprechende Warnmeldung ausgibt.Fehler bei der Zertifikatsüberprüfung werden jetzt im neuen Abschnitt „verify_failures
“ der API-Ausgabe gemeldet, wenn Sie die Zertifikatsüberprüfung konfigurieren:
ssl_verify_client
[ HTTP ][ Stream ]Für Verbindungen zu Servern mit diesen protokollspezifischen Anweisungen:
grpc_ssl_verify
proxy_ssl_verify
[ HTTP ][ Stream ]uwsgi_ssl_verify
Bei einem Fehler bei der Zertifikatsprüfung wird die Metrik für die entsprechende Ursache erhöht und die Verbindung getrennt. Beachten Sie jedoch, dass der Zähler für grundlegende Handshakes
dennoch hochgezählt wird, da diese Fehler auch nach einem erfolgreichen Handshake auftreten.
Die Kennzahlen für eine fehlgeschlagene Zertifikatsüberprüfung lauten:
expired_cert
– Peer hat ein abgelaufenes Zertifikat vorgelegthostname_mismatch
– Das Serverzertifikat stimmt nicht mit dem Hostnamen überein (wird bei Verbindungen zu Clients nicht erfasst)no_cert
– Der Client hat kein erforderliches Zertifikat bereitgestellt (wird bei Verbindungen mit Upstream-Servern nicht erfasst)revoked_cert
– Der Peer hat ein widerrufenes Zertifikat vorgelegtother
– Expliziter Zähler für andere Fehler bei der ZertifikatsüberprüfungHier ist eine Reihe von Beispiel-TLS-Metriken für HTTP-Verbindungen auf systemweiter Ebene:
$ curl 127.0.0.1:8080/api/8/ssl { "Handshakes": 32, "Sitzung wird wiederverwendet": 0, „Handshakes fehlgeschlagen“: 8, „kein_gemeinsames_Protokoll“: 4, „keine_gemeinsame_Chiffre“: 2, „Handshake-Timeout“: 0, „Peer_rejected_cert“: 0, "Fehler überprüfen": { "kein_Zertifikat": 0, "abgelaufenes Zertifikat": 2, „widerrufliches Zertifikat“: 1, „Hostname stimmt nicht überein“: 2, "andere": 1 } }
Hier ist eine Reihe von Beispielmetriken für Verbindungen zwischen Clients und dem virtuellen HTTP-Server s9 (wie bereits erwähnt, wird der Zähler hostname_mismatch
für solche Verbindungen nicht erfasst):
$ curl 127.0.0.1:8080/api/8/http/server_zones/s9 { ... "ssl": { "handshakes": 0, "Sitzung wird wiederverwendet": 0, „Handshakes fehlgeschlagen“: 1, „kein_gemeinsames_Protokoll“: 0, "keine_gemeinsame_Chiffre": 1, „Handshake-Timeout“: 0, „Peer_rejected_cert“: 0, "Fehler überprüfen": { "kein_Zertifikat": 0, "abgelaufenes Zertifikat": 0, „widerrufliches Zertifikat“: 0, "anderes": 0 } } ... }
Hier ist eine Reihe von Beispielmetriken für HTTP-Verbindungen zu Servern in der Upstream-Gruppe u2 (wie bereits erwähnt, werden die Zähler „no_cert“
und „no_common_cipher“
für solche Verbindungen nicht erfasst):
$ curl 127.0.0.1:8080/api/8/http/upstreams/u2 { "Peers": [ { "ID": 0, "Server": "127.0.0.1:8082", "Name": "127.0.0.1:8082", ... "ssl": { "Handshakes": 1, „Sitzung wird wiederverwendet“: 0, „Handshakes fehlgeschlagen“: 0, „kein_gemeinsames_Protokoll“: 0, "handshake_timeout": 0, „Peer_rejected_cert“: 0, "verify_failures": { "abgelaufenes_Zertifikat": 1, „widerrufliches Zertifikat“: 0, „Hostname stimmt nicht überein“: 0, "anderes": 0 } }, ... } ], }
Für NGINX Plus R28 und höher zeigt das Dashboard zur Live-Aktivitätsüberwachung die oben beschriebenen neuen TLS-Metriken an. Dieser Screenshot zeigt Metriken für Verbindungen zu Clients. Um die neuen Messwerte anzuzeigen, bewegen Sie die Maus über den Wert in der Spalte „SSL > Handshakes fehlgeschlagen“ , wie gezeigt.
Die drei führenden Cloud-Anbieter – Amazon Web Services (AWS), Google Cloud Platform (GCP) und Microsoft Azure – bieten jeweils einen „privaten Dienst“ an, mit dem Sie externen Clients den Zugriff auf Ihre Dienste ermöglichen können, ohne diese im öffentlichen Internet verfügbar zu machen. Jeder Dienst verwendet eine Clientkennung, die in einem Typ-Länge-Wert-Vektor (TLV) in einem PROXY-Protokoll v2-Header dargestellt wird. Die dienstspezifischen Kennungen sind:
PP2_SUBTYPE_AWS_VPCE_ID
pscConnectionId
PP2_SUBTYPE_AZURE_PRIVATEENDPOINT_LINKID
Standardmäßig werden diese Clientkennungen nicht an Backend-Dienste weitergegeben. NGINX Plus R28 führt Module für die HTTP-
und Stream-
Kontexte ein – ngx_http_proxy_protocol_vendor_module und ngx_stream_proxy_protocol_vendor_module – die das TLV dekodieren und eine Variable für die Weiterleitung des Bezeichners an Backend-Dienste definieren.
Allgemeine Informationen dazu, wie NGINX Plus das PROXY-Protokoll verwendet, um IP-Adressen und andere Informationen über Clients abzurufen, finden Sie unter „Akzeptieren des PROXY-Protokolls“ im NGINX Plus-Administratorhandbuch.
In AWS ist die Quell-IP-Adresse für Datenverkehr, der von Clients über einen Virtual Private Cloud (VPC)-Endpunktdienst kommt, die private IP-Adresse des Network Load Balancer-Knotens. Wenn die Backend-Anwendung die echten IP-Adressen und andere Kennungen für Clients benötigt, können diese aus den Headern des PROXY-Protokolls v2 abgerufen werden.
In AWS codiert ein benutzerdefinierter TLV-Vektor die VPC-ID des Endpunkts im PROXY-Protokoll v2-Header PP2_SUBTYPE_AWS_VPCE_ID
. (Weitere Informationen finden Sie in der AWS-Dokumentation .)
Feld | Länge (Oktette) | Beschreibung |
---|---|---|
Typ | 1 | PP2_TYPE_AWS ( 0xEA ) |
Länge | 2 | Die Länge des Wertes |
Wert | 1 | PP2_SUBTYPE_AWS_VPCE_ID ( 0x01 ) |
Variiert (Wertlänge minus 1) | Die ID des Endpunkts |
NGINX Plus R28 dekodiert das TLV und übergibt die Endpunkt-ID an Backend-Anwendungen in der Variable $proxy_protocol_tlv_aws_vpce_id
.
Notiz: Im Serverblock
, in dem Sie auf die Variable $proxy_protocol_tlv_aws_vpce_id
verweisen, müssen Sie auch den Parameter proxy_protocol
in die Direktive „ listen
[ HTTP ][ Stream ]“ aufnehmen. Ein Beispiel finden Sie unten in Zeile 8 von proxy_protocol_v2.conf .
Diese Beispielkonfiguration für AWS prüft, ob die VPC-ID akzeptabel ist, und übergibt sie gegebenenfalls als zweiten Parameter an die add_header-
Direktive an die Backend-Anwendung:
In GCP Private Service Connect ist die Quell-IP-Adresse für von Clients kommenden Datenverkehr eine „Adresse in einem der Private Service Connect-Subnetze im VPC-Netzwerk des Dienstanbieters“. Wenn die Back-End-Anwendung die echten IP-Adressen und andere Kennungen für Clients benötigt, können diese aus den Headern des PROXY-Protokolls v2 abgerufen werden.
In GCP codiert ein benutzerdefinierter TLV-Vektor die (zu diesem Zeitpunkt) eindeutige Verbindungs-ID im PROXY-Protokoll v2-Header pscConnectionId
. (Weitere Informationen finden Sie in der GCP-Dokumentation .)
Feld | Länge (Bytes) | Beschreibung |
---|---|---|
Typ | 1 | 0xE0 ( PP2_TYPE_GCP ) |
Länge | 2 | 0x8 (8 Byte) |
Wert | 8 | Die 8‑Byte pscConnectionId in Netzwerkreihenfolge |
NGINX Plus R28 dekodiert das TLV und übergibt den Wert von pscConnectionId
an Backend-Anwendungen in der Variable $proxy_protocol_tlv_gcp_conn_id
.
Notiz: Im Serverblock
, in dem Sie auf die Variable $proxy_protocol_tlv_gcp_conn_id
verweisen, müssen Sie auch den Parameter proxy_protocol
in die Direktive „ listen
[ HTTP ][ Stream ]“ aufnehmen. Ein Beispiel finden Sie in Zeile 8 von proxy_protocol_v2.conf oben.
In Microsoft Azure Private Link ist die Quell-IP-Adresse für von Clients kommenden Datenverkehr die „auf Seiten des Dienstanbieters mithilfe der vom virtuellen Netzwerk des Anbieters zugewiesenen NAT-IP[-Adresse] übersetzte Netzwerkadresse (NAT)“. Wenn die Back-End-Anwendung die echten IP-Adressen und andere Kennungen für Clients benötigt, können diese aus den Headern des PROXY-Protokolls v2 abgerufen werden.
In Azure codiert ein benutzerdefinierter TLV-Vektor die Link-ID des Clients im PROXY-Protokoll v2-Header PP2_SUBTYPE_AZURE_PRIVATEENDPOINT_LINKID
. (Weitere Informationen finden Sie in der Azure-Dokumentation .)
Feld | Länge (Oktette) | Beschreibung |
---|---|---|
Typ | 1 | PP2_TYPE_AZURE ( 0xEE ) |
Länge | 2 | Länge des Wertes |
Wert | 1 | PP2_SUBTYPE_AZURE_PRIVATEENDPOINT_LINKID ( 0x01 ) |
4 | UINT32 (4 Bytes) stellt die LINKID des privaten Endpunkts dar. Im Little‑Endian‑Format codiert. |
NGINX Plus R28 dekodiert das TLV und übergibt die LinkID an Backend-Anwendungen in der Variable $proxy_protocol_tlv_azure_pel_id
.
Notiz: Im Serverblock
, in dem Sie auf die Variable „ $proxy_protocol_tlv_azure_pel_id“
verweisen, müssen Sie auch den Parameter „proxy_protocol“
in die Direktive „ listen
[ HTTP ] [ Stream ]“ aufnehmen. Ein Beispiel finden Sie in Zeile 8 von proxy_protocol_v2.conf oben.
samesite
-ParameterIn früheren Versionen von NGINX Plus waren drei statische Werte ( strict
, lax
und none
) für den samesite-
Parameter der Sticky-
Cookie-
Direktive akzeptabel. In NGINX Plus R28 kann der Wert auch eine Variable sein.
Standardmäßig (es gibt keinen Samesite-
Parameter) fügt NGINX das SameSite-
Attribut nicht in das Cookie ein. Wenn der Samesite
-Parameter eine Variable ist, hängt das Ergebnis davon ab, wie die Variable zur Laufzeit aufgelöst wird:
strict
, lax
und none
) – NGINX fügt das auf diesen Wert eingestellte SameSite-
Attribut ein""
) – NGINX fügt das SameSite-
Attribut nicht einSameSite-
Attribut ein, das auf „Strict“
(die sicherste Einstellung) eingestellt ist.Diese Beispielkonfiguration legt das SameSite
-Attribut basierend auf dem Wert des HTTP- User-Agent-
Headers fest (dies ist gut für ältere Clients, die das SameSite-
Attribut nicht unterstützen):
NGINX Plus R28 basiert auf NGINX Open Source 1.23.2 und übernimmt funktionale Änderungen und Fehlerbehebungen seit der Veröffentlichung von NGINX Plus R27 (in NGINX 1.23.0 bis 1.23.2). Zu den Änderungen und Fehlerbehebungen gehören:
„ipv4=off“
der HTTP- Resolver-
Direktive deaktiviert die Suche nach IPv4-Adressen.„shared
“ für die Direktive „ssl_session_cache“
einen gemeinsamen Cache für HTTP-Sitzungsinformationen aktivieren, werden die TLS-Sitzungsticketschlüssel jetzt automatisch rotiert.„crit“
auf „info“
gesenkt.Die vollständige Liste der neuen Funktionen, Änderungen und Fehlerbehebungen dieser Versionen finden Sie in der Datei CHANGES .
NGINX Plus R28 enthält Änderungen und Korrekturen, die in den Versionen 0.7.5 bis 0.7.8 des NGINX JavaScript-Moduls (njs) vorgenommen wurden. Einige der wichtigsten davon haben wir in unserem Blog in „Machen Sie Ihre NGINX-Konfiguration mit njs 0.7.7 noch modularer und wiederverwendbarer“ hervorgehoben. Eine vollständige Liste finden Sie in der Datei „Änderungen“ .
Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich auf NGINX Plus R28 zu aktualisieren. Sie erhalten außerdem mehrere zusätzliche Fehlerbehebungen und Verbesserungen und NGINX kann Ihnen helfen, wenn Sie ein Support-Ticket erstellen müssen.
Wenn Sie NGINX Plus noch nicht ausprobiert haben, empfehlen wir Ihnen, es auszuprobieren – für Sicherheit, Lastausgleich und API-Gateway oder als vollständig unterstützten Webserver mit erweiterten Überwachungs- und Verwaltungs-APIs. Sie können noch heute mit einer kostenlosen 30-Tage-Testversion beginnen.
„Dieser Blogbeitrag kann auf Produkte verweisen, die nicht mehr verfügbar und/oder nicht mehr unterstützt werden. Die aktuellsten Informationen zu verfügbaren F5 NGINX-Produkten und -Lösungen finden Sie in unserer NGINX-Produktfamilie . NGINX ist jetzt Teil von F5. Alle vorherigen NGINX.com-Links werden auf ähnliche NGINX-Inhalte auf F5.com umgeleitet."