Presentamos NGINX Plus R28

Robert HaynesResponsable de marketing técnico

Nos complace anunciar la disponibilidad de NGINX Plus Release 28 (R28). Basado en NGINX Open Source, NGINX Plus es el único software todo en uno que integra servidor web, equilibrador de carga, proxy inverso, caché de contenido y puerta de enlace de API.

Entre las funciones nuevas y mejoradas de NGINX Plus R28 se incluyen:

• Métricas de TLS adicionales – NGINX Plus R28 recopila estadísticas de TLS adicionales a nivel de todo el sistema, del lado del cliente y del lado del servidor, lo que proporciona información esencial para solucionar errores relacionados con SSL/TLS en la configuración del proxy y en las conexiones con clientes y servidores ascendentes. El panel de supervisión de la actividad en tiempo real de NGINX Plus se ha actualizado para mostrar los nuevos datos de las sesiones SSL.
• Compatibilidad con los TLV del protocolo PROXY v2 en servicios privados en la nube – Cuando se ponen recursos a disposición de clientes externos mediante un «servicio privado» en AWS, Google Cloud Platform y Microsoft Azure, de forma predeterminada no se transmite a los servicios de backend el identificador de cliente específico del servicio, representado en un vector de tipo-longitud-valor (TLV) en la cabecera del protocolo PROXY v2. NGINX Plus R28 incorpora módulos para los contextos http y stream que descodifican el TLV y definen una variable para reenviar el identificador de cliente a los servicios de backend.
• Compatibilidad con variables para el parámetro samesite de la cookie persistente – En NGINX Plus R28, el valor del parámetro samesite de la directiva sticky cookie puede ser una variable. Esta mejora facilita la gestión del tráfico y aumenta la seguridad.

Para completar esta versión se incluyen nuevas funcionalidades y correcciones de errores heredadas de NGINX Open Source, así como actualizaciones del módulo JavaScript de NGINX.

Cambios importantes en el comportamiento

Nota: Si va a actualizar desde una versión distinta de NGINX Plus R27, asegúrese de consultar la sección Cambios importantes de comportamiento de los blogs de anuncios de todas las versiones comprendidas entre la que utiliza actualmente y esta.

Cambios en la compatibilidad con plataformas

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 antiguos eliminados:

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

Sistemas operativos y arquitecturas antiguos obsoletos y cuya eliminación está prevista en NGINX Plus R29:

• Alpine 3.13, que llegó al final de su vida útil el 1 de noviembre de 2022

Cambio en la gestión de varias cabeceras con nombres idénticos

• La mayoría de las cabeceras de respuesta duplicadas conocidas del servidor de origen ahora se ignoran y se muestra una advertencia
• Los encabezados Content-Length y Transfer-Encoding duplicados ahora se rechazan, al igual que 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 de TLS adicionales

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

• handshakes – Número de protocolos de enlace SSL realizados correctamente
• handshakes_failed – Número de fallos en el protocolo de enlace SSL (sin incluir los fallos de verificación del certificado que se producen 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 y servidores virtuales individuales.

NGINX Plus R28 amplía el conjunto de métricas de TLS con nuevos contadores de errores de negociación y fallos de validación de certificados tanto en los módulos HTTP como Stream (aquí solo ofrecemos ejemplos para los módulos HTTP, pero las métricas disponibles para Stream son similares). Para obtener más información sobre cómo configurar la recopilación de métricas para servidores upstream y servidores virtuales individuales, consulte el blog del anuncio de NGINX Plus R27<.htmlspan>.

Errores de negociación

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

• handshake_timeout – Número de fallos de protocolo de enlace debidos al tiempo de espera agotado del protocolo de enlace
• no_common_cipher – Número de fallos de negociación debidos a la falta de un cifrado común entre las partes de la negociación (no se recopila para las conexiones con servidores ascendentes porque no es aplicable)
• no_common_protocol – Número de fallos de negociación debidos a la falta de un protocolo común entre las partes
• peer_rejected_cert – Número de fallos de negociación debidos a que la otra parte ha rechazado el certificado presentado por NGINX Plus y ha proporcionado el mensaje de alerta correspondiente

Errores de verificación de certificados

Los fallos de verificación de certificados ahora se notifican en la nueva sección verify_failures de la salida de la API al configurar la verificación de certificados:

• Para las conexiones con clientes mediante la directiva «ssl_verify_client» de [HTTP][Stream]
• Para conexiones con servidores mediante estas directivas específicas del protocolo:
  • grpc_ssl_verify
  • proxy_ssl_verify[HTTP][Flujo]
  • uwsgi_ssl_verify

Cuando se produce un error de verificación del certificado, se incrementa la métrica correspondiente a la causa y se cierra la conexión. Sin embargo, tenga en cuenta que el contador básico de handshakes también se incrementa porque estos errores se producen después de que el protocolo de enlace se complete correctamente.

Las métricas de los errores de validación de certificados son:

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

Ejemplo de salida de métricas

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

$ 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    }}

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

