Anunciamos NGINX Plus R31

Nos complace anunciar la disponibilidad de NGINX Plus Release 31 (R31). 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 R31 incluyen:

• Informes de uso nativos de NGINX : NGINX Plus ahora cuenta con soporte nativo para generar informes sobre implementaciones de NGINX en toda su organización, lo que permite una vista consolidada de su infraestructura NGINX en NGINX Instance Manager. Esta característica permite una mejor gobernanza de las instancias NGINX para fines de cumplimiento.
• Mejoras en la configuración de SNI : anteriormente, el nombre del servidor que pasaba por la Identificación de nombre de servidor (SNI) utilizaba la directiva proxy_ssl_name y era utilizado por todos los servidores en el grupo ascendente. NGINX Plus R31 permite configurar este SNI en un servidor ascendente seleccionado.
• Ejecución periódica de tareas con NGINX JavaScript : NGINX JavaScript introduce la directiva js_periodic para permitir la ejecución de contenido a intervalos periódicos. Esta mejora elimina la necesidad de configurar un trabajo cron y puede configurarse para ejecutarse en todos los procesos de trabajo o en procesos específicos para un rendimiento óptimo.
• Una mejor experiencia de inicio de NGINX : NGINX Plus R31 aporta mejoras en la experiencia general de inicio de NGINX en los casos en los que hay una gran cantidad de “ubicaciones” en la configuración.
• Optimizaciones y mejoras de QUIC+HTTP/3 : NGINX Plus R31 agrega muchas mejoras y optimizaciones de rendimiento a la implementación de QUIC, incluido soporte para el descubrimiento de la unidad de transmisión máxima (MTU) de ruta, mejoras en el control de congestión y la capacidad de reutilizar el contexto criptográfico en toda la sesión QUIC.

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 R30, asegúrese de consultar la sección Cambios importantes en el comportamiento en los blogs de anuncios anteriores para todas las versiones entre su versión actual y esta.

Desuso del módulo OpenTracing

El módulo OpenTracing que se introdujo en NGINX Plus R18 ahora está obsoleto. Está marcado para eliminarse a partir de la futura versión de NGINX Plus R34. El paquete estará disponible con todas las versiones de NGINX Plus hasta entonces. Se recomienda encarecidamente utilizar el módulo OpenTelemetry que se introdujo en NGINX Plus R29.

Mensaje de advertencia por no informar el uso de NGINX

Los usuarios de NGINX Plus deben informar su uso de NGINX a F5 para fines de cumplimiento. Con el lanzamiento de NGINX Plus R31, la capacidad de informar su uso de NGINX a NGINX Instance Manager está presente de forma nativa y está habilitada de forma predeterminada. Se registra un mensaje de advertencia si la instancia NGINX no puede proporcionar su información de uso al Administrador de instancias NGINX por algún motivo.

Consulte la sección Informes de uso nativo de NGINX para obtener detalles sobre cómo configurar esta función en su entorno.

Cambios en el soporte de la plataforma

Nuevos sistemas operativos compatibles:

• FreeBSD 14
• Alpino 3.19

Sistemas operativos más antiguos eliminados:

• Alpine 3.15, que llegó al final de su vida útil (EOL) el 1 de noviembre de 2023

Sistemas operativos antiguos obsoletos y programados para su eliminación en NGINX Plus R32:

• FreeBSD 12, que alcanzará el fin de su vida útil el 31 de diciembre de 2023

Nuevas funciones en detalle

Informes de uso nativo de NGINX

NGINX Plus R31 presenta comunicación nativa con NGINX Instance Manager en su red para automatizar el cumplimiento de las licencias. Si participa en el Programa de Consumo Flexible de F5 , ya no necesitará realizar un seguimiento manual de sus instancias NGINX Plus.

De forma predeterminada, NGINX Plus intentará descubrir NGINX Instance Manager al iniciarse a través de una búsqueda DNS del nombre de host nginx-mgmt.local . Si bien el nombre de host es configurable, sugerimos (para simplificar) agregar un registro A a su DNS local, asociando el nombre de host predeterminado con la dirección IP del sistema que ejecuta NGINX Instance Manager. Luego, NGINX Plus establecerá una conexión TLS con NGINX Instance Manager e informará su número de versión, nombre de host e identificador único cada treinta minutos.

