Annonce de NGINX Plus R31

Nous sommes heureux d’annoncer la disponibilité de NGINX Plus Release 31 (R31). Basé sur NGINX Open Source, NGINXPlus est le seul serveur Web logiciel tout-en-un, équilibreur de charge, proxy inverse, cache de contenu et passerelle API.

Les fonctionnalités nouvelles et améliorées de NGINX Plus R31 incluent :

• Rapports d’utilisation NGINX natifs – NGINX Plus dispose désormais d’une prise en charge native des rapports sur les déploiements NGINX dans votre organisation, permettant une vue consolidée de votre infrastructure NGINX dans NGINX Instance Manager. Cette fonctionnalité permet une gouvernance améliorée des instances NGINX à des fins de conformité.
• Améliorations apportées à la configuration SNI – Auparavant, le nom du serveur qui passait par l’identification du nom du serveur (SNI) utilisait la directive proxy_ssl_name et était utilisé par tous les serveurs du groupe en amont. NGINX Plus R31 permet de définir ce SNI sur un serveur en amont sélectionné.
• Exécution de tâches périodiques avec NGINX JavaScript – NGINX JavaScript introduit la directive js_periodic pour permettre l’exécution de contenu à intervalles périodiques. Cette amélioration élimine le besoin de configurer une tâche cron et peut être configurée pour s'exécuter sur tous les processus de travail ou sur des processus spécifiques pour des performances optimales.
• Une meilleure expérience de démarrage NGINX – NGINX Plus R31 apporte des améliorations à l’expérience de démarrage globale de NGINX dans les cas où il existe un nombre élevé d’« emplacements » dans la configuration.
• Optimisations et améliorations de QUIC+HTTP/3 – NGINX Plus R31 ajoute de nombreuses améliorations et optimisations des performances à l'implémentation QUIC, notamment la prise en charge de la découverte de l'unité de transmission maximale (MTU) du chemin, des améliorations du contrôle de la congestion et la possibilité de réutiliser le contexte cryptographique sur l'ensemble de votre session QUIC.

La version est complétée par de nouvelles fonctionnalités et des corrections de bugs héritées de NGINX Open Source et des mises à jour du module JavaScript NGINX.

Changements importants dans le comportement

Note: Si vous effectuez une mise à niveau à partir d'une version autre que NGINX Plus R30, assurez-vous de consulter la section Modifications importantes du comportement dans les blogs d'annonces précédents pour toutes les versions entre votre version actuelle et celle-ci.

Obsolescence du module OpenTracing

Le module OpenTracing qui a été introduit dans NGINX Plus R18 est désormais obsolète. Il est prévu qu'il soit supprimé à partir de la future version de NGINX Plus R34. Le package sera disponible avec toutes les versions de NGINX Plus d'ici là. Il est fortement conseillé d'utiliser le module OpenTelemetry qui a été introduit dans NGINX Plus R29.

Message d'avertissement pour ne pas avoir signalé l'utilisation de NGINX

Les utilisateurs de NGINX Plus sont tenus de signaler leur utilisation de NGINX à F5 à des fins de conformité. Avec la sortie de NGINX Plus R31, la possibilité de signaler votre utilisation de NGINX à NGINX Instance Manager est nativement présente et est activée par défaut. Un message d'avertissement est enregistré si l'instance NGINX n'est pas en mesure de fournir ses informations d'utilisation à NGINX Instance Manager pour une raison quelconque.

Reportez-vous à la section Rapports d’utilisation natifs de NGINX pour plus de détails sur la configuration de cette fonctionnalité dans votre environnement.

Modifications apportées à la prise en charge de la plateforme

Nouveaux systèmes d’exploitation pris en charge :

• FreeBSD 14
• Alpine 3.19

Anciens systèmes d’exploitation supprimés :

• Alpine 3.15, qui a atteint la fin de vie (EOL) le 1er novembre 2023

Les anciens systèmes d'exploitation sont obsolètes et leur suppression est prévue dans NGINX Plus R32 :

• FreeBSD 12 qui atteindra sa fin de vie le 31 décembre 2023

Nouvelles fonctionnalités en détail

Rapports d'utilisation natifs de NGINX

NGINX Plus R31 introduit une communication native avec NGINX Instance Manager sur votre réseau pour automatiser la conformité des licences. Si vous participez au programme de consommation F5 Flex , vous n'aurez plus besoin de suivre manuellement vos instances NGINX Plus.