$ 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        }    }    ...}

A continuación se muestra un conjunto de métricas de ejemplo para las conexiones HTTP a los servidores del grupo de servidores upstream u2 (como se ha indicado anteriormente, los contadores no_cert y no_common_cipher no se recopilan para este tipo de conexiones):

$ 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                }            },            ...        }    ],}

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

En NGINX Plus R28 y versiones posteriores, el panel de supervisión de la actividad en tiempo real muestra las nuevas métricas de TLS descritas anteriormente. Esta captura de pantalla muestra las métricas de las conexiones con los clientes. Para ver las nuevas métricas, sitúe el cursor sobre el valor de la columna SSL > Enlaces fallidos tal como se muestra.

Compatibilidad con los TLV de PROXY Protocol v2 en Cloud Private Services

Los tres principales proveedores de servicios en la nube —Amazon Web Services (AWS), Google Cloud Platform (GCP) y Microsoft Azure— ofrecen un «servicio privado» que permite a los clientes externos acceder a sus servicios sin exponerlos en la Internet pública. Cada servicio utiliza un identificador de cliente representado en un vector de tipo-longitud-valor (TLV) dentro de una cabecera del protocolo PROXY v2. Los identificadores específicos de cada servicio son:

• AWS PrivateLink – PP2_SUBTYPE_AWS_VPCE_ID
• GCP Private Service Connect – pscConnectionId
• Microsoft Azure Private Link – PP2_SUBTYPE_AZURE_PRIVATEENDPOINT_LINKID

De forma predeterminada, estos identificadores de cliente no se transmiten a los servicios de backend. NGINX Plus R28 incorpora módulos para los contextos http y stream —ngx_http_proxy_protocol_vendor_module y ngx_stream_proxy_protocol_vendor_module— que descodifican el TLV y definen una variable para reenviar el identificador a los servicios de 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 con el protocolo PROXY v2 para AWS

En AWS, la dirección IP de origen del tráfico procedente de clientes a través de un servicio de punto de conexión de nube privada virtual (VPC) es la dirección IP privada del nodo del equilibrador de carga de red. Si la aplicación de backend necesita las direcciones IP reales y otros identificadores de los clientes, puede obtenerlos de las cabeceras del protocolo PROXY v2.

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

NGINX Plus R28 descodifica el TLV y pasa el ID del punto de conexión a las aplicaciones de backend en la variable $proxy_protocol_tlv_aws_vpce_id.

Nota: En el bloque server en el que se 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 a continuación.

Esta configuración de ejemplo para AWS comprueba que el ID de la VPC sea válido y, de ser así, lo pasa a la aplicación de backend como segundo parámetro de la directiva add_header:

Cargando ejemplo de código…

Compatibilidad con el protocolo PROXY v2 para GCP

