Ankündigung von NGINX Plus R10

[ Anmerkung des Herausgebers – Der Verkauf des NGINX ModSecurity WAF- Moduls für NGINX Plus endete offiziell am 1. April 2022 , und mit Wirkung zum 31. März 2024 wird es nicht mehr unterstützt . Weitere Einzelheiten finden Sie unter „F5 NGINX ModSecurity WAF wird eingestellt“<.htmla> in unserem Blog.]

Wir freuen uns, NGINX Plus Release 10 (R10) ankündigen zu dürfen, unsere bisher bedeutendste Version. NGINX Plus erweitert NGINX Open Source um erweiterte Funktionen und preisgekrönten Support und bietet Kunden eine komplette Lösung zur Anwendungsbereitstellung. Mit dieser Version stellen wir zahlreiche neue Funktionen bereit, mit denen die Sicherheit und Leistung der von NGINX Plus bereitgestellten Anwendungen erheblich verbessert wird. Darüber hinaus bieten wir zusätzliche Funktionen für eine verbesserte Netzwerkintegration und Unterstützung für die Anpassung von NGINX Plus durch Skripting.

[ Herausgeber – Weitere Einzelheiten zu den wichtigsten neuen Funktionen in NGINX Plus R10 finden Sie in den folgenden verwandten Ressourcen:

• Authentifizieren von API-Clients mit JWT und NGINX Plus
• NGINX Plus R10 nutzt die Leistung von IBM
• Authentifizieren von Benutzern bei vorhandenen Anwendungen mit OpenID Connect und NGINX Plus
• Verwenden des NGINX-JavaScript-Moduls zum schrittweisen Umstellen von Clients auf einen neuen Server
• IP-Transparenz und Direct Server Return mit NGINX und NGINX Plus als transparenter Proxy
• Was ist neu in NGINX Plus R10? (On-Demand-Webinar)

]

NGINX Plus R10 enthält die Erstveröffentlichung unserer Web Application Firewall (WAF) , die von ModSecurity betrieben und vollständig von NGINX, Inc. unterstützt wird. Laut Akamai haben Angriffe auf Webanwendungen im vergangenen Jahr um 50 % zugenommen und DDoS-Angriffe haben sich mehr als verdoppelt. Heutzutage ist jede Anwendung dem Risiko eines Angriffs ausgesetzt. NGINX ModSecurity WAF trägt zum Schutz von Webanwendungen vor böswilligen Benutzern bei und bietet Kunden ein vielseitiges Tool zum Schutz ihrer Apps und Daten.

NGINX ModSecurity WAF basiert auf der neuen ModSecurity 3 -Software und läuft nativ innerhalb von NGINX Plus. Es ist als kostenpflichtige Option in unserem Repository für dynamische Module verfügbar, wird von NGINX, Inc. unterstützt und wurde gründlich mit NGINX Plus getestet. Wir arbeiten mit Trustwave zusammen und halten getestete Updates bereit, während wir Funktionen hinzufügen, die Leistung verbessern und etwaige Probleme beheben.

Zwei weitere neue Funktionen verbessern die Sicherheitsfunktionen von NGINX Plus noch weiter:

• JSON-Web-Token – Viele unserer Kunden verwenden NGINX Plus als API-Gateway und haben uns nach einer allgemeinen und standardmäßigen Methode zur Authentifizierung des Zugriffs auf APIs auf der NGINX Plus-Ebene gefragt. Um diesem Bedarf gerecht zu werden, fügen wir mit dieser Version Unterstützung für die Authentifizierung mit JSON Web Tokens (JWTs) hinzu.

  NGINX Plus kann jetzt ein JWT validieren, bevor Clients Zugriff auf APIs gewährt wird. Mithilfe dieser Funktion können Anwendungsadministratoren den Zugriff auf ihre APIs mithilfe eines offenen Standards sichern und so die Abhängigkeit des Anbieters von einem proprietären Standard vermeiden. Die native JWT-Unterstützung reduziert außerdem die Komplexität für Anwendungsadministratoren, indem Authentifizierungsvorgänge – wie etwa die Validierung OAuth 2.0-kompatibler OpenID Connect-Tokens – von Anwendungsservern auf NGINX Plus ausgelagert werden.