Par défaut, NGINX Plus tentera de découvrir NGINX Instance Manager au démarrage via une recherche DNS du nom d'hôte nginx-mgmt.local . Bien que le nom d'hôte soit configurable, nous suggérons (pour plus de simplicité) d'ajouter un enregistrement A à votre DNS local, en associant le nom d'hôte par défaut à l'adresse IP du système exécutant NGINX Instance Manager. NGINX Plus établira ensuite une connexion TLS à NGINX Instance Manager, signalant son numéro de version, son nom d'hôte et son identifiant unique toutes les trente minutes.

Pour une couche de sécurité supplémentaire, nous vous suggérons également de provisionner cette connexion avec mTLS en utilisant le bloc de configuration de gestion facultatif. À un rythme régulier, NGINX Instance Manager signalera ensuite l'utilisation totale des instances NGINX Plus à un service F5.

Vous verrez un message d'avertissement dans votre journal des erreurs si NGINX Plus rencontre des problèmes lors de la résolution du nom d'hôte nginx-mgmt.local ou de la communication avec NGINX Instance Manager.

Voici un exemple de message d'erreur indiquant que l'instance NGINX Plus ne parvient pas à résoudre nginx-mgmt.local :

2023/12/21 21:02:01 [warn] 3050#3050 : rapport d'utilisation : hôte introuvable résolvant le point de terminaison « nginx-mgmt.local »

Et voici un exemple de message d'erreur indiquant que l'instance NGINX Plus rencontre des difficultés de communication avec NGINX Instance Manager :

2023/12/21 21:02:01 [warn] 3184#3184 : rapport d'utilisation : délai de connexion expiré

Personnalisation des paramètres du bloc de configuration de gestion

Si vous préférez affiner la manière dont votre instance NGINX Plus communique avec NGINX Instance Manager, vous pouvez choisir d'utiliser le nouveau bloc de configuration de gestion et les directives associées. Cela vous permet de définir un résolveur personnalisé, d’utiliser une adresse IP ou un nom d’hôte alternatif pour identifier votre système NGINX Instance Manager, de spécifier les options TLS, d’utiliser mTLS pour une sécurité renforcée et de spécifier d’autres paramètres personnalisés.

Voici un exemple de configuration personnalisée :

mgmt {
usage_report endpoint=instance-manager.local interval=30m;
resolver 192.168.0.2; # Exemple d'adresse IP DNS interne

uuid_file /var/lib/nginx/nginx.id;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers DEFAULT;

ssl_certificate client.pem;
ssl_certificate_key client.key;

ssl_trusted_certificate trust_ca_cert.crt;
ssl_verify on;
ssl_verify_depth 2;
}

Pour plus de détails sur ces directives, veuillez consulter la documentation du produit .

Pour plus d'informations sur le téléchargement et l'installation de NGINX Instance Manager, consultez le guide d'installation .

Note: Si vous utilisez une version antérieure de NGINX Plus, vous pouvez toujours signaler vos instances en suivant ces instructions .

Améliorations de la configuration SNI

Avant cette version, NGINX Plus supposait que tous les serveurs d’un groupe en amont étaient identiques. Cela signifie qu'ils devaient pouvoir répondre aux mêmes requêtes, répondre au même nom SNI (lorsque proxy_ssl_server_name est utilisé) et renvoyer des certificats SSL correspondant au même nom.

Il existe cependant des scénarios dans lesquels ce comportement n’est pas suffisant. Par exemple, si plusieurs serveurs virtuels sont partagés derrière un serveur en amont et doivent être distingués par un SNI et/ou un en-tête d'hôte différent pour acheminer les requêtes vers des ressources spécifiques. Il est également possible que le même certificat ne puisse pas être utilisé sur tous les serveurs du groupe en amont ou qu’il existe des limitations pour placer les serveurs en amont dans des groupes en amont distincts.

NGINX Plus R31 introduit la prise en charge de la configuration SNI par serveur en amont. La variable $upstream_last_server_name fait référence au nom du serveur en amont sélectionné, qui peut ensuite être transmis au serveur proxy à l'aide des directives proxy_ssl_server_name et proxy_ssl_name .

Voici comment définir proxy_ssl_server_name sur on , permettant à un nom de serveur de passer via SNI :
proxy_ssl_server_name activé ;

