Ankündigung von NGINX Plus R28

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.

• Unterstützung für PROXY-Protokoll v2-TLVs in privaten Clouddiensten – Wenn Sie Ressourcen über einen „privaten Dienst“ in AWS, Google Cloud Platform und Microsoft Azure externen Clients zur Verfügung stellen, wird die dienstspezifische Clientkennung, die in einem Typ-Längen-Wert -Vektor (TLV) im Header des PROXY-Protokolls v2 dargestellt ist, standardmäßig nicht an Back-End-Dienste übergeben. NGINX Plus R28 führt Module für die HTTP- und Stream -Kontexte ein, die das TLV dekodieren und eine Variable zur Weiterleitung der Clientkennung an Backend-Dienste definieren.
• Variablenunterstützung für den Sticky-Cookie- 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.

Wichtige Verhaltensänderungen

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.

Änderungen an der Plattformunterstützung

Unterstützte neue Betriebssysteme und Architekturen:

• AlmaLinux 8 und 9 (x86_64, aarch64)
• Alpine 3.17 (x86_64, arm64)
• Oracle Linux 9 (x86_64)
• Rocky Linux 8 und 9 (x86_64, aarch64)

Ältere Betriebssysteme entfernt:

• Debian 10, das im August 2022 das Ende seiner Lebensdauer (EOL) erreichte

Ältere Betriebssysteme und Architekturen, die veraltet sind und deren Entfernung in NGINX Plus R29 vorgesehen ist:

• Alpine 3.13, das am 1. November 2022 EOL erreichte

Änderung im Umgang mit mehreren Headern mit identischen Namen

• Die meisten bekannten doppelten Upstream-Antwortheader werden jetzt mit einer Warnung ignoriert
• Doppelte 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.

Neue Features im Detail

Zusätzliche TLS-Metriken

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-Handshakes
• handshakes_failed – Anzahl der fehlgeschlagenen SSL-Handshakes (ohne fehlgeschlagene Zertifikatsüberprüfungen, die nach dem SSL-Handshake auftreten)
• session_reuses – Anzahl der Wiederverwendungen von SSL-Sitzungen

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

Handshake-Fehler

Zähler für die folgenden Handshake-Fehler sind neu in NGINX Plus R28 :

• handshake_timeout – Anzahl der Handshake-Fehler aufgrund eines Handshake-Timeouts
• no_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 Parteien
• peer_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

Fehler bei der Zertifikatsüberprüfung werden jetzt im neuen Abschnitt „verify_failures “ der API-Ausgabe gemeldet, wenn Sie die Zertifikatsüberprüfung konfigurieren:

• Für Verbindungen zu Clients mit der Direktive 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 vorgelegt
• hostname_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 vorgelegt
• other – Expliziter Zähler für andere Fehler bei der Zertifikatsüberprüfung

Beispiel für die Metrikausgabe

Hier 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 } }, ... } ], }

Das NGINX Plus-Dashboard zeigt die erweiterten TLS-Metriken an

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.

Unterstützung für PROXY-Protokoll v2-TLVs in Cloud Private Services

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:

• AWS PrivateLink – PP2_SUBTYPE_AWS_VPCE_ID
• GCP Private Service Connect – pscConnectionId
• Microsoft Azure Private Link – 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.

PROXY-Protokoll v2-Unterstützung für AWS

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

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:

PROXY-Protokoll v2-Unterstützung für GCP

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

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.

PROXY-Protokoll v2-Unterstützung für Microsoft Azure

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

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.

Variablenunterstützung für den Sticky Cookie samesite -Parameter

In 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:

• Auf einen der Standardwerte ( strict , lax und none ) – NGINX fügt das auf diesen Wert eingestellte SameSite- Attribut ein
• Auf einen leeren Wert ( "" ) – NGINX fügt das SameSite- Attribut nicht ein
• Bei jedem anderen Wert, der auf eine Fehlkonfiguration hinweist, fügt NGINX das SameSite- 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):

Weitere Verbesserungen in NGINX Plus R28

Von NGINX Open Source übernommene Änderungen

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:

• Der neue Parameter „ipv4=off“ der HTTP- Resolver- Direktive deaktiviert die Suche nach IPv4-Adressen.
• Wenn Sie mit dem Parameter „shared “ für die Direktive „ssl_session_cache“ einen gemeinsamen Cache für HTTP-Sitzungsinformationen aktivieren, werden die TLS-Sitzungsticketschlüssel jetzt automatisch rotiert.
• Der Schweregrad, mit dem verschiedene Arten von TLS/SSL-Fehlern protokolliert werden, wird von „crit“ auf „info“ gesenkt.

Die vollständige Liste der neuen Funktionen, Änderungen und Fehlerbehebungen dieser Versionen finden Sie in der Datei CHANGES .

Änderungen am NGINX JavaScript-Modul

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

Upgrade oder Testen von NGINX Plus

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.