Ankündigung von NGINX Plus R28

Robert HaynesManager für technisches Marketing

Wir freuen uns, die Verfügbarkeit von NGINX Plus Release 28 (R28) bekannt zu geben. Basierend auf NGINX Open Source ist NGINX Plus die einzige All-in-One-Software, die Webserver, Load Balancer, Reverse Proxy, Content-Cache und API-Gateway in einem vereint.

Zu den neuen und verbesserten 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 liefert damit wichtige Erkenntnisse für die Behebung von SSL/TLS-bezogenen Fehlern in der Proxy-Konfiguration sowie bei Verbindungen zu Clients und Upstream-Servern. Das Dashboard zur Überwachung der Live-Aktivitäten von NGINX Plus wurde aktualisiert und zeigt nun die neuen SSL-Sitzungsdaten an.
• Unterstützung für TLVs des PROXY-Protokolls v2 in privaten Cloud-Diensten – Wenn Sie Ressourcen über einen „privaten Dienst“ in AWS, Google Cloud Platform und Microsoft Azure für externe Clients verfügbar machen, wird die dienstspezifische Client-ID, die in einem Typ-Länge-Wert-Vektor (TLV) im Header des PROXY-Protokolls v2 enthalten ist, standardmäßig nicht an Backend-Dienste weitergegeben. NGINX Plus R28 führt Module für die Kontexte http und stream ein, die den TLV dekodieren und eine Variable definieren, mit der die Client-ID an Backend-Dienste weitergeleitet werden kann.
• Unterstützung von Variablen für den samesite-Parameter von Sticky Cookies – In NGINX Plus R28 kann der Wert des samesite-Parameters der sticky-cookie-Direktive eine Variable sein. Diese Verbesserung erleichtert die Verwaltung des Datenverkehrs und erhöht die Sicherheit.

Abgerundet wird das Release durch neue Funktionen und Fehlerbehebungen aus NGINX Open Source sowie Aktualisierungen des NGINX-JavaScript-Moduls.

Wichtige Verhaltensänderungen

Hinweis: Wenn Sie ein Upgrade von einer anderen Version als NGINX Plus R27 durchführen, lesen Sie unbedingt den Abschnitt „Wichtige Verhaltensänderungen“ in den Ankündigungsblogs zu allen Versionen zwischen Ihrer aktuellen Version und dieser Version.

Änderungen bei der Plattformunterstützung

Neu unterstützte 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, dessen Lebenszyklus (EOL) im August 2022 endete

Ältere Betriebssysteme und Architekturen, die als veraltet eingestuft wurden und deren Unterstützung mit NGINX Plus R29 eingestellt werden soll:

• Alpine 3.13, dessen Support am 1. November 2022 eingestellt wurde

Änderung bei der Verarbeitung mehrerer Header mit identischen Namen

• Die meisten bekannten doppelten Upstream-Antwortheader werden nun ignoriert, wobei eine Warnung ausgegeben wird.
• Doppelte Content-Length- und Transfer-Encoding-Header werden nun ebenso abgelehnt wie Antworten mit ungültigen Content-Length- oder Transfer-Encoding-Headern oder wenn sowohl Content-Length als auch Transfer-Encoding in der Antwort enthalten sind

Neue Funktionen im Detail

Zusätzliche TLS-Metriken

Die Beobachtbarkeit von SSL/TLS-Ereignissen und -Fehlern ist wichtig, um TLS-bezogene Probleme mit der Proxy-Konfiguration, Upstream-Servern und Clients zu beheben. Seit der Einführung der NGINX Plus API in NGINX Plus R13 erfasst NGINX Plus drei TLS-Metriken auf systemweiter Ebene:

• handshakes – Anzahl erfolgreicher SSL-Handshakes
• handshakes_failed – Anzahl der fehlgeschlagenen SSL-Handshakes (ohne Fehler bei der Zertifikatsüberprüfung, die nach dem SSL-Handshake auftreten)
• session_reuses – Anzahl der Wiederverwendungen von SSL-Sitzungen

Ab NGINX Plus R27<.htmla> können Sie die Erfassung der drei Metriken für einzelne Upstream-Server und virtuelle Server konfigurieren.