• „Dual-Stack“-Unterstützung für ECC- und RSA-Zertifikate – Mit NGINX Plus R10 können Sie SSL/TLS-Dienste sowohl mit RSA- als auch mit ECC-Zertifikaten veröffentlichen. NGINX Plus wählt basierend auf den Fähigkeiten jedes Clients das optimale Zertifikat aus, sodass moderne Clients schnellere ECC-Zertifikate verwenden können, während ältere, nur RSA-basierte Clients weiterhin unterstützt werden. ECC-Zertifikate können bis zu dreimal schneller sein als RSA-Zertifikate gleicher Stärke. Dies bedeutet mehr SSL/TLS-Verbindungen pro Server und schnellere SSL/TLS-Handshakes.

Zusätzlich zu den Sicherheitsfunktionen umfasst NGINX Plus R10:

• Transparente Proxy-Unterstützung – Obwohl viele moderne HTTP-Anwendungen so konfiguriert werden können, dass sie auf einen X-Forwarded-For- Header angewiesen sind, verweisen einige ältere Anwendungen und andere TCP- oder UDP-Dienste aus Protokollierungs-, Sicherheits- oder Authentifizierungsgründen auf die Quell-IP-Adresse der Transaktion.

  NGINX Plus kann jetzt die Quell-IP-Adresse und den Port von HTTP- und TCP-Verbindungen sowie UDP-Datagrammen, die es an Upstream-Server weiterleitet, „fälschen“. Dies kann verwendet werden, um IP-Transparenz bereitzustellen, eine Konfiguration, bei der NGINX Plus Pakete mit der IP-Adresse des Remote-Clients sendet, sodass der Upstream-Server die Pakete als von dieser Adresse stammend erkennt und nicht als von einer lokalen IP-Adresse auf dem NGINX Plus-Server. Mit dieser Funktion kann auch Direct Server Return für UDP-basierte Protokolle aktiviert werden.

• Unterstützung für NGINX JavaScript-Modul – Das NGINX JavaScript-Modul ist die Konfigurations- und Steuerungssprache der nächsten Generation für NGINX und NGINX Plus und bietet Benutzern umfassende und detaillierte Kontrolle über die Bereitstellung und Sicherung ihrer Anwendungen. In dieser Vorabversion erhöht das NGINX JavaScript-Modul Ihre Kontrolle über HTTP-, TCP- und UDP-Verkehr, generiert Antworten und trifft präzise Entscheidungen, um Anfragen an die optimalen Server weiterzuleiten.
• Weitere Verbesserungen beim TCP- und UDP-Lastausgleich – Erweiterungen des Stream-Moduls fügen Unterstützung für weitere NGINX-Variablen , Berechnungen mithilfe der Map- Direktive, Unterstützung für A/B-Tests mit der Split_Clients -Direktive, Geo- und GeoIP- Operationen und selektives Routing ( variabler Parameter für die Proxy_Pass- Direktive ) hinzu. Diese Erweiterungen ermöglichen Ihnen die Erstellung komplexerer TCP- und UDP-Lastausgleichsrichtlinien, die von der NGINX-Konfigurationssprache und der neuen NGINX-JavaScript-Integration gesteuert werden.

NGINX Plus R10 im Detail

NGINX ModSecurity Web-Anwendungs-Firewall

Das Hauptmerkmal von NGINX Plus R10 ist die Erstveröffentlichung unseres WAF, das auf der bekannten und bewährten ModSecurity- Technologie basiert. Seit seiner ersten Open-Source-Veröffentlichung im Jahr 2002 trägt ModSecurity dazu bei, einige der größten Web-Eigenschaften der Welt vor böswilligen Benutzern zu schützen. Es wird gemeinhin als „Schweizer Taschenmesser“ der Sicherheit bezeichnet. NGINX ModSecurity WAF ist eine kostenpflichtige Option und wird Abonnenten über unser Repository für dynamische Module bereitgestellt.

NGINX ModSecurity WAF ist eine unverzichtbare Lösung zum Schutz kritischer Anwendungen. Es stellt eine kostengünstige Alternative zu unflexiblen und teuren Hardware-Geräten dar, wie sie beispielsweise von F5, Citrix und Imperva angeboten werden, und übertrifft deren Fähigkeiten gleichzeitig durch die Flexibilität der Software. NGINX ModSecurity WAF kann in jeder Umgebung bereitgestellt werden – auf lokalen Servern sowie in öffentlichen, privaten und hybriden Clouds.

