Anunciamos NGINX Plus R28

Nos complace anunciar la disponibilidad de NGINX Plus Release 28 (R28) . Basado en NGINX de código abierto, NGINX Plus es el único servidor web de software todo en uno , balanceador de carga, proxy inverso, caché de contenido y puerta de enlace API.

Las características nuevas y mejoradas de NGINX Plus R28 incluyen:

• Métricas TLS adicionales : NGINX Plus R28 recopila estadísticas TLS adicionales a nivel de todo el sistema, del lado del cliente y del servidor, lo que proporciona información fundamental para solucionar errores relacionados con SSL/TLS en la configuración del proxy y para las conexiones a clientes y servidores ascendentes.

  El panel de monitoreo de actividad en vivo de NGINX Plus se actualiza para mostrar los nuevos datos de la sesión SSL.

• Compatibilidad con TLV del protocolo PROXY v2 en servicios privados en la nube : cuando pone recursos a disposición de clientes externos a través de un “servicio privado” en AWS, Google Cloud Platform y Microsoft Azure, de manera predeterminada, el identificador de cliente específico del servicio representado en un vector de tipo-longitud-valor (TLV) en el encabezado del protocolo PROXY v2 no se pasa a los servicios de backend. NGINX Plus R28 presenta módulos para los contextos http y de flujo que decodifican el TLV y definen una variable para reenviar el identificador del cliente a los servicios backend.
• Soporte de variables para el parámetro samesite de cookies adhesivas : en NGINX Plus R28 , el valor del parámetro samesite de la directiva de cookies adhesivas puede ser una variable. Esta mejora permite una gestión más sencilla del tráfico y una mayor seguridad.

Para completar el lanzamiento se incluyen nuevas características y correcciones de errores heredadas de NGINX Open Source y actualizaciones del módulo JavaScript de NGINX.

Cambios importantes en el comportamiento

Nota:  Si está actualizando desde una versión distinta a NGINX Plus R27 , asegúrese de consultar la sección Cambios importantes en el comportamiento en los blogs de anuncios de todas las versiones entre su versión actual y esta.

Cambios en el soporte de la plataforma

Nuevos sistemas operativos y arquitecturas compatibles:

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

Sistemas operativos más antiguos eliminados:

• Debian 10, que llegó al final de su vida útil (EOL) en agosto de 2022

Sistemas operativos y arquitecturas más antiguos obsoletos y programados para su eliminación en NGINX Plus R29 :

• Alpine 3.13, que alcanzó el fin de su vida útil el 1 de noviembre de 2022

Cambio en el manejo de múltiples encabezados con nombres idénticos

• La mayoría de los encabezados de respuesta ascendentes duplicados conocidos ahora se ignoran con una advertencia
• Ahora se rechazan los encabezados Content-Length y Transfer-Encoding duplicados, así como las respuestas con encabezados Content-Length o Transfer-Encoding no válidos, o si tanto Content-Length como Transfer-Encoding están presentes en la respuesta.

Nuevas funciones en detalle

Métricas TLS adicionales

La observabilidad de eventos y errores de SSL/TLS es importante a la hora de solucionar problemas relacionados con TLS con la configuración del proxy, servidores ascendentes y clientes. Desde la introducción de la API NGINX Plus en NGINX Plus R13 , NGINX Plus ha recopilado tres métricas TLS a nivel de todo el sistema:

• protocolos de enlace : número de protocolos de enlace SSL exitosos
• handshakes_failed : número de fallas de protocolo de enlace SSL (que no incluyen fallas de verificación de certificado que ocurren después del protocolo de enlace SSL)
• session_reuses – Número de reutilizaciones de sesiones SSL

En NGINX Plus R27<.htmla> y versiones posteriores, puede configurar la recopilación de las tres métricas para servidores ascendentes individuales y servidores virtuales.

NGINX Plus R28 amplía el conjunto de métricas TLS con nuevos contadores para errores de protocolo de enlace y fallas de validación de certificados en los módulos HTTP y Stream (aquí proporcionamos ejemplos solo para módulos HTTP, pero las métricas Stream disponibles son similares). Para obtener detalles sobre cómo configurar la recopilación de métricas para servidores ascendentes individuales y servidores virtuales, consulte el blog de anuncio de NGINX Plus R27<.htmlspan> .