NGINX Plus R28 erweitert den Umfang der TLS-Metriken um neue Zähler für Handshake-Fehler und Fehler bei der Zertifikatsvalidierung sowohl in HTTP- als auch in Stream-Modulen (hier zeigen wir nur Beispiele für HTTP-Module, die verfügbaren Stream-Metriken sind jedoch ähnlich). Einzelheiten zur Konfiguration 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 aufgrund einer Zeitüberschreitung beim Handshake fehlgeschlagenen Handshakes
• no_common_cipher – Anzahl der fehlgeschlagenen Handshakes, weil die am Handshake beteiligten Parteien keine gemeinsame Verschlüsselung verwenden (wird für Verbindungen zu Upstream-Servern nicht erfasst, da dies dort nicht zutrifft)
• no_common_protocol – Anzahl der fehlgeschlagenen Handshakes, weil die beteiligten Parteien kein gemeinsames Protokoll unterstützen
• peer_rejected_cert – Anzahl der fehlgeschlagenen Handshakes, weil die Gegenstelle das von NGINX Plus vorgelegte Zertifikat abgelehnt und die entsprechende Warnmeldung gesendet hat

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 Direktiven:
  • grpc_ssl_verify
  • proxy_ssl_verify[HTTP][Stream]
  • uwsgi_ssl_verify

Wenn bei der Zertifikatsüberprüfung ein Fehler auftritt, wird die Metrik für die entsprechende Ursache erhöht und die Verbindung getrennt. Beachten Sie jedoch, dass der grundlegende Zähler handshakes weiterhin erhöht wird, da diese Fehler erst nach erfolgreichem Handshake auftreten.

Die Metriken für fehlgeschlagene Zertifikatsvalidierungen sind:

• expired_cert – Die Gegenstelle hat ein abgelaufenes Zertifikat vorgelegt
• hostname_mismatch – Das Zertifikat des Servers stimmt nicht mit dem Hostnamen überein (wird bei Verbindungen zu Clients nicht erfasst)
• no_cert – Der Client hat nicht wie erforderlich ein Zertifikat bereitgestellt (wird bei Verbindungen zu Upstream-Servern nicht erfasst)
• revoked_cert – Die Gegenstelle hat ein widerrufenes Zertifikat vorgelegt
• other – Expliziter Zähler für sonstige Fehler bei der Zertifikatsüberprüfung

Beispiel für die Metrikausgabe

Hier finden Sie eine Reihe beispielhafter TLS-Metriken für HTTP-Verbindungen auf systemweiter Ebene:

$ curl 127.0.0.1:8080/api/8/ssl{    "handshakes": 32,    "session_reuses": 0,    "handshakes_failed": 8,    "no_common_protocol": 4,    "no_common_cipher": 2,    "handshake_timeout": 0,    "peer_rejected_cert": 0,    "verify_failures": {        "no_cert": 0,        "expired_cert": 2,        "revoked_cert": 1,        "hostname_mismatch": 2,        "other": 1    }}

Hier sehen Sie 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,        "session_reuses": 0,        "handshakes_failed": 1,        "no_common_protocol": 0,        "no_common_cipher": 1,        "handshake_timeout": 0,        "peer_rejected_cert": 0,        "verify_failures": {            "no_cert": 0,            "expired_cert": 0,            "revoked_cert": 0,            "other": 0        }    }    ...}

Hier sehen Sie 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,                "session_reuses": 0,                "handshakes_failed": 0,                "no_common_protocol": 0,                "handshake_timeout": 0,                "peer_rejected_cert": 0,                "verify_failures": {                    "expired_cert": 1,                    "revoked_cert": 0,                    "hostname_mismatch": 0,                    "other": 0                }            },            ...        }    ],}

NGINX Plus-Dashboard zeigt die erweiterten TLS-Metriken an

Ab NGINX Plus R28 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 Metriken anzuzeigen, bewegen Sie den Mauszeiger wie dargestellt über den Wert in der Spalte „SSL > Fehlgeschlagene Handshakes“.