Et voici comment transmettre le nom du serveur en amont sélectionné à l'aide de proxy_ssl_name :
nom_proxy_ssl $upstream_last_server_name;

Exécution de tâches périodiques avec NGINX JavaScript

NGINX JavaScript v0.8.1 a introduit une nouvelle directive js_periodic qui est disponible dans les contextes http et stream . Cette directive permet de spécifier un gestionnaire de contenu JavaScript à exécuter à intervalles réguliers. Cela est utile dans les cas où le code personnalisé doit être exécuté à intervalles réguliers et peut nécessiter l'accès aux variables NGINX. Le gestionnaire de contenu reçoit un objet de session comme argument et a également accès aux objets globaux.

Par défaut, le gestionnaire de contenu s'exécute sur le processus de travail 0, mais il peut être configuré pour s'exécuter sur des processus de travail spécifiques ou sur tous les processus de travail.

Cette directive est disponible dans le contexte de localisation :

example.conf :

location @periodics {

# à exécuter à des intervalles de 15 minutes dans les processus de travail 1 et 3
js_periodic main.handler interval=900s worker_affinity=0101 ;

resolver 10.0.0.1 ;
js_fetch_trusted_certificate /path/to/certificate.pem ;
}

example.js :

gestionnaire(s) de fonctions asynchrones {
let reply = wait ngx.fetch('https://nginx.org/en/docs/njs/');
let body = wait reply.text();

ngx.log(ngx.INFO, body);
}

Pour les détails de syntaxe et de configuration, veuillez vous référer à la documentation JavaScript de NGINX .

Une meilleure expérience de démarrage NGINX

Dans les scénarios où une configuration NGINX contient un nombre élevé d’« emplacements », le temps de démarrage de votre NGINX peut prendre un temps considérable. Dans de nombreux cas, cela pourrait ne pas être acceptable. Le problème fondamental réside dans l’algorithme de tri utilisé pour trier la liste des emplacements.

NGINX R31 introduit une amélioration qui remplace l'algorithme de tri existant du tri par insertion , qui a une complexité temporelle de O(n2) , au tri par fusion avec une complexité temporelle de O(n*log n) .

Dans une configuration de test avec 20 000 emplacements, il a été observé que le temps de démarrage total était réduit de 8 secondes à 0,9 seconde après cette mise à jour.

Optimisations et améliorations de QUIC+HTTP/3

NGINX Plus R31 introduit plusieurs améliorations et optimisations de performances dans l'implémentation QUIC+HTTP/3, telles que :

• Découverte de l'unité de transmission maximale (MTU) du chemin lors de l'utilisation de QUIC+HTTP/3 – Le MTU du chemin est une mesure en octets de la plus grande taille de trame ou de paquet de données pouvant être transmis sur un réseau. Avant ce changement, l’implémentation QUIC utilisait un MTU de chemin de 1 200 octets pour tous les datagrammes. NGINX Plus prend désormais en charge la découverte de la taille MTU du chemin, qui est ensuite utilisée pour tous les datagrammes sortants.
• Réutiliser le contexte cryptographique sur l’ensemble de la session QUIC – Cette optimisation concerne le comportement de chiffrement et de déchiffrement des paquets QUIC. Auparavant, un contexte cryptographique distinct était créé pour chaque opération de chiffrement ou de déchiffrement. Désormais, le même contexte est utilisé dans toute la session QUIC, ce qui améliore les performances.

Les optimisations de performances supplémentaires incluent la réduction des retards potentiels lors de l'envoi de paquets d'accusé de réception, le placement des trames d'accusé de réception (ACK) en tête de la file d'attente pour réduire les retransmissions de trames et les retards de livraison des trames ACK, ainsi que des améliorations du comportement de contrôle de congestion en mode de déchargement de segmentation générique (GSO).

Autres améliorations et corrections de bugs dans NGINX Plus R31

Module de gestion supplémentaire

Dans NGINX Plus R31, ngx_mgmt_module vous permet de signaler les informations d'utilisation de NGINX à NGINX Instance Manager. Ces informations incluent le nom d’hôte NGINX, la version NGINX et un identifiant d’instance unique.

Le module fournit plusieurs directives pour affiner la manière dont votre instance NGINX communique avec NGINX Instance Manager. Pour une liste complète des directives et options de configuration disponibles, reportez-vous à la documentation NGINX .

Corrections de bugs dans le module MQTT