Errores de protocolo de enlace

Los contadores para los siguientes errores de protocolo de enlace son nuevos en NGINX Plus R28 :

• handshake_timeout : Número de fallos de protocolo de enlace debido al tiempo de espera del protocolo de enlace
• no_common_cipher : número de fallas en el protocolo de enlace debido a la falta de un cifrado común entre las partes (no se recopila para conexiones a servidores ascendentes porque no corresponde)
• no_common_protocol – Número de fallos de protocolo de enlace debido a la falta de un protocolo común entre las partes
• peer_rejected_cert : Número de fallos de protocolo de enlace debido a que la otra parte rechazó el certificado presentado por NGINX Plus y proporcionó el mensaje de alerta adecuado

Fallos de verificación de certificados

Las fallas de verificación de certificado ahora se informan en la nueva sección verify_failures de la salida de la API cuando configura la verificación de certificado:

• Para conexiones a clientes con la directiva ssl_verify_client [ HTTP ][ Stream ]

• Para conexiones a servidores con estas directivas específicas del protocolo:

  • grpc_ssl_verify
  • proxy_ssl_verify [ HTTP ][ Transmisión ]
  • verificación SSL de uwsgi

Cuando ocurre una falla en la verificación del certificado, se incrementa la métrica de la causa correspondiente y se interrumpe la conexión. Tenga en cuenta, sin embargo, que el contador de apretones de manos básicos aún se incrementa porque estas fallas ocurren después de que el apretón de manos tiene éxito.

Las métricas para la validación de certificado fallida son:

• expired_cert – El par presentó un certificado vencido
• hostname_mismatch : el certificado del servidor no coincide con el nombre de host (no se recopila para las conexiones a los clientes)
• no_cert – El cliente no proporcionó un certificado como se requiere (no se recopila para las conexiones a servidores ascendentes)
• revoked_cert – El par presentó un certificado revocado
• otro – Contador explícito para otros fallos de verificación de certificados

Salida de métricas de muestra

A continuación se muestra un conjunto de métricas TLS de muestra para conexiones HTTP a nivel de todo el sistema:

$ curl 127.0.0.1:8080/api/8/ssl { "apretones de manos": 32, "reutilizaciones de sesión": 0, "el protocolo de enlace falló": 8, "sin_protocolo_común": 4, "sin_cifrado_común": 2, "tiempo de espera del protocolo de enlace": 0, "certificado rechazado por pares": 0, "verificar_fallos": { "sin_certificado": 0, "certificado_caducado": 2, "certificado revocado": 1, "nombre_de_host_discordancia": 2, "otro": 1 } }

A continuación se muestra un conjunto de métricas de muestra para las conexiones entre los clientes y el servidor virtual HTTP s9 (como se señaló anteriormente, el contador hostname_mismatch no se recopila para dichas conexiones):

$ curl 127.0.0.1:8080/api/8/http/server_zones/s9 { ... "ssl": { "apretones de manos": 0, "reutilizaciones de sesión": 0, "el protocolo de enlace falló": 1, "sin_protocolo_común": 0, "sin_cifrado_común": 1, "tiempo de espera del protocolo de enlace": 0, "certificado rechazado por pares": 0, "verificar_fallos": { "sin_certificado": 0, "certificado_caducado": 0, "certificado revocado": 0, "otro": 0 } } ... }

A continuación se muestra un conjunto de métricas de muestra para conexiones HTTP a servidores en el grupo ascendente u2 (como se señaló anteriormente, los contadores no_cert y no_common_cipher no se recopilan para dichas conexiones):

$ curl 127.0.0.1:8080/api/8/http/upstreams/u2 { "pares": [ { "id": 0, "servidor": "127.0.0.1:8082", "nombre": "127.0.0.1:8082", ... "ssl": { "apretones de manos": 1, "reutilizaciones de sesión": 0, "el protocolo de enlace falló": 0, "sin_protocolo_común": 0, "tiempo de espera del protocolo de enlace": 0, "certificado rechazado por pares": 0, "verificar_fallos": { "certificado_expirado": 1, "certificado revocado": 0, "nombre de host no coincidente": 0, "otro": 0 } }, ... } ], }

