Nous sommes heureux d'annoncer la disponibilité de NGINX Plus Release 28 (R28) . Basé sur NGINX Open Source, NGINX Plus 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 R28 incluent :
Mesures TLS supplémentaires – NGINX Plus R28 collecte des statistiques TLS supplémentaires au niveau du système, côté client et côté serveur, fournissant des informations essentielles lors du dépannage des erreurs liées à SSL/TLS dans la configuration du proxy et pour les connexions aux clients et aux serveurs en amont.
Le tableau de bord de surveillance des activités en direct de NGINX Plus est mis à jour pour afficher les nouvelles données de session SSL.
http
et stream
qui décodent le TLV et définissent une variable pour transmettre l'identifiant client aux services backend.samesite
du cookie collant – Dans NGINX Plus R28 , la valeur du paramètre samesite
de la directive sticky
cookie
peut être une variable. Cette amélioration permet une gestion plus facile du trafic et plus de sécurité.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.
Note: Si vous effectuez une mise à niveau à partir d'une version autre que NGINX Plus R27 , assurez-vous de consulter la section Modifications importantes du comportement dans les blogs d'annonces pour toutes les versions entre votre version actuelle et celle-ci.
Nouveaux systèmes d'exploitation et architectures pris en charge :
Anciens systèmes d’exploitation supprimés :
Systèmes d'exploitation et architectures plus anciens obsolètes et dont la suppression est prévue dans NGINX Plus R29 :
Content-Length
et Transfer-Encoding
en double sont désormais rejetés, ainsi que les réponses avec des en-têtes Content-Length
ou Transfer-Encoding
non valides, ou si Content-Length
et Transfer-Encoding
sont tous deux présents dans la réponseL’observabilité des événements et des erreurs SSL/TLS est importante lors du dépannage des problèmes liés à TLS avec la configuration du proxy, les serveurs en amont et les clients. Depuis l’introduction de l’ API NGINX Plus dans NGINX Plus R13 , NGINX Plus a collecté trois mesures TLS au niveau du système :
poignées de main
– Nombre de poignées de main SSL réussieshandshakes_failed
– Nombre d'échecs de négociation SSL (qui n'incluent pas les échecs de vérification de certificat qui se produisent après la négociation SSL)session_reuses
– Nombre de réutilisations de sessions SSLDans NGINX Plus R27<.htmla> et versions ultérieures, vous pouvez configurer la collecte des trois métriques pour les serveurs en amont individuels et les serveurs virtuels.
NGINX Plus R28 étend l'ensemble des métriques TLS avec de nouveaux compteurs pour les erreurs de négociation et les échecs de validation de certificat dans les modules HTTP et Stream (nous fournissons ici des exemples uniquement pour les modules HTTP, mais les métriques Stream disponibles sont similaires). Pour plus de détails sur la configuration de la collecte de métriques pour les serveurs en amont individuels et les serveurs virtuels, consultez le blog d'annonces NGINX Plus R27<.htmlspan> .
Les compteurs pour les erreurs de négociation suivantes sont nouveaux dans NGINX Plus R28 :
handshake_timeout
– Nombre d'échecs de négociation en raison d'un dépassement de délai de négociationno_common_cipher
– Nombre d'échecs de négociation en raison de l'absence d'un chiffrement commun entre les parties à la négociation (non collecté pour les connexions aux serveurs en amont car cela ne s'applique pas)no_common_protocol
– Nombre d’échecs de négociation en raison de l’absence d’un protocole commun entre les partiespeer_rejected_cert
– Nombre d'échecs de négociation dus au rejet par l'autre partie du certificat présenté par NGINX Plus et à la fourniture du message d'alerte appropriéLes échecs de vérification des certificats sont désormais signalés dans la nouvelle section verify_failures
de la sortie de l'API lorsque vous configurez la vérification des certificats :
ssl_verify_client
[ HTTP ][ Stream ]Pour les connexions aux serveurs avec ces directives spécifiques au protocole :
vérification_grpc_ssl
proxy_ssl_verify
[ HTTP ][ Flux ]uwsgi_ssl_verify
Lorsqu'un échec de vérification de certificat se produit, la métrique de la cause correspondante est incrémentée et la connexion est interrompue. Notez cependant que le compteur de poignées de main
de base est toujours incrémenté car ces échecs se produisent après la réussite de la poignée de main.
Les mesures pour une validation de certificat échouée sont :
expired_cert
– Un pair a présenté un certificat expiréhostname_mismatch
– Le certificat du serveur ne correspond pas au nom d'hôte (non collecté pour les connexions aux clients)no_cert
– Le client n'a pas fourni de certificat comme requis (non collecté pour les connexions aux serveurs en amont)revoked_cert
– Le pair a présenté un certificat révoquéautre
– Compteur explicite pour les autres échecs de vérification de certificatVoici un ensemble d’exemples de mesures TLS pour les connexions HTTP au niveau du système :
$ curl 127.0.0.1:8080/api/8/ssl { "poignées de main": 32, « session_reuses » : 0, « échec de la poignée de main » : 8, « no_common_protocol » : 4, "no_common_cipher": 2, « délai d'attente de la poignée de main » : 0, « certificat_rejeté_par_le_pair » : 0, "vérifier_échecs": { "no_cert": 0, « certificat expiré » : 2, « certificat_révoqué » : 1, « hostname_mismatch » : 2, « autre » : 1 } }
Voici un ensemble d'exemples de mesures pour les connexions entre les clients et le serveur virtuel HTTP s9 (comme indiqué précédemment, le compteur hostname_mismatch
n'est pas collecté pour ces connexions) :
$ curl 127.0.0.1:8080/api/8/http/server_zones/s9 { ... "ssl": { "poignées de main": 0, « session_reuses » : 0, « échec de la poignée de main » : 1, « no_common_protocol » : 0, "no_common_cipher": 1, « délai d'attente de la poignée de main » : 0, « certificat_rejeté_par_le_pair » : 0, "vérifier_échecs": { "no_cert": 0, « certificat expiré » : 0, « certificat_révoqué » : 0, "autre" : 0 } } ... }
Voici un ensemble d'exemples de mesures pour les connexions HTTP aux serveurs du groupe en amont u2 (comme indiqué précédemment, les compteurs no_cert
et no_common_cipher
ne sont pas collectés pour ces connexions) :
$ curl 127.0.0.1:8080/api/8/http/upstreams/u2 { "pairs": [ { "id": 0, "serveur" : "127.0.0.1:8082", "nom": "127.0.0.1:8082", ... "ssl": { "poignées de main": 1, « session_reuses » : 0, « échec de la poignée de main » : 0, "no_common_protocol": 0, « délai d'attente de la poignée de main » : 0, « certificat_rejeté_par_le_pair » : 0, "verify_failures": { "expired_cert": 1, « certificat_révoqué » : 0, « hostname_mismatch » : 0, "autre" : 0 } }, ... } ], }
Pour NGINX Plus R28 et versions ultérieures, le tableau de bord de surveillance des activités en direct affiche les nouvelles mesures TLS décrites ci-dessus. Cette capture d'écran montre les métriques des connexions aux clients. Pour afficher les nouvelles mesures, passez la souris sur la valeur dans la colonne SSL > Échec des poignées de main comme indiqué.
Les trois principaux fournisseurs de cloud – Amazon Web Services (AWS), Google Cloud Platform (GCP) et Microsoft Azure – proposent chacun un « service privé » qui vous permet de permettre à des clients externes d’accéder à vos services sans les exposer sur l’Internet public. Chaque service utilise un identifiant client qui est représenté dans un vecteur type-longueur-valeur (TLV) dans un en-tête de protocole PROXY v2. Les identifiants spécifiques au service sont :
PP2_SUBTYPE_AWS_VPCE_ID
pscConnectionId
PP2_SUBTYPE_AZURE_PRIVATEENDPOINT_LINKID
Par défaut, ces identifiants client ne sont pas transmis aux services back-end. NGINX Plus R28 introduit des modules pour les contextes http
et stream
– ngx_http_proxy_protocol_vendor_module et ngx_stream_proxy_protocol_vendor_module – qui décodent le TLV et définissent une variable pour transmettre l'identifiant aux services backend.
Pour obtenir des informations générales sur la manière dont NGINX Plus utilise le protocole PROXY pour obtenir des adresses IP et d'autres informations sur les clients, consultez Acceptation du protocole PROXY dans le Guide d'administration de NGINX Plus.
Dans AWS, l’adresse IP source du trafic provenant des clients via un service de point de terminaison Virtual Private Cloud (VPC) est l’adresse IP privée du nœud Network Load Balancer. Si l'application backend nécessite les adresses IP réelles et d'autres identifiants pour les clients, ils peuvent être obtenus à partir des en-têtes du protocole PROXY v2.
Dans AWS, un vecteur TLV personnalisé encode l'ID VPC du point de terminaison dans l'en-tête du protocole PROXY v2 PP2_SUBTYPE_AWS_VPCE_ID
. (Pour plus d'informations, consultez la documentation AWS .)
Champ | Longueur (Octets) | Description |
---|---|---|
Taper | 1 | PP2_TYPE_AWS ( 0xEA ) |
Longueur | 2 | La longueur de la valeur |
Valeur | 1 | PP2_SUBTYPE_AWS_VPCE_ID ( 0x01 ) |
Varie (longueur de la valeur moins 1) | L'ID du point de terminaison |
NGINX Plus R28 décode le TLV et transmet l'ID du point de terminaison aux applications back-end dans la variable $proxy_protocol_tlv_aws_vpce_id
.
Note: Dans le bloc serveur
où vous référencez la variable $proxy_protocol_tlv_aws_vpce_id
, vous devez également inclure le paramètre proxy_protocol
à la directive listen
[ HTTP ][ Stream ]. Pour un exemple, voir la ligne 8 de proxy_protocol_v2.conf juste en dessous.
Cet exemple de configuration pour AWS vérifie que l'ID VPC est acceptable et, si tel est le cas, le transmet à l'application back-end en tant que deuxième paramètre de la directive add_header
:
Dans GCP Private Service Connect, l’adresse IP source du trafic provenant des clients est une « adresse dans l’un des sous-réseaux Private Service Connect du réseau VPC du producteur de services ». Si l’application backend nécessite les adresses IP réelles et d’autres identifiants pour les clients, ils peuvent être obtenus à partir des en-têtes du protocole PROXY v2.
Dans GCP, un vecteur TLV personnalisé encode l'ID de connexion unique (à ce moment-là) dans l'en-tête du protocole PROXY v2 pscConnectionId
. (Pour plus d'informations, consultez la documentation GCP .)
Champ | Longueur (octets) | Description |
---|---|---|
Taper | 1 | 0xE0 ( PP2_TYPE_GCP ) |
Longueur | 2 | 0x8 (8 octets) |
Valeur | 8 | L' identifiant pscConnectionId de 8 octets dans l'ordre réseau |
NGINX Plus R28 décode le TLV et transmet la valeur de pscConnectionId
aux applications back-end dans la variable $proxy_protocol_tlv_gcp_conn_id
.
Note: Dans le bloc serveur
où vous référencez la variable $proxy_protocol_tlv_gcp_conn_id
, vous devez également inclure le paramètre proxy_protocol
à la directive listen
[ HTTP ][ Stream ]. Pour un exemple, voir la ligne 8 de proxy_protocol_v2.conf ci-dessus.
Dans Microsoft Azure Private Link, l’adresse IP source du trafic provenant des clients est « l’adresse réseau traduite (NAT) côté fournisseur de services à l’aide de l’adresse IP NAT [adresse] allouée à partir du réseau virtuel du fournisseur ». Si l’application backend nécessite les adresses IP réelles et d’autres identifiants pour les clients, ils peuvent être obtenus à partir des en-têtes du protocole PROXY v2.
Dans Azure, un vecteur TLV personnalisé encode le LinkID du client dans l'en-tête du protocole PROXY v2 PP2_SUBTYPE_AZURE_PRIVATEENDPOINT_LINKID
. (Pour plus d'informations, consultez la documentation Azure .)
Champ | Longueur (Octets) | Description |
---|---|---|
Taper | 1 | PP2_TYPE_AZURE ( 0xEE ) |
Longueur | 2 | Longueur de la valeur |
Valeur | 1 | PP2_SOUS-TYPE_AZURE_PRIVATEENDPOINT_LINKID ( 0x01 ) |
4 | UINT32 (4 octets) représentant le LINKID du point de terminaison privé. Codé au format little-endian. |
NGINX Plus R28 décode le TLV et transmet le LinkID aux applications back-end dans la variable $proxy_protocol_tlv_azure_pel_id
.
Note: Dans le bloc serveur
où vous référencez la variable $proxy_protocol_tlv_azure_pel_id
, vous devez également inclure le paramètre proxy_protocol
dans la directive listen
[ HTTP ][ Stream ]. Pour un exemple, voir la ligne 8 de proxy_protocol_v2.conf ci-dessus.
samesite
Dans les versions précédentes de NGINX Plus, trois valeurs statiques ( strict
, lax
et none
) étaient acceptables pour le paramètre samesite
de la directive sticky
cookie
. Dans NGINX Plus R28 , la valeur peut également être une variable.
Par défaut (il n'y a pas de paramètre samesite
), NGINX n'injecte pas l'attribut SameSite
dans le cookie. Lorsque le paramètre samesite
est une variable, le résultat dépend de la manière dont la variable est résolue au moment de l'exécution :
strict
, lax
et none
) – NGINX injecte l'attribut SameSite
défini sur cette valeur""
) – NGINX n'injecte pas l'attribut SameSite
SameSite
défini sur Strict
(le paramètre le plus sécurisé)Cet exemple de configuration définit l'attribut samesite
en fonction de la valeur de l'en-tête HTTP User-Agent
(cela convient aux clients hérités qui ne prennent pas en charge l'attribut SameSite
) :
NGINX Plus R28 est basé sur NGINX Open Source 1.23.2. et hérite des modifications fonctionnelles et des corrections de bugs apportées depuis la sortie de NGINX Plus R27 (dans NGINX 1.23.0 à 1.23.2). Les modifications et corrections de bogues incluent :
ipv4=off
de la directive de résolution
HTTP désactive la recherche d'adresses IPv4.shared
de la directive ssl_session_cache
, les clés de ticket de session TLS sont désormais tournées automatiquement.crit
à info
.Pour la liste complète des nouvelles fonctionnalités, modifications et corrections de bogues héritées de ces versions, consultez le fichier CHANGES .
NGINX Plus R28 intègre les modifications et les correctifs apportés dans les versions 0.7.5 à 0.7.8 du module JavaScript NGINX (njs). Nous avons mis en évidence certains des plus importants dans Rendez votre configuration NGINX encore plus modulaire et réutilisable avec njs 0.7.7 sur notre blog. Pour une liste complète, voir le fichier Modifications .
Si vous utilisez NGINX Plus, nous vous encourageons vivement à effectuer une mise à niveau vers NGINX Plus R28 dès que possible. Vous bénéficierez également de plusieurs correctifs et améliorations supplémentaires, et cela aidera NGINX à vous aider lorsque vous aurez besoin de créer un ticket d'assistance.
Si vous n'avez pas essayé NGINX Plus, nous vous encourageons à l'essayer - pour la sécurité, l'équilibrage de charge et la passerelle API, ou en tant que serveur Web entièrement pris en charge avec des API de surveillance et de gestion améliorées. Vous pouvez commencer dès aujourd'hui avec un essai gratuit de 30 jours .
« Cet article de blog peut faire référence à des produits qui ne sont plus disponibles et/ou qui ne sont plus pris en charge. Pour obtenir les informations les plus récentes sur les produits et solutions F5 NGINX disponibles, explorez notre famille de produits NGINX . NGINX fait désormais partie de F5. Tous les liens NGINX.com précédents redirigeront vers un contenu NGINX similaire sur F5.com."