La prise en charge de Message Queuing Telemetry Transport (MQTT) a été introduite dans NGINX Plus R29 et cette version contient quelques correctifs de bogues pour les problèmes observés dans le module MQTT.

Un correctif important résout un problème de rejet des messages CONNECT lorsqu’un mot de passe n’était pas fourni. Auparavant, nous nous attendions inconditionnellement à ce que le champ du nom d'utilisateur soit suivi d'un mot de passe. Il existe cependant des cas particuliers dans la spécification MQTT – comme l’authentification anonyme – où la fourniture d’un mot de passe n’est pas obligatoire. Le correctif vérifie conditionnellement si le mot de passe est attendu ou non en regardant le champ cflags du paquet. Si le drapeau n'est pas défini, cela implique que le mot de passe n'est pas obligatoire.

Un autre correctif de bogue arrête l'analyse des messages MQTT CONNECT lorsque la longueur du message est inférieure au nombre d'octets reçus.

Prise en charge des jetons de serveur HTTP/3 avec des variables

NGINX Plus R31 ajoute la prise en charge des variables server_tokens manquantes pour les connexions HTTP/3. Le champ de chaîne peut être utilisé pour définir explicitement la signature sur les pages d'erreur et la valeur du champ d'en-tête de réponse « Serveur ». Si le champ chaîne est vide, cela désactive l'émission du champ « Serveur ».

Modifications héritées de NGINX Open Source

NGINX Plus R31 est basé sur NGINX Open Source 1.25.3 et hérite des modifications fonctionnelles, des fonctionnalités et des corrections de bogues apportées depuis la sortie de NGINX Plus R30 (dans NGINX 1.25.2 et 1.25.3).

Caractéristiques

• Découverte du chemin MTU lors de l’utilisation de QUIC – Auparavant, une taille par défaut de 1 200 MTU était utilisée pour tous les datagrammes. Dans le cadre des améliorations de QUIC+HTTP/3, nous avons ajouté la prise en charge de la découverte de la taille MTU du chemin qui est ensuite utilisée pour tous les datagrammes sortants.
• Optimisations des performances dans QUIC – La version principale NGINX 1.25.2 a introduit des optimisations dans l’implémentation QUIC pour réutiliser le contexte cryptographique pour l’ensemble de la session QUIC. Cela réduit les délais d'envoi des paquets ACK et place les trames ACK en tête de la file d'attente pour réduire les retransmissions de trames et les délais de livraison des trames ACK.
• Prise en charge de la suite de chiffrement TLS_AES_128_CCM_SHA256 lors de l'utilisation de HTTP/3 – Cette amélioration ajoute la prise en charge de TLS_AES_128_CCM_SHA256 à QUIC, qui est actuellement la seule suite de chiffrement non prise en charge par l'implémentation NGINX QUIC. Il est désactivé par défaut dans OpenSSL et peut être activé avec cette directive : ssl_conf_command Ciphersuites TLS_AES_128_CCM_SHA256 ;
• Fournir nginx appName lors du chargement des configurations OpenSSL – Lors de l'utilisation de l'interface OPENSSL_init_ssl() , au lieu de vérifier OPENSSL_VERSION_NUMBER , NGINX teste désormais si OPENSSL_INIT_LOAD_CONFIG est défini et vrai. Cela garantit que l'interface n'est pas utilisée avec BoringSSL et LibreSSL, car ils ne fournissent pas de paramètres d'initialisation de bibliothèque supplémentaires (notamment l'appel OPENSSL_INIT_set_config_appname() ).

Changements

• Modification de l’algorithme de tri de la file d’attente NGINX – Comme détaillé ci-dessus, NGINX utilise désormais le tri par fusion , qui a une complexité temporelle de O(n*log n) . Cela crée une meilleure expérience de démarrage NGINX , en particulier lorsqu'il y a un très grand nombre d'« emplacements » dans la configuration.
• Limite de gestion des flux d’itération HTTP/2 – Cette amélioration garantit une détection précoce des attaques par inondation sur NGINX en imposant une limite au nombre de nouveaux flux pouvant être introduits dans une boucle d’événements. Cette limite est deux fois supérieure à la valeur et est configurée à l'aide de http2_max_concurrent_streams . Elle est appliquée même si le seuil maximal de flux simultanés autorisés n'est jamais atteint pour tenir compte des cas où les flux sont réinitialisés immédiatement après l'envoi des requêtes.