El panel de NGINX Plus muestra las métricas TLS extendidas

Para NGINX Plus R28 y versiones posteriores, el panel de monitoreo de actividad en vivo muestra las nuevas métricas TLS descritas anteriormente. Esta captura de pantalla muestra métricas de las conexiones a los clientes. Para ver las nuevas métricas, pase el cursor sobre el valor en la columna SSL > Errores de protocolo de enlace como se muestra.

Compatibilidad con TLV del protocolo PROXY v2 en servicios privados en la nube

Los tres principales proveedores de nube (Amazon Web Services (AWS), Google Cloud Platform (GCP) y Microsoft Azure) ofrecen cada uno un “servicio privado” que permite que clientes externos accedan a sus servicios sin exponerlos en Internet público. Cada servicio utiliza un identificador de cliente que se representa en un vector de tipo-longitud-valor (TLV) en un encabezado del protocolo PROXY v2. Los identificadores específicos del servicio son:

• AWS PrivateLink – PP2_SUBTYPE_AWS_VPCE_ID
• Conexión de servicio privado de GCP – pscConnectionId
• Enlace privado de Microsoft Azure : PP2_SUBTYPE_AZURE_PRIVATEENDPOINT_LINKID

De forma predeterminada, estos identificadores de cliente no se pasan a los servicios backend. NGINX Plus R28 presenta módulos para los contextos http y de flujo : ngx_http_proxy_protocol_vendor_module y ngx_stream_proxy_protocol_vendor_module , que decodifican el TLV y definen una variable para reenviar el identificador a los servicios backend.

Para obtener información general sobre cómo NGINX Plus utiliza el protocolo PROXY para obtener direcciones IP y otra información sobre los clientes, consulte Aceptación del protocolo PROXY en la Guía de administración de NGINX Plus.

Compatibilidad del protocolo PROXY v2 con AWS

En AWS, la dirección IP de origen del tráfico que proviene de los clientes a través de un servicio de punto final de nube privada virtual (VPC) es la dirección IP privada del nodo Network Load Balancer. Si la aplicação backend requiere las direcciones IP reales y otros identificadores para los clientes, se pueden obtener de los encabezados del protocolo PROXY v2.

En AWS, un vector TLV personalizado codifica el ID de VPC del punto final en el encabezado del protocolo PROXY v2 PP2_SUBTYPE_AWS_VPCE_ID . (Para obtener más información, consulte la documentación de AWS ).

NGINX Plus R28 decodifica el TLV y pasa el ID del punto final a las aplicações backend en la variable $proxy_protocol_tlv_aws_vpce_id .

Nota:  En el bloque del servidor donde hace referencia a la variable $proxy_protocol_tlv_aws_vpce_id , también debe incluir el parámetro proxy_protocol en la directiva listen [ HTTP ][ Stream ]. Para ver un ejemplo, consulte la línea 8 de proxy_protocol_v2.conf justo debajo.

Esta configuración de muestra para AWS verifica que el ID de VPC sea aceptable y, de ser así, lo pasa a la aplicação backend como segundo parámetro de la directiva add_header :

Compatibilidad del protocolo PROXY v2 con GCP

En GCP Private Service Connect, la dirección IP de origen del tráfico proveniente de los clientes es una “dirección en una de las subredes de Private Service Connect en la red VPC del productor de servicios”. Si la aplicação backend requiere las direcciones IP reales y otros identificadores para los clientes, se pueden obtener de los encabezados del protocolo PROXY v2.

En GCP, un vector TLV personalizado codifica la ID de conexión única (en ese momento) en el encabezado del protocolo PROXY v2 pscConnectionId . (Para obtener más información, consulte la documentación de GCP ).

NGINX Plus R28 decodifica el TLV y pasa el valor de pscConnectionId a las aplicações backend en la variable $proxy_protocol_tlv_gcp_conn_id .

Nota:  En el bloque del servidor donde hace referencia a la variable $proxy_protocol_tlv_gcp_conn_id , también debe incluir el parámetro proxy_protocol en la directiva listen [ HTTP ][ Stream ]. Para ver un ejemplo, consulte la línea 8 de proxy_protocol_v2.conf más arriba.