Eine WAF arbeitet mit einer Datenbank von „Regeln“, die bösartiges Verhalten definieren, das blockiert und/oder protokolliert werden soll. Der OWASP ModSecurity-Kernregelsatz (CRS) ist einer der am häufigsten verwendeten Regelsätze mit ModSecurity. NGINX ModSecurity WAF verwendet das OWASP CRS, um ein breites Spektrum an Anwendungsangriffen zu identifizieren und zu blockieren, mit Funktionen wie:

• Layer-7-Angriffsschutz – Schützen Sie Ihre Anwendungen vor einer breiten Palette von Angriffen, wie etwa HTTP-Verstößen, SQL-Injection, XSS-, RFI- und LFI-Angriffen und mehr.
• DDoS-Minderung – Sorgen Sie für kontinuierliche Betriebszeit, indem Sie die Auswirkungen komplexer DDoS-Angriffe und Botnetze auf Anwendungsebene eindämmen und verringern.
• Denylisten in Echtzeit – Blockieren Sie bekannte böswillige Benutzer automatisch, indem Sie Datenverkehr von IP-Adressen ablehnen, die aufgrund ihrer Reputation als böswillig gelten.
• PCI-DSS 6.6-Konformität – Beginnen Sie mit der Konformität mit den PCI-DSS 6.6-Anforderungen für sichere Online-Transaktionen.
• Prüfprotokollierung – Reagieren Sie mithilfe der Informationen in detaillierten Protokollen schneller auf Angriffe und anderen anomalen Anwendungsverkehr.

Darüber hinaus sind von verschiedenen Anbietern, beispielsweise TrustWave , zusätzliche Regelsätze zu unterschiedlichen Kosten erhältlich. Darüber hinaus können Sie mit der leistungsstarken Regelsprache von ModSecurity Ihre eigenen benutzerdefinierten Regeln definieren, die die von Ihnen verwendeten Regelsätze ergänzen.

Support für NGINX ModSecurity WAF wird direkt von NGINX, Inc. bereitgestellt. Unser Supportteam kann Ihnen bei der Installation, Konfiguration und Fehlerbehebung von Problemen mit dem WAF und dem OWASP-Kernregelsatz helfen.

NGINX ModSecurity WAF ist als dynamisches Modul im NGINX Plus-Repository verfügbar, das Sie mit Standardtools zur Paketverwaltung installieren. Diese Befehle sind für Debian‑basierte Betriebssysteme:

# apt-get update # apt-get installiere nginx-plus # apt-get installiere nginx-plus-module-modsecurity

Beachten Sie, dass nur Abonnenten, die das NGINX ModSecurity WAF-Modul erworben haben, sowie Abonnenten und Evaluatoren, die Zugriff angefordert haben, das Paket nginx-plus-module-modsecurity herunterladen können.

Um das NGINX ModSecurity WAF-Modul zu laden, fügen Sie die Direktive load_module in den „Main“-Kontext der obersten Ebene der NGINX Plus-Konfigurationsdatei ein:

Um NGINX ModSecurity WAF mit NGINX Plus zu aktivieren, fügen Sie die Direktive „modsecurity“ zusammen mit der Direktive „modsecurity_rules_file“ ein, um den Regelsatz anzugeben:

Laden Sie dann die NGINX Plus-Konfiguration neu:

# nginx -t und nginx -s neu laden

Native JWT-Unterstützung für OAuth 2.0 und OpenID Connect

Dank nativer Unterstützung für den Authentifizierungsstandard JSON Web Token (JWT) können Sie mit NGINX Plus R10 Ihren Anwendungen und APIs ganz einfach anspruchsvolle Authentifizierungslösungen hinzufügen.

JWT-Token (ausgesprochen „jot“), definiert in RFC 7519 , sind das zugrunde liegende Datenformat für Benutzerinformationen im OpenID Connect -Standard, der die Standardidentitätsschicht über dem OAuth 2.0-Protokoll darstellt. Auch Anbieter von APIs und Microservices greifen aufgrund seiner Einfachheit und Flexibilität auf den JWT-Standard zurück.

[ Herausgeber – Anwendungsfälle, die die native JWT-Unterstützung nutzen, finden Sie in diesen Blogs:

• Authentifizieren von API-Clients mit JWT und NGINX Plus
• Authentifizieren von Benutzern bei vorhandenen Anwendungen mit OpenID Connect und NGINX Plus

]