En Private Service Connect de GCP, la dirección IP de origen del tráfico procedente de los clientes es una «dirección de una de las subredes de Private Service Connect de la red VPC del productor del servicio». Si la aplicación de backend necesita las direcciones IP reales y otros identificadores de los clientes, puede obtenerlos de las cabeceras del protocolo PROXY v2.

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

NGINX Plus R28 descodifica el TLV y pasa el valor de pscConnectionId a las aplicaciones de backend en la variable $proxy_protocol_tlv_gcp_conn_id.

Nota: En el bloque server en el que se 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 con el protocolo PROXY v2 para Microsoft Azure

En Microsoft Azure Private Link, la dirección IP de origen del tráfico procedente de los clientes es la «dirección de red traducida (NAT) en el lado del proveedor de servicios mediante la dirección IP de NAT asignada desde la red virtual del proveedor». Si la aplicación de backend necesita las direcciones IP reales y otros identificadores de los clientes, puede obtenerlos de las cabeceras del protocolo PROXY v2.

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

NGINX Plus R28 descodifica el TLV y pasa el LinkID a las aplicaciones de backend en la variable $proxy_protocol_tlv_azure_pel_id.

Nota: En el bloque server en el que se 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.

Compatibilidad con variables para el parámetro samesite de la cookie persistente

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

De forma predeterminada (si no se especifica el parámetro samesite), NGINX no añade el atributo SameSite a la cookie. Cuando el parámetro samesite es una variable, el resultado depende del valor que adopte la variable en tiempo de ejecución:

• A uno de los valores estándar (strict, lax o none): NGINX inserta el atributo SameSite establecido en ese valor
• A un valor vacío ("") – NGINX no inserta el atributo SameSite attribute
• A cualquier otro valor, lo que indica una configuración incorrecta – NGINX inserta el atributo SameSite establecido en Strict (la configuración más segura)

Esta configuración de ejemplo establece el atributo samesite en función del valor de la cabecera HTTP User-Agent (lo cual resulta útil para clientes antiguos que no admiten el atributo SameSite):

Cargando ejemplo de código…

Otras mejoras de NGINX Plus R28

Cambios heredados de NGINX Open Source

NGINX Plus R28 se basa en NGINX Open Source 1.23.2 y hereda los cambios funcionales y las correcciones de errores realizados desde el lanzamiento de NGINX Plus R27 (desde NGINX 1.23.0 hasta 1.23.2). Entre los cambios y las correcciones de errores se incluyen:

• El nuevo parámetro «ipv4=off» de la directiva «resolver» de HTTP deshabilita la búsqueda de direcciones IPv4.
• Cuando se habilita una caché compartida para la información de las sesiones HTTP mediante el parámetro shared de la directiva ssl_session_cache, las claves de los tickets de sesión TLS ahora se rotan automáticamente.
• El nivel de gravedad con el que se registran varios tipos de errores de TLS/SSL se reduce de «crit» a «info».

Para consultar la lista completa de nuevas funciones, cambios y correcciones de errores heredados de estas versiones, consulte el archivo CHANGES.

Cambios en el módulo JavaScript de NGINX

NGINX Plus R28 incorpora los cambios y las 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 de NGINX sea aún más modular y reutilizable con njs 0.7.7 en nuestro blog. Para consultar la lista completa, consulte el archivo de cambios.

Actualice o pruebe NGINX Plus

Si utiliza NGINX Plus, le recomendamos encarecidamente que actualice a NGINX Plus R28 lo antes posible. También obtendrá varias correcciones y mejoras adicionales, y esto facilitará que NGINX pueda ayudarle cuando necesite abrir una incidencia de soporte.

Si aún no ha probado NGINX Plus, le animamos a hacerlo, ya sea para la seguridad, el balanceo de carga y la puerta de enlace de API, o como servidor web con soporte completo y API mejoradas de supervisión y gestión. Puede empezar hoy mismo con una prueba gratuita de 30 días.

Sobre el autor

Robert HaynesResponsable de marketing técnico

Más artículos de Robert Haynes