Para una capa adicional de seguridad, también sugerimos aprovisionar esta conexión con mTLS mediante el uso del bloque de configuración mgmt opcional. Luego, a una cadencia regular, NGINX Instance Manager informará el uso total de instancias NGINX Plus a un servicio F5.

Verá un mensaje de advertencia en su registro de errores si NGINX Plus experimenta algún problema al resolver el nombre de host nginx-mgmt.local o al comunicarse con el Administrador de instancias de NGINX.

Este es un ejemplo de un mensaje de error que indica que la instancia de NGINX Plus no puede resolver nginx-mgmt.local :

2023/12/21 21:02:01 [warn] 3050#3050: Informe de uso: No se encontró el host que resuelve el punto final "nginx-mgmt.local”

A continuación se muestra un ejemplo de un mensaje de error que indica que la instancia NGINX Plus está experimentando dificultades para comunicarse con el Administrador de instancias NGINX:

2023/12/21 21:02:01 [warn] 3184#3184: informe de uso: se agotó el tiempo de conexión

Personalización de la configuración del bloque de administración

Si prefiere ajustar la forma en que su instancia NGINX Plus se comunica con NGINX Instance Manager, puede optar por utilizar el nuevo bloque de configuración mgmt y las directivas asociadas. Al hacerlo, podrá definir un solucionador personalizado, usar una dirección IP o un nombre de host alternativo para identificar su sistema NGINX Instance Manager, especificar opciones de TLS, usar mTLS para mayor seguridad y especificar otros parámetros personalizados.

La siguiente es una configuración personalizada de ejemplo:

mgmt {
use_report endpoint=instance-manager.local interval=30m;
resolver 192.168.0.2; # Ejemplo de IP DNS interna

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 trusted_ca_cert.crt;
ssl_verify on;
ssl_verify_depth 2;
}

Para obtener detalles adicionales sobre estas directivas, consulte la documentación del producto .

Para obtener más información sobre cómo descargar e instalar NGINX Instance Manager, consulte la guía de instalación .

Nota:  Si está utilizando una versión anterior de NGINX Plus, aún puede informar sus instancias siguiendo estas instrucciones .

Mejoras en la configuración de SNI

Antes de este lanzamiento, NGINX Plus asumía que todos los servidores de un grupo ascendente eran idénticos. Esto significa que necesitaban poder responder las mismas solicitudes, responder al mismo nombre SNI (cuando se usa proxy_ssl_server_name ) y devolver certificados SSL que coincidieran con el mismo nombre.

Sin embargo, existen escenarios en los que este comportamiento no es suficiente. Por ejemplo, si se comparten varios servidores virtuales detrás de un servidor ascendente y es necesario distinguirlos mediante un SNI y/o encabezado de host diferente para enrutar solicitudes a recursos específicos. También es posible que no se pueda usar el mismo certificado en todos los servidores del grupo ascendente o que existan limitaciones para colocar los servidores ascendentes en grupos ascendentes separados.

NGINX Plus R31 introduce soporte para que SNI se configure por servidor ascendente. La variable $upstream_last_server_name hace referencia al nombre del servidor ascendente seleccionado, que luego puede pasarse al servidor proxy mediante las directivas proxy_ssl_server_name y proxy_ssl_name .

Aquí se explica cómo configurar proxy_ssl_server_name en activado , lo que permite que un nombre de servidor pase a través de SNI:
nombre_del_servidor_ssl_proxy activado;

Y así es como se pasa el nombre del servidor ascendente seleccionado usando proxy_ssl_name :
proxy_ssl_name $nombre_del_último_servidor_upstream;

Ejecución periódica de tareas con NGINX JavaScript