Als Reverse-Proxy und Load Balancer sitzt NGINX Plus vor den Anwendungen und ist dadurch ideal positioniert, um die Anwendungsentwicklung zu vereinfachen, indem es die Validierung des in jeder HTTP-Anfrage bereitgestellten JWT auslagert. Dies bietet zwei Vorteile. Erstens kann NGINX Plus dazu beitragen, dass nicht authentifizierte, fehlerhaft formatierte und böswillige Anfragen nicht bei der Anwendung eingehen, und sie vor dem Aufwand und den Risiken bewahren, die mit der Verarbeitung solcher Anfragen verbunden sind.

Der zweite Vorteil besteht darin, dass NGINX Plus (nach der Signaturüberprüfung) Zugriff auf alle Felder im validierten JWT hat und die inhärente Leistungsstärke und Flexibilität seiner Konfigurationssyntax nutzen kann, um anspruchsvolle Authentifizierungslösungen sowohl für Microservices als auch für APIs bereitzustellen:

• Ein typischer Anwendungsfall für Microservices besteht darin, dass NGINX Plus das JWT validiert und der Back-End-Anwendung die Identität des authentifizierten Benutzers als HTTP-Header bereitstellt. Dadurch entfällt die Notwendigkeit, in jedem Mikrodienst immer wieder dieselbe Authentifizierungsfunktionalität zu implementieren.
• Bei APIs kann NGINX Plus die Zugriffsrate wirklich pro Benutzer begrenzen, anstatt sich auf die ungefähre Zuordnung von IP-Adressen zu Endbenutzern zu verlassen.

Der folgende Beispiel-Konfigurationsausschnitt von NGINX Plus zeigt, wie JWTs zum Schutz einer Website verwendet werden.

Die Direktive auth_jwt weist NGINX Plus an, JWT zur Authentifizierung von Benutzern zu verwenden, die Anfragen für eine Domäne stellen, in diesem Fall myrealm . Die Direktive „auth_jwt_key_file“ gibt an, welcher JSON Web Key (JWK) zum Validieren der Token-Signatur verwendet werden soll. Er funktioniert wie der öffentliche Schlüssel bei der SSL/TLS-Verschlüsselung. Der Dateispeicherort muss für NGINX Plus zugänglich sein.

Während NGINX Plus das Token validiert und analysiert, erstellt es automatisch NGINX-Variablen für die „ Ansprüche “ im JWT, die damit verbundene Entitäten darstellen (z. B. seinen Aussteller, den Benutzer, an den es ausgestellt wurde, und den beabsichtigten Empfänger). Die Variablennamen beginnen alle mit $jwt_claim_ . Sie können dann die Direktive „add_header“ verwenden, damit NGINX Plus einen Anspruch in Form eines HTTP-Headers, der auf den Wert der Variable „ $jwt_claim_ “ gesetzt ist, an die Backend-Server übergibt. In unserem Beispiel übergibt NGINX Plus die Benutzeridentität an die Backend-Anwendung in der Variable $jwt_claim_sub , die der Benutzer-ID ( Unteranspruch ) im JWT entspricht.

In NGINX Plus R8 haben wir eine Technologievorschau der OAuth2-Unterstützung veröffentlicht. Bei der NGINX Plus R10-Implementierung haben wir das Feedback unserer Kunden berücksichtigt, um eine produktionsreife Implementierung bereitzustellen, die die wertvollsten Anwendungsfälle in der komplexen Welt der Authentifizierung von Benutzern und Computern erreicht.

„Dual‑Stack“ RSA‑ und ECC‑Zertifikatsunterstützung

Es gibt mittlerweile zahlreiche Gründe, den gesamten Anwendungsverkehr mit SSL/TLS zu verschlüsseln. Google belohnt SSL/TLS-verschlüsselte Websites mit einem höheren Suchmaschinen-Ranking . Darüber hinaus schreiben moderne Webstandards wie HTTP/2 eine SSL/TLS-Verschlüsselung für alle Websites vor.

Mit NGINX Plus R10 können Sie SSL/TLS-Dienste sowohl mit RSA- als auch mit ECC-Zertifikaten veröffentlichen. In unseren Tests waren ECC-Zertifikate bis zu dreimal schneller als RSA-Zertifikate gleicher Stärke. Dies bedeutet mehr SSL/TLS-Verbindungen pro Server und schnellere SSL/TLS-Handshakes. NGINX Plus wählt je nach den Fähigkeiten jedes Clients das optimale Zertifikat aus. Dadurch können moderne Clients schnellere ECC-Zertifikate verwenden, während ältere Nur-RSA-Clients weiterhin unterstützt werden.