Corrections de bugs

• Gestion de tampon fixe avec détection automatique HTTP/2 – Dans le cadre de la détection automatique HTTP/2 sur les connexions TCP simples, les données initiales sont d’abord lues dans un tampon spécifié par la directive client_header_buffer_size qui n’a pas de réservation d’état. Cela a provoqué un problème où le tampon pouvait être écrasé lors de l'enregistrement de l'état. Le correctif actuel permet de lire uniquement la taille de tampon disponible au lieu de la taille de tampon fixe. Ce bug est apparu pour la première fois dans la version principale de NGINX 1.25.1 (NGINX Plus R30).
• Mode de transport incorrect dans le mode de compatibilité OpenSSL – Avant cette version, la couche de compatibilité OpenSSL provoquait un retard de connexion, dans le cas où un paramètre de transport incorrect était envoyé par le client. Le correctif gère sans effort ce comportement en informant d’abord l’utilisateur du paramètre incorrect, puis en fermant la connexion.
• Correction de la gestion des en-têtes d'état sans phrase de raison – Un en-tête d'état avec une « phrase de raison » vide comme Statut : 404 était valide selon la spécification Common Gateway Interface (CGI) mais a perdu l'espace de fin lors de l'analyse. Cela a généré une ligne d'état HTTP/1.1 404 dans la réponse, ce qui viole la spécification HTTP en raison d'un espace de fin manquant. Avec ce correctif de bogue, seul le code d'état est utilisé à partir de ces lignes d'en-tête d'état courtes, donc NGINX générera la ligne d'état elle-même avec l'espace et la phrase de raison appropriée si disponible.
• Fuite de mémoire corrigée lors des rechargements de configuration avec PCRE2 – Ce problème se produisait lorsque NGINX était configuré pour utiliser PCRE2 dans la version 1.21.5 ou supérieure.

Pour la liste complète des nouveaux changements, fonctionnalités, corrections de bogues et solutions de contournement hérités des versions récentes, consultez le fichier NGINX CHANGES .

Modifications apportées au module JavaScript NGINX

NGINX Plus R31 intègre les modifications du module NGINX JavaScript (njs) version 0.8.2. Voici la liste des changements notables dans njs depuis la version 0.8.0 (qui faisait partie de la version NGINX Plus R30).

Caractéristiques

• Objet console introduit. Ces méthodes ont été introduites : error() , info() , log() , time() , timeEnd() et warn() .
• Introduction de la directive js_periodic pour http et stream qui permet de spécifier un gestionnaire JS à exécuter à intervalles réguliers.
• Méthode items() implémentée d'un dictionnaire partagé . Cette méthode renvoie toutes les paires clé-valeur non expirées.

Changements

• Extension du module « fs ». Méthode existsSync() ajoutée.

Corrections de bugs

• Correction du module « xml ». Correction de la gestion des exceptions XML cassées dans la méthode parse() .
• Correction de RegExp.prototype.exec() avec expression régulière globale (regexp) et entrée Unicode.
• Méthodes fixed size() et keys() d'un dictionnaire partagé .
• Correction d'une exception erronée dans r.internalRedirect() qui a été introduite dans la version 0.8.0.
• Correction de l'ordre incorrect des clés dans Object.getOwnPropertyNames() .
• Correction de la gestion des réponses HEAD avec une longueur de contenu importante dans l'API de récupération.
• Méthode items() fixe pour un dictionnaire partagé.

Pour une liste complète de toutes les fonctionnalités, modifications et corrections de bogues, consultez le journal des modifications njs.

Mettre à niveau ou essayer NGINX Plus

Si vous utilisez NGINX Plus, nous vous encourageons vivement à effectuer une mise à niveau vers NGINX Plus R31 dès que possible. En plus de toutes ces nouvelles fonctionnalités intéressantes, vous bénéficierez également de plusieurs correctifs et améliorations supplémentaires, et le fait d'être à jour aidera NGINX à vous aider si vous devez ouvrir un ticket d'assistance.

Si vous n’avez pas essayé NGINX Plus, nous vous encourageons à le découvrir. Vous pouvez l'utiliser pour la sécurité, l'équilibrage de charge et les cas d'utilisation de passerelle API, ou comme serveur Web entièrement pris en charge avec des API de surveillance et de gestion améliorées. Commencez dès aujourd'hui avec un essai gratuit de 30 jours .