Unterstützung für PROXY-Protocol-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, über den Sie externen Clients den Zugriff auf Ihre Dienste ermöglichen können, ohne diese im öffentlichen Internet zugänglich zu machen. Jeder Dienst verwendet eine Client-Kennung, die in einem Typ-Länge-Wert-Vektor (TLV) in einem PROXY-Protocol-v2-Header dargestellt wird. Die dienstspezifischen Kennungen lauten:

• 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 Client-Kennungen nicht an Backend-Dienste weitergegeben. NGINX Plus R28 führt Module für die Kontexte „http“ und „stream“ ein – ngx_http_proxy_protocol_vendor_module und ngx_stream_proxy_protocol_vendor_module –, die das TLV decodieren und eine Variable definieren, mit der die Kennung an Backend-Dienste weitergeleitet werden kann.

Allgemeine Informationen dazu, wie NGINX Plus mithilfe des PROXY-Protokolls IP-Adressen und andere Informationen über Clients abruft, finden Sie unter „Akzeptieren des PROXY-Protokolls“ im NGINX Plus-Administratorhandbuch.

Unterstützung des PROXY-Protokolls v2 für AWS

In AWS ist die Quell-IP-Adresse für Datenverkehr, der von Clients über einen Virtual-Private-Cloud(VPC)-Endpunktdienst eingeht, die private IP-Adresse des Network-Load-Balancer-Knotens. Wenn die Backend-Anwendung die tatsächlichen IP-Adressen und andere Kennungen der Clients benötigt, können diese den Headern des PROXY-Protokolls v2 entnommen werden.

In AWS codiert ein benutzerdefinierter TLV-Vektor die VPC-ID des Endpunkts im PROXY-Protocol-v2-Header PP2_SUBTYPE_AWS_VPCE_ID. (Weitere Informationen finden Sie in der AWS-Dokumentation.)

NGINX Plus R28 decodiert den TLV und übergibt die Endpunkt-ID in der Variable $proxy_protocol_tlv_aws_vpce_id an Backend-Anwendungen.

Hinweis: In dem server-Block, in dem Sie auf die Variable $proxy_protocol_tlv_aws_vpce_id verweisen, müssen Sie außerdem den Parameter proxy_protocol in die listen[HTTP][Stream]-Direktive aufnehmen. Ein Beispiel finden Sie in Zeile 8 der direkt darunter stehenden Datei proxy_protocol_v2.conf.

Diese Beispielkonfiguration für AWS prüft, ob die VPC-ID zulässig ist, und übergibt sie gegebenenfalls als zweiten Parameter der Anweisung „add_header“ an die Backend-Anwendung:

Codebeispiel wird geladen…

Unterstützung des PROXY-Protokolls v2 für GCP

In GCP Private Service Connect ist die Quell-IP-Adresse für den von Clients eingehenden Datenverkehr eine „Adresse in einem der Private Service Connect-Subnetze im VPC-Netzwerk des Dienstanbieters“. Wenn die Backend-Anwendung die tatsächlichen IP-Adressen und andere Kennungen der Clients benötigt, können diese den Headern des PROXY-Protokolls v2 entnommen werden.

In GCP codiert ein benutzerdefinierter TLV-Vektor die zu diesem Zeitpunkt eindeutige Verbindungs-ID im PROXY-Protocol-v2-Header pscConnectionId. (Weitere Informationen finden Sie in der GCP-Dokumentation.)

NGINX Plus R28 decodiert den TLV und übergibt den Wert von pscConnectionId in der Variable $proxy_protocol_tlv_gcp_conn_id an Backend-Anwendungen.

Hinweis: In dem server-Block, in dem Sie auf die Variable $proxy_protocol_tlv_gcp_conn_id verweisen, müssen Sie außerdem den Parameter proxy_protocol in die listen[HTTP][Stream]-Direktive aufnehmen. Ein Beispiel finden Sie oben in Zeile 8 von proxy_protocol_v2.conf.

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