Um sowohl RSA- als auch ECC-Zertifikate zu unterstützen, fügen Sie in die Konfiguration für einen virtuellen Server einfach ein Paar von ssl_certificate- und ssl_certificate_key -Direktiven für jeden Zertifikatstyp ein, wie im folgenden Beispiel gezeigt.

Transparenter Proxy

Wir fügen NGINX Plus kontinuierlich neue Funktionen hinzu, wie etwa TCP- und UDP- Lastausgleich, um ein breiteres Spektrum an Anwendungen und Bereitstellungsmodellen zu unterstützen. Mit NGINX Plus R10 haben wir eine transparente Proxy-Funktion hinzugefügt, die es NGINX Plus ermöglicht, Pakete unter Verwendung beliebiger Quell-IP-Adressen und Ports an Upstream-Server zu senden. Dies ermöglicht Konfigurationen wie IP-Transparenz und Direct Server Return.

IP-Transparenz ist eine Konfiguration, bei der der Load Balancer (NGINX Plus) die IP-Adresse des Remote-Clients als Quell-IP-Adresse in Paketen verwendet, die er an Upstream-Server sendet. Dies bedeutet, dass Upstream-Server Pakete so erkennen, als kämen sie von der IP-Adresse des Remote-Clients und nicht von einer lokalen IP-Adresse auf dem Load Balancer. Dies ist von Bedeutung, wenn Anwendungen zu Protokollierungs-, Sicherheits-, Ratenbegrenzungs- oder Authentifizierungszwecken auf die Quell-IP-Adresse verweisen.

IP-Transparenz ist außerdem ein Baustein für eine Netzwerk-Lastausgleichstechnik namens Direct Server Return (DSR). NGINX Plus kann DSR für UDP-basierte Protokolle (aber nicht für TCP oder HTTP) durchführen, wodurch die Rückgabepakete den Load Balancer vollständig umgehen und direkt an den Remote-Client gesendet werden können.

IP-Transparenz und DSR werden mit dem neuen transparenten Parameter für die Anweisungen proxy_bind , fastcgi_bind , memcached_bind , scgi_bind und uwsgi_bind konfiguriert. Das folgende Beispiel zeigt, wie DSR für ein DNS-Backend eingerichtet wird. Die Direktive „proxy_responses“ gibt an, dass NGINX Plus keine Serverantworten sehen muss (Null ist der entsprechende Wert für DSR).

Beachten Sie, dass passive Integritätsprüfungen nicht wirksam sind, wenn DSR aktiviert ist, da hierbei NGINX Plus überprüft, ob der Server eine Antwort an den Client gesendet hat. Das Konfigurieren aktiver anwendungsbezogener Integritätsprüfungen ist für eine DSR-Konfiguration obligatorisch. Ein Beispiel finden Sie in unseren ausführlichen Anweisungen zur Konfiguration für DNS-Server mit Lastenausgleich.

IP-Transparenz- und DSR-Konfigurationen sind komplex und erfordern zusätzliche Routing- und Paketumschreibungsanforderungen, die über den Umfang der NGINX Plus-Software hinausgehen. Vollständige Anweisungen finden Sie unter „IP-Transparenz und Direct Server Return mit NGINX und NGINX Plus als transparenter Proxy“ in unserem Blog.

Das NGINX JavaScript-Modul für HTTP-, TCP- und UDP-basierte Anwendungen

[ Editor – Das NGINX JavaScript-Modul hieß früher nginScript. Das Modul wurde in NGINX Plus R12 (und NGINX 1.11.10) allgemein verfügbar.

Ausführliche Informationen zu anderen Anwendungsfällen für das NGINX-JavaScript-Modul finden Sie unter Anwendungsfälle für das NGINX-JavaScript-Modul .

Der Code in diesem Abschnitt wird aktualisiert, um die Direktive js_import zu verwenden, die die Direktive js_include in NGINX Plus R23 und höher ersetzt. Weitere Informationen finden Sie in der Referenzdokumentation für das NGINX-JavaScript-Modul – der Abschnitt „Beispielkonfiguration“ zeigt die richtige Syntax für die NGINX-Konfiguration und JavaScript-Dateien. ]