NGINX JavaScript v0.8.1 introdujo una nueva directiva js_periodic que está disponible tanto en el contexto http como en el de streaming . Esta directiva permite especificar un controlador de contenido JavaScript para que se ejecute a intervalos regulares. Esto es útil en casos donde el código personalizado necesita ejecutarse a intervalos periódicos y podría requerir acceso a variables NGINX. El controlador de contenido recibe un objeto de sesión como argumento y también tiene acceso a objetos globales.

De forma predeterminada, el controlador de contenido se ejecuta en el proceso de trabajo 0, pero se puede configurar para que se ejecute en procesos de trabajo específicos o en todos ellos.

Esta directiva está disponible en el contexto de ubicación :

ejemplo.conf:

ubicación @periodics {

# Se ejecutará a intervalos de 15 minutos en los procesos de trabajo 1 y 3

js_periodic main.handler interval=900sworker_affinity=0101;

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

ejemplo.js:

función asíncrona handler(s) {

let reply = await ngx.fetch('https://nginx.org/en/docs/njs/');

let body = await reply.text();

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

Para conocer los detalles de sintaxis y configuración, consulte la documentación de JavaScript de NGINX .

Una mejor experiencia de startup con NGINX

En escenarios donde una configuración de NGINX contiene una gran cantidad de “ubicaciones”, el tiempo de inicio de NGINX puede demorar una cantidad de tiempo considerable. En muchos casos, esto podría no ser aceptable. El problema de raíz existe en el algoritmo de clasificación que se utiliza para ordenar la lista de ubicaciones.

NGINX R31 presenta una mejora que reemplaza el algoritmo de ordenamiento existente, el de ordenamiento por inserción , que tiene una complejidad temporal de O(n2) , con el de ordenamiento por fusión, que tiene una complejidad temporal de O(n*log n) .

En una configuración de prueba con 20.000 ubicaciones, se observó que el tiempo total de inicio se redujo de 8 segundos a 0,9 segundos después de esta actualización.

Optimizaciones y mejoras de QUIC+HTTP/3

NGINX Plus R31 introduce varias mejoras y optimizaciones de rendimiento para la implementación de QUIC+HTTP/3, como:

• Descubrimiento de la unidad de transmisión máxima (MTU) de ruta cuando se utiliza QUIC+HTTP/3 : la MTU de ruta es una medida en bytes del tamaño más grande de la trama o paquete de datos que se puede transmitir a través de una red. Antes de este cambio, la implementación de QUIC utilizaba una MTU de ruta de 1200 bytes para todos los datagramas. NGINX Plus ahora tiene soporte para descubrir el tamaño de MTU de la ruta, que luego se utiliza para todos los datagramas salientes.
• Reutilizar el contexto criptográfico en toda la sesión QUIC : esta optimización se relaciona con el comportamiento de cifrado y descifrado de los paquetes QUIC. Anteriormente, se creaba un contexto criptográfico separado para cada operación de cifrado o descifrado. Ahora, el mismo contexto se utiliza en toda la sesión QUIC, lo que genera un mejor rendimiento.

Las optimizaciones de rendimiento adicionales incluyen la reducción de posibles demoras al enviar paquetes de reconocimiento, colocar los marcos de reconocimiento (ACK) al frente de la cola para reducir las retransmisiones de marcos y las demoras en la entrega de marcos ACK, y mejoras en el comportamiento de control de congestión en el modo de descarga de segmentación genérica (GSO).

Otras mejoras y correcciones de errores en NGINX Plus R31

Módulo de gestión adicional

En NGINX Plus R31, ngx_mgmt_module le permite informar información de uso de NGINX al Administrador de instancias de NGINX. Esta información incluye el nombre de host NGINX, la versión de NGINX y un identificador de instancia único.

El módulo proporciona varias directivas para ajustar la forma en que su instancia NGINX se comunica con el Administrador de instancias NGINX. Para obtener una lista completa de las directivas y opciones de configuración disponibles, consulte la documentación de NGINX .

Corrección de errores en el módulo MQTT

La compatibilidad con Message Queueing Telemetry Transport (MQTT) se introdujo en NGINX Plus R29 y esta versión contiene algunas correcciones de errores observados en el módulo MQTT.

Una solución importante aborda un problema por el cual los mensajes CONNECT eran rechazados cuando no se proporcionaba una contraseña. Anteriormente, esperábamos incondicionalmente que el campo de nombre de usuario fuera seguido por la contraseña. Sin embargo, existen casos especiales en la especificación MQTT (como la autenticación anónima) en los que no es obligatorio proporcionar una contraseña. La solución verifica condicionalmente si se espera la contraseña o no mirando el campo cflags del paquete. Si la bandera no está establecida, implica que la contraseña no es obligatoria.

Otra corrección de errores detiene el análisis de los mensajes MQTT CONNECT cuando la longitud del mensaje es menor que la cantidad de bytes recibidos.

Compatibilidad con tokens de servidor HTTP/3 con variables

NGINX Plus R31 agrega soporte para variables server_tokens faltantes para conexiones HTTP/3. El campo de cadena se puede utilizar para establecer explícitamente la firma en las páginas de error y el valor del campo de encabezado de respuesta “Servidor”. Si el campo de cadena está vacío, deshabilita la emisión del campo “Servidor”.

Cambios heredados de NGINX de código abierto

NGINX Plus R31 se basa en NGINX Open Source 1.25.3 y hereda cambios funcionales, características y correcciones de errores realizados desde que se lanzó NGINX Plus R30 (en NGINX 1.25.2 y 1.25.3).

Características

• Descubrimiento de MTU de ruta al utilizar QUIC : anteriormente, se utilizaba un tamaño predeterminado de 1200 MTU para todos los datagramas. Como parte de las mejoras de QUIC+HTTP/3, agregamos soporte para descubrir el tamaño de MTU de la ruta que luego se utiliza para todos los datagramas salientes.
• Optimizaciones de rendimiento en QUIC : la versión principal 1.25.2 de NGINX introdujo optimizaciones en la implementación de QUIC para reutilizar el contexto criptográfico para toda la sesión QUIC. Esto reduce los retrasos en el envío de paquetes ACK y coloca los marcos ACK al frente de la cola para disminuir las retransmisiones de marcos y los retrasos en la entrega de marcos ACK.
• Compatibilidad con el conjunto de cifrado TLS_AES_128_CCM_SHA256 al usar HTTP/3 : esta mejora agrega compatibilidad con TLS_AES_128_CCM_SHA256 a QUIC, que actualmente es el único conjunto de cifrado no compatible con la implementación de QUIC de NGINX. Está deshabilitado de forma predeterminada en OpenSSL y se puede habilitar con esta directiva: ssl_conf_command Ciphersuites TLS_AES_128_CCM_SHA256;
• Proporcionar el nombre de la aplicación nginx al cargar configuraciones de OpenSSL : al usar la interfaz OPENSSL_init_ssl() , en lugar de verificar OPENSSL_VERSION_NUMBER , NGINX ahora prueba que OPENSSL_INIT_LOAD_CONFIG esté definido y sea verdadero. Esto garantiza que la interfaz no se utilice con BoringSSL y LibreSSL, ya que no proporcionan configuraciones de inicialización de biblioteca adicionales (en particular, la llamada OPENSSL_INIT_set_config_appname() ).

Cambios

• Cambio en el algoritmo de ordenamiento de colas de NGINX : como se detalla anteriormente, NGINX ahora utiliza ordenamiento por combinación , que tiene una complejidad temporal de O(n*log n) . Esto crea una mejor experiencia de inicio de NGINX , especialmente cuando hay una cantidad muy elevada de “ubicaciones” en la configuración.
• Límite de manejo de flujo de iteración HTTP/2 : esta mejora garantiza la detección temprana de ataques de inundación en NGINX al imponer un límite en la cantidad de flujos nuevos que se pueden introducir en un bucle de eventos. Este límite es el doble del valor y se configura mediante http2_max_concurrent_streams . Se aplica incluso si nunca se alcanza el umbral máximo de transmisiones simultáneas permitidas para tener en cuenta los casos en que las transmisiones se restablecen inmediatamente después de enviar las solicitudes.

Corrección de errores

• Gestión de búfer fija con detección automática HTTP/2 : como parte de la detección automática HTTP/2 en conexiones TCP simples, los datos iniciales se leen primero en un búfer especificado por la directiva client_header_buffer_size que no tiene reserva de estado. Esto provocó un problema por el cual el búfer podía sobreleerse al guardar el estado. La solución actual permite leer solo el tamaño de búfer disponible en lugar del tamaño de búfer fijo. Este error apareció por primera vez en la versión principal de NGINX 1.25.1 (NGINX Plus R30).
• Modo de transporte incorrecto en el modo de compatibilidad con OpenSSL : antes de esta versión, la capa de compatibilidad de OpenSSL provocaba que la conexión se demorara en caso de que el cliente enviara un parámetro de transporte incorrecto. La solución maneja este comportamiento sin esfuerzo notificando primero al usuario sobre el parámetro incorrecto y luego cerrando la conexión.
• Se corrigió el manejo de encabezados de estado sin frase de motivo : un encabezado de estado con una frase de motivo vacía como Estado: 404 era válido según la especificación de la Interfaz de puerta de enlace común (CGI), pero perdió el espacio final durante el análisis. Esto generó una línea de estado HTTP/1.1 404 en la respuesta, lo que viola la especificación HTTP debido a un espacio final faltante. Con esta corrección de errores, solo se usa el código de estado de esas líneas de encabezado de estado cortas, por lo que NGINX generará la línea de estado por sí misma con el espacio y la frase de motivo apropiada si está disponible.
• Se solucionó una pérdida de memoria al recargar la configuración con PCRE2 : este problema ocurrió cuando NGINX estaba configurado para usar PCRE2 en la versión 1.21.5 o superior.

Para obtener la lista completa de nuevos cambios, características, correcciones de errores y soluciones alternativas heredadas de versiones recientes, consulte el archivo CAMBIOS DE NGINX.

Cambios en el módulo JavaScript de NGINX

NGINX Plus R31 incorpora cambios de la versión 0.8.2 del módulo NGINX JavaScript (njs). Aquí está la lista de cambios notables en njs desde 0.8.0 (que fue parte del lanzamiento de NGINX Plus R30).

Características

• Se introdujo el objeto de consola. Se introdujeron estos métodos: error() , info() , log() , time() , timeEnd() y warn() .
• Se introdujo la directiva js_periodic para http y stream que permite especificar un controlador JS para ejecutar a intervalos regulares.
• Se implementó el método items() de un diccionario compartido . Este método devuelve todos los pares clave-valor no vencidos.

Cambios

• Se amplió el módulo “fs”. Se agregó el método existsSync() .

Corrección de errores

• Se arregló el módulo “xml”. Se corrigió el manejo de excepciones XML dañado en el método parse() .
• Se corrigió RegExp.prototype.exec() con expresión regular global (regexp) y entrada Unicode.
• Métodos de tamaño fijo() y claves() de un diccionario compartido .
• Se corrigió una excepción errónea en r.internalRedirect() que se introdujo en 0.8.0.
• Se corrigió el orden incorrecto de las claves en Object.getOwnPropertyNames() .
• Se solucionó el manejo de la respuesta HEAD con una longitud de contenido grande en la API de búsqueda.
• Método items() fijo para un diccionario compartido.

Para obtener una lista completa de todas las características, cambios y correcciones de errores, consulte el registro de cambios de njs.

Actualice o pruebe NGINX Plus

Si está utilizando NGINX Plus, le recomendamos encarecidamente que actualice a NGINX Plus R31 lo antes posible. Además de todas las nuevas y excelentes funciones, también obtendrá varias correcciones y mejoras adicionales, y estar actualizado ayudará a NGINX a ayudarlo si necesita generar un ticket de soporte.

Si aún no has probado NGINX Plus, te recomendamos que lo hagas. Puede usarlo para casos de uso de seguridad, equilibrio de carga y puerta de enlace de API, o como un servidor web totalmente compatible con API de administración y monitoreo mejoradas. Comience hoy con una prueba gratuita de 30 días .