Compatibilidad del protocolo PROXY v2 con Microsoft Azure

En Microsoft Azure Private Link, la dirección IP de origen para el tráfico proveniente de los clientes es la “dirección de red traducida (NAT) del lado del proveedor de servicios que utiliza la dirección IP NAT asignada desde la red virtual del proveedor”. Si la aplicação backend requiere las direcciones IP reales y otros identificadores para los clientes, se pueden obtener de los encabezados del protocolo PROXY v2.

En Azure, un vector TLV personalizado codifica el LinkID del cliente en el encabezado del protocolo PROXY v2 PP2_SUBTYPE_AZURE_PRIVATEENDPOINT_LINKID . (Para obtener más información, consulte la documentación de Azure ).

NGINX Plus R28 decodifica el TLV y pasa el LinkID a las aplicações backend en la variable $proxy_protocol_tlv_azure_pel_id .

Nota:  En el bloque del servidor donde hace referencia a la variable $proxy_protocol_tlv_azure_pel_id , también debe incluir el parámetro proxy_protocol en la directiva listen [ HTTP ][ Stream ]. Para ver un ejemplo, consulte la línea 8 de proxy_protocol_v2.conf más arriba.

Soporte de variables para el parámetro Sticky Cookie samesite

En versiones anteriores de NGINX Plus, se aceptaban tres valores estáticos ( strict , lax y none ) para el parámetro samesite de la directiva de cookies adhesivas . En NGINX Plus R28 , el valor también puede ser una variable.

De forma predeterminada (no hay ningún parámetro SameSite ), NGINX no inyecta el atributo SameSite en la cookie. Cuando el parámetro samesite es una variable, el resultado depende de cómo se resuelve la variable en tiempo de ejecución:

• A uno de los valores estándar ( estricto , laxo y ninguno ), NGINX inyecta el atributo SameSite establecido en ese valor.
• A un valor vacío ( "" ) – NGINX no inyecta el atributo SameSite
• Para cualquier otro valor que indique una configuración incorrecta, NGINX inyecta el atributo SameSite establecido en Estricto (la configuración más segura).

Esta configuración de muestra establece el atributo SameSite en función del valor del encabezado User-Agent HTTP (esto es útil para clientes heredados que no admiten el atributo SameSite ):

Otras mejoras en NGINX Plus R28

Cambios heredados de NGINX de código abierto

NGINX Plus R28 se basa en NGINX Open Source 1.23.2 y hereda los cambios funcionales y las correcciones de errores realizados desde que se lanzó NGINX Plus R27 (en NGINX 1.23.0 a 1.23.2). Los cambios y correcciones de errores incluyen:

• El nuevo parámetro ipv4=off de la directiva de resolución HTTP deshabilita la búsqueda de direcciones IPv4.
• Cuando habilita un caché compartido para la información de la sesión HTTP con el parámetro shared en la directiva ssl_session_cache , las claves de ticket de sesión TLS ahora se rotan automáticamente.
• El nivel de gravedad con el que se registran varios tipos de errores TLS/SSL se reduce de crítico a informativo .

Para obtener la lista completa de nuevas características, cambios y correcciones de errores heredados de estas versiones, consulte el archivo CAMBIOS .

Cambios en el módulo JavaScript de NGINX

NGINX Plus R28 incorpora cambios y correcciones realizados en las versiones 0.7.5 a 0.7.8 del módulo JavaScript de NGINX (njs). Hemos destacado algunos de los más importantes en Haga que su configuración NGINX sea aún más modular y reutilizable con njs 0.7.7 en nuestro blog. Para obtener una lista completa, consulte el archivo Cambios .

Actualice o pruebe NGINX Plus

Si está utilizando NGINX Plus, le recomendamos encarecidamente que actualice a NGINX Plus R28 lo antes posible. También recibirás varias correcciones y mejoras adicionales, y ayudará a NGINX a ayudarte cuando necesites generar un ticket de soporte.

Si aún no ha probado NGINX Plus, le recomendamos que lo haga por cuestiones de seguridad, equilibrio de carga y puerta de enlace de API, o como servidor web totalmente compatible con API de administración y monitoreo mejoradas. Puede comenzar hoy con una prueba gratuita de 30 días .