NGINX Plus R10 enthält eine Vorabversion unserer neuen NGINX JavaScript-Konfigurationssprache. Der Funktionsumfang ist noch nicht vollständig und wir freuen uns über jedes Feedback zur bisherigen Arbeit. Mit NGINX JavaScript können Sie JavaScript-Code verwenden, um komplexe und benutzerdefinierte Aktionen für HTTP-, TCP- und UDP-Verkehr auszuführen. Es bietet eine leistungsstarke neue Möglichkeit zur Kontrolle der Bereitstellung und Sicherung Ihrer Anwendungen. Mit NGINX JavaScript können Sie:

• Schreiben Sie „serverlose“ Funktionen direkt in NGINX Plus mit der leistungsstarken Programmiersprache JavaScript.
• Formatieren, Bearbeiten und Transformieren von API-Daten
• Bereitstellung einfacher TCP-Dienste, wie z. B. eines Zeitservers
• Verwenden Sie JavaScript, um NGINX-Variablen festzulegen, benutzerdefinierte Lastausgleichsentscheidungen zu treffen, Cache-Schlüssel zu speichern und mehr

Die NGINX JavaScript-Vorschau ist in unserem Repository für dynamische Module verfügbar. Sie können es mit Standardtools zur Paketverwaltung installieren. Diese Befehle sind für Debian‑basierte Betriebssysteme:

# apt-get update # apt-get installiere nginx-plus # apt-get installiere nginx-plus-module-njs

Um die NGINX JavaScript-Module für HTTP und TCP/UDP zu laden, fügen Sie die Direktive load_module in den „Main“-Kontext der obersten Ebene der NGINX Plus-Konfigurationsdatei ein:

Laden Sie dann die NGINX Plus-Konfiguration neu, um die NGINX-JavaScript-Module zu laden:

# nginx -t und nginx -s neu laden

Benutzer von NGINX Open Source können NGINX JavaScript aus unserem Open-Source-Code-Repository beziehen.

JavaScript-Code ist nicht direkt in der NGINX Plus-Konfiguration enthalten. Stattdessen wird es mit der Direktive js_import eingelesen. In diesem Beispiel wird der JavaScript-Code für eine einfache „serverlose“ Funktion aus /etc/nginx/conf.d/functions.js eingelesen. Die js_content- Direktive weist NGINX Plus an, die JavaScript-Funktion aufzurufen und die Ergebnisse an den Client zurückzugeben.

Der JavaScript-Code in /etc/nginx/conf.d/functions.js füllt eine Zeichenfolge mit einem angegebenen Zeichensatz auf:

Zusätzliche Merkmale

NGINX Plus R10 führt eine Reihe zusätzlicher Verbesserungen ein, die Sie bei der fehlerfreien Anwendungsbereitstellung unterstützen, darunter:

• Der im Stream- Modul implementierte TCP/UDP-Lastausgleich weist jetzt eine größere Funktionsparität mit dem HTTP-Lastausgleich auf. Zu den neu unterstützten Modulen gehören Split Clients für A/B-Tests, GeoIP zum Ergreifen von Aktionen basierend auf dem geografischen Standort der Clients und Geo zum Definieren von Variablen basierend auf der IP-Adresse. Weitere Informationen sind über zusätzliche NGINX-Variablen verfügbar und Sie können Routing-Entscheidungen treffen, indem Sie eine Variable als Parameter für die Direktive „proxy_pass“ verwenden.
• Ein häufiges Problem bei Anwendungen mit hohem Datenverkehr ist die kurzlebige Porterschöpfung . Dabei können keine neuen Verbindungen zu Upstream-Servern hergestellt werden, weil im Betriebssystem keine Portnummern mehr verfügbar sind. Um dies zu umgehen, verwendet NGINX Plus jetzt die Socket-Option IP_BIND_ADDRESS_NO_PORT, sofern verfügbar. Mit dieser Option können Quellports für ausgehende Verbindungen zu Upstream-Servern wiederverwendet werden, vorausgesetzt, das standardmäßige „4-Tupel“ (Quell-IP-Adresse, Ziel-IP-Adresse, Quellport, Zielport) ist eindeutig. Es ist auf Systemen mit Linux-Kernelversion 4.2 und höher sowie glibc 2.22 und höher verfügbar.
• NGINX Plus generiert die neue Variable $request_id automatisch für jede neue HTTP-Anfrage und weist der Anfrage effektiv eine eindeutige „Transaktions-ID“ zu. Dies erleichtert die Anwendungsverfolgung und bringt APM-Funktionen in Protokollanalysetools. Die Transaktions-ID wird an Backend-Anwendungen und Microservices weitergeleitet, sodass alle Teile des Systems für jede Transaktion eine konsistente Kennung protokollieren können.
• Die Anweisungen proxy_request_buffering , fastcgi_request_buffering , scgi_request_buffering und uwsgi_request_buffering funktionieren jetzt mit HTTP/2 und können zum Umschalten der Anforderungspufferung verwendet werden.
• Mit der neuen Direktive „http2_body_preread_size“ können HTTP/2-Clients sofort mit dem Senden des Anforderungstexts beginnen. Die Direktive steuert die Größe des Puffers, der verwendet wird, bevor NGINX Plus mit dem Lesen des Client-Anforderungstexts beginnt.