Bei Microsoft Azure Private Link ist die Quell-IP-Adresse für den von Clients eingehenden Datenverkehr die „aufseiten des Dienstanbieters mithilfe der aus dem virtuellen Netzwerk des Anbieters zugewiesenen NAT-IP-[Adresse] per Network Address Translation (NAT) übersetzte Adresse“. Wenn die Backend-Anwendung die tatsächlichen IP-Adressen und andere Kennungen der Clients benötigt, können diese aus den Headern des PROXY-Protokolls v2 abgerufen werden.

In Azure codiert ein benutzerdefinierter TLV-Vektor die LinkID des Clients im PROXY-Protocol-v2-Header PP2_SUBTYPE_AZURE_PRIVATEENDPOINT_LINKID. (Weitere Informationen finden Sie in der Azure-Dokumentation.)

NGINX Plus R28 dekodiert den TLV und übergibt die LinkID in der Variablen $proxy_protocol_tlv_azure_pel_id an Backend-Anwendungen.

Hinweis: In dem server-Block, in dem Sie auf die Variable $proxy_protocol_tlv_azure_pel_id verweisen, müssen Sie außerdem den Parameter proxy_protocol in die listen[HTTP][Stream]-Direktive aufnehmen. Ein Beispiel finden Sie oben in Zeile 8 von proxy_protocol_v2.conf.

Variablenunterstützung für den samesite-Parameter des Sticky-Cookies

In früheren Versionen von NGINX Plus waren drei statische Werte (strict, lax und none) für den Parameter samesite der Direktive sticky cookie zulässig. In NGINX Plus R28 kann der Wert auch eine Variable sein.

Standardmäßig (wenn kein Parameter samesite vorhanden ist) fügt NGINX dem Cookie das Attribut SameSite nicht hinzu. Wenn der Parameter samesite eine Variable ist, hängt das Ergebnis davon ab, welchen Wert die Variable zur Laufzeit annimmt:

• In einen der Standardwerte (strict, lax oder none) – NGINX fügt das Attribut SameSite mit diesem Wert ein
• Auf einen leeren Wert ("") – NGINX fügt das Attribut SameSite nicht ein
• Auf einen beliebigen anderen Wert, der auf eine Fehlkonfiguration hinweist – NGINX fügt das auf SameSite gesetzte Attribut Strict ein (die sicherste Einstellung)

Diese Beispielkonfiguration legt das Attribut samesite basierend auf dem Wert des HTTP-Headers User-Agent fest (dies eignet sich für ältere Clients, die das Attribut SameSite nicht unterstützen):

Codebeispiel wird geladen…

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, die seit der Veröffentlichung von NGINX Plus R27 vorgenommen wurden (in NGINX 1.23.0 bis 1.23.2). Zu den Änderungen und Fehlerbehebungen gehören:

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

Eine vollständige Liste der neuen Funktionen, Änderungen und Fehlerbehebungen, die aus diesen Releases übernommen wurden, finden Sie in der Datei „CHANGES“.

Änderungen am NGINX-JavaScript-Modul

NGINX Plus R28 enthält Änderungen und Fehlerbehebungen aus den Versionen 0.7.5 bis 0.7.8 des NGINX-JavaScript-Moduls (njs). Einige der wichtigsten davon stellen wir in unserem Blogbeitrag „Machen Sie Ihre NGINX-Konfiguration mit njs 0.7.7 noch modularer und wiederverwendbarer“ vor. Eine vollständige Liste finden Sie in der Datei „Changes“.

NGINX Plus aktualisieren oder testen

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich ein Upgrade auf NGINX Plus R28 durchzuführen. Damit erhalten Sie außerdem mehrere zusätzliche Fehlerbehebungen und Verbesserungen, und NGINX kann Sie besser unterstützen, wenn Sie ein Support-Ticket erstellen müssen.

Wenn Sie NGINX Plus noch nicht ausprobiert haben, empfehlen wir Ihnen, es zu testen – für Sicherheit, Lastverteilung und als API-Gateway oder als vollständig unterstützten Webserver mit erweiterten APIs für Überwachung und Verwaltung. Starten Sie noch heute mit einer kostenlosen 30-Tage-Testversion.

Über den Autor

Robert HaynesManager für technisches Marketing

Weitere Blogbeiträge von Robert Haynes