Das NGINX Plus-Extraspaket ist veraltet

Wie wir bei der Veröffentlichung von NGINX Plus R9 angekündigt haben , ist R10 die letzte Version, die das NGINX Plus Extras-Paket enthalten wird.

Wir empfehlen Ihnen dringend, Ihre Installations- und Konfigurationsverfahren jetzt zu ändern, um das Paket nginx-plus zu verwenden und die Module im Paket nginx-plus-extras , die Sie tatsächlich verwenden, dynamisch zu laden. Ab NGINX Plus R11 ist dies die einzige Möglichkeit, Module zu verwenden, die nicht im nginx-plus -Paket integriert sind.

Um zum nginx-plus -Paket und zu dynamischen Modulen zu wechseln, führen Sie diese Schritte aus:

1. Entfernen Sie das Paket nginx-plus-extras und installieren Sie nginx-plus und die dynamischen Module, die Sie verwenden möchten. Für Debian‑basierte Systeme lautet der entsprechende Befehlssatz:

   # apt-get update # apt-get remove nginx-plus-extras # apt-get install nginx-plus # apt-get install Modulname

2. Fügen Sie im Hauptkontext (oberste Ebene) in /etc/nginx/nginx.conf eine load_module- Direktive für jedes dynamisch geladene Modul hinzu:

3. Überprüfen Sie die neue Konfiguration auf syntaktische Gültigkeit und laden Sie sie erneut:

   # nginx -t und nginx -s neu laden

Upgrade durchführen oder NGINX Plus testen

Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich auf Release 10 zu aktualisieren. Sie erhalten eine Reihe von Fehlerbehebungen und Verbesserungen und können Ihnen so leichter helfen, wenn Sie ein Support-Ticket erstellen müssen. Installations- und Upgrade-Anweisungen finden Sie im NGINX Plus-Kundenportal .

NOTIZ : NGINX Plus R10 ist die letzte Version, die das Paket nginx-plus-extras enthält. Siehe oben „NGINX Plus Extras-Paket ist veraltet “.

Wenn Sie NGINX Plus noch nicht ausprobiert haben, empfehlen wir Ihnen, es zur Webbeschleunigung, zum Lastenausgleich und zur Anwendungsbereitstellung oder als vollständig unterstützten Webserver mit erweiterten Überwachungs- und Verwaltungs- APIs auszuprobieren. Sie können noch heute kostenlos mit einer 30-tägigen Testversion beginnen und sich selbst davon überzeugen, wie NGINX Plus Ihnen bei der Bereitstellung und Skalierung Ihrer Anwendungen helfen kann.

Weitere Informationen zu NGINX Plus R10

Weitere Einzelheiten zu den wichtigsten neuen Funktionen in NGINX Plus R10 finden Sie in den folgenden zugehörigen Ressourcen:

• Authentifizieren von API-Clients mit JWT und NGINX Plus
• NGINX Plus R10 nutzt die Leistung von IBM
• Authentifizieren von Benutzern bei vorhandenen Anwendungen mit OpenID Connect und NGINX Plus
• Verwenden des NGINX-JavaScript-Moduls zum schrittweisen Umstellen von Clients auf einen neuen Server
• IP-Transparenz und Direct Server Return mit NGINX und NGINX Plus als transparenter Proxy
• Was ist neu in NGINX Plus R10? (On-Demand-Webinar)

[NGINX ModSecurity WAF ist seit dem 1. April 2022 offiziell nicht mehr im Verkauf und wird mit Wirkung zum 31. März 2024 nicht mehr unterstützt. Weitere Einzelheiten finden Sie unter „F5 NGINX ModSecurity WAF wird eingestellt“ in unserem Blog.]