Presentamos NGINX Plus R31

Prabhat Dixit

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

Las funcionalidades nuevas y mejoradas de NGINX Plus R31 incluyen:

• Informes nativos sobre el uso de NGINX – NGINX Plus ahora ofrece compatibilidad nativa para generar informes sobre las implementaciones de NGINX en toda su organización, lo que permite obtener una visión consolidada de su infraestructura de NGINX en NGINX Instance Manager. Esta función permite mejorar la gobernanza de las instancias de NGINX con fines de cumplimiento normativo.
• Mejoras en la configuración de SNI – Anteriormente, el nombre del servidor que se transmitía mediante la indicación del nombre del servidor (SNI) utilizaba la directiva proxy_ssl_name y se aplicaba a todos los servidores del grupo de servidores ascendentes. NGINX Plus R31 permite configurar este SNI para un servidor ascendente seleccionado.
• Ejecución periódica de tareas con NGINX JavaScript – NGINX JavaScript incorpora la directiva js_periodic, que permite ejecutar contenido a intervalos periódicos. Esta mejora elimina la necesidad de configurar una tarea cron y puede configurarse para ejecutarse en todos los procesos de trabajo o solo en algunos específicos para optimizar el rendimiento.
• Una mejor experiencia de inicio de NGINX – NGINX Plus R31 mejora la experiencia general de inicio de NGINX cuando la configuración contiene un gran número de «ubicaciones».
• Optimizaciones y mejoras de QUIC+HTTP/3 – NGINX Plus R31 incorpora numerosas mejoras y optimizaciones de rendimiento en la implementación de QUIC, como la compatibilidad con la detección de la unidad máxima de transmisión (MTU) de la ruta, mejoras en el control de congestión y la posibilidad de reutilizar el contexto criptográfico durante toda la sesión QUIC.

La versión se completa con nuevas funcionalidades y correcciones de errores heredadas de NGINX Open Source, así como con 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 R30, asegúrese de consultar la sección Cambios importantes de comportamiento en los blogs de anuncios anteriores para todas las versiones comprendidas entre la que utiliza actualmente y esta.

Obsolescencia del módulo OpenTracing

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

Mensaje de advertencia por no informar del uso de NGINX

Los usuarios de NGINX Plus deben notificar a F5 su uso de NGINX para cumplir los requisitos normativos. Con el lanzamiento de NGINX Plus R31, la función para notificar el uso de NGINX a NGINX Instance Manager está integrada y activada de forma predeterminada. Si, por cualquier motivo, la instancia de NGINX no puede proporcionar información sobre su uso a NGINX Instance Manager, se registra un mensaje de advertencia.

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

Cambios en la compatibilidad con plataformas

Nuevos sistemas operativos compatibles:

• FreeBSD 14
• Alpine 3.19

Sistemas operativos 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 cuya eliminación está prevista en NGINX Plus R32:

• FreeBSD 12, que llegará al final de su vida útil el 31 de diciembre de 2023

Nuevas funciones en detalle

Informes nativos de uso de NGINX

NGINX Plus R31 incorpora comunicación nativa con NGINX Instance Manager en su red para automatizar el cumplimiento de las licencias. Si participa en el programa F5 Flex Consumption Program, ya no tendrá que realizar un seguimiento manual de sus instancias de NGINX Plus.

De forma predeterminada, NGINX Plus intentará detectar NGINX Instance Manager al iniciarse mediante una consulta DNS del nombre de host nginx-mgmt.local. Aunque el nombre de host se puede configurar, recomendamos, para simplificar, añadir un registro A al DNS local que asocie el nombre de host predeterminado con la dirección IP del sistema en el que se ejecuta NGINX Instance Manager. A continuación, NGINX Plus establecerá una conexión TLS con NGINX Instance Manager y comunicará su número de versión, nombre de host e identificador único cada treinta minutos.

Para añadir una capa adicional de seguridad, también recomendamos configurar esta conexión con mTLS mediante el mgmt bloque de configuración opcional. A intervalos regulares, NGINX Instance Manager notificará el uso total de las instancias de NGINX Plus a un servicio de F5.

Verá un mensaje de advertencia en el registro de errores si NGINX Plus tiene algún problema para resolver el nombre de host nginx-mgmt.local o para comunicarse con NGINX Instance Manager.

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 [advertencia] 3050#3050: informe de uso: no se encontró el host al resolver el endpoint "nginx-mgmt.local”

Y este es un ejemplo de un mensaje de error que indica que la instancia de NGINX Plus está teniendo dificultades para comunicarse con NGINX Instance Manager:

2023/12/21 21:02:01 [warn] 3184#3184: usage report: connection timed out

Personalización de la configuración del bloque mgmt Configuration Block Settings

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

A continuación se muestra un ejemplo de configuración personalizada:

mgmt {
    usage_report endpoint=instance-manager.local interval=30m;
    resolver 192.168.0.2; # Sample internal DNS IP

    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 más información 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 utiliza una versión anterior de NGINX Plus, puede seguir notificando sus instancias siguiendo estas instrucciones.

Mejoras en la configuración de SNI

Antes de esta versión, NGINX Plus presuponía que todos los servidores de un grupo de servidores ascendentes eran idénticos. Esto significa que debían poder responder a las mismas solicitudes, responder al mismo nombre SNI (cuando se utiliza proxy_ssl_server_name) y devolver certificados SSL que coincidieran con ese mismo nombre.

Sin embargo, hay situaciones en las que este comportamiento no es suficiente. Por ejemplo, cuando varios servidores virtuales comparten un mismo servidor ascendente y es necesario distinguirlos mediante un SNI o una cabecera de host diferentes para dirigir las solicitudes a recursos específicos. También es posible que no se pueda utilizar el mismo certificado en todos los servidores del grupo ascendente o que existan limitaciones que impidan distribuir los servidores ascendentes en grupos separados.

NGINX Plus R31 incorpora la posibilidad de configurar SNI para cada servidor upstream. La variable $upstream_last_server_name hace referencia al nombre del servidor upstream seleccionado, que puede pasarse al servidor al que se reenvía la solicitud mediante las directivas proxy_ssl_server_name y proxy_ssl_name.

Así se configura proxy_ssl_server_name como on, lo que permite pasar un nombre de servidor mediante SNI:
proxy_ssl_server_name on;

Y así es como se pasa el nombre del servidor ascendente seleccionado mediante proxy_ssl_name:
proxy_ssl_name $upstream_last_server_name;

Ejecución periódica de tareas con JavaScript de NGINX

NGINX JavaScript v0.8.1 introdujo una nueva directiva, «js_periodic», que está disponible tanto en los contextos «http» como «stream». Esta directiva permite especificar un controlador de contenido JavaScript que se ejecute a intervalos regulares. Esto resulta útil cuando es necesario ejecutar código personalizado periódicamente y este puede requerir acceso a variables de 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 puede configurarse para que se ejecute en procesos de trabajo específicos o en todos ellos.

Esta directiva está disponible en el contexto location:

example.conf:

location @periodics {

    # to be run at 15 minute intervals in worker processes 1 and 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:

async function handler(s) {
    let reply = await ngx.fetch('https://nginx.org/en/docs/njs/');
    let body = await reply.text();

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

Para obtener información detallada sobre la sintaxis y la configuración, consulte la documentación de NGINX JavaScript.

Una mejor experiencia de inicio de NGINX

En situaciones en las que una configuración de NGINX contiene un gran número de «locations», el arranque de NGINX puede tardar bastante tiempo. En muchos casos, esto podría no ser aceptable. La causa principal se encuentra en el algoritmo de ordenación utilizado para ordenar la lista de ubicaciones.

NGINX R31 incorpora una mejora que sustituye el algoritmo de ordenación existente, la ordenación por inserción, cuya complejidad temporal es de O(n2), por la ordenación por mezcla, con una complejidad temporal de O(n*log n).

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

Optimizaciones y mejoras de QUIC+HTTP/3

NGINX Plus R31 incorpora varias mejoras y optimizaciones de rendimiento en la implementación de QUIC+HTTP/3, como las siguientes:

• Detección de la unidad máxima de transmisión (MTU) de la ruta al utilizar QUIC+HTTP/3 – La MTU de la ruta es una medida en bytes del tamaño máximo de una trama o un paquete de datos que puede transmitirse 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 permite detectar el tamaño de la MTU de la ruta, que se utiliza posteriormente para todos los datagramas salientes.
• Reutilización del contexto criptográfico durante toda la sesión QUIC – Esta optimización está relacionada con el cifrado y descifrado de los paquetes QUIC. Anteriormente, se creaba un contexto criptográfico independiente para cada operación de cifrado o descifrado. Ahora se utiliza el mismo contexto durante toda la sesión QUIC, lo que mejora el rendimiento.

Entre las optimizaciones de rendimiento adicionales se incluyen la reducción de posibles retrasos al enviar paquetes de confirmación, la colocación de las tramas de confirmación (ACK) al principio de la cola para reducir las retransmisiones de tramas y los retrasos en la entrega de las tramas ACK, así como mejoras en el comportamiento del 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 mgmt adicional

En NGINX Plus R31, ngx_mgmt_module permite enviar información sobre el uso de NGINX a NGINX Instance Manager. Esta información incluye el nombre de host de NGINX, la versión de NGINX y un identificador único de la instancia.

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

Correcciones de errores en el módulo MQTT

La compatibilidad con el protocolo de transporte de telemetría de colas de mensajes (MQTT) se introdujo en NGINX Plus R29 y esta versión incluye varias correcciones de errores detectados en el módulo MQTT.

Una corrección importante resuelve un problema por el que los mensajes CONNECT se rechazaban cuando no se proporcionaba una contraseña. Anteriormente, se esperaba de forma incondicional que el campo de nombre de usuario fuera seguido de una contraseña. Sin embargo, la especificación MQTT contempla casos especiales —como la autenticación anónima— en los que no es obligatorio proporcionar una contraseña. La corrección comprueba de forma condicional si se espera una contraseña consultando el campo cflags del paquete. Si la marca no está establecida, significa que la contraseña no es obligatoria.

Otra corrección de errores detiene el análisis de los mensajes CONNECT de MQTT cuando la longitud del mensaje es inferior al número de bytes recibidos.

Compatibilidad de HTTP/3 con «server_tokens» mediante variables

NGINX Plus R31 añade compatibilidad con las variables de server_tokens que faltaban para las conexiones HTTP/3. El campo string se puede utilizar para establecer explícitamente la firma en las páginas de error y el valor del campo de cabecera de respuesta «Server». Si el campo string está vacío, se deshabilita la emisión del campo «Server».

Cambios heredados de NGINX Open Source

NGINX Plus R31 se basa en NGINX Open Source 1.25.3 y hereda los cambios funcionales, las funcionalidades y las correcciones de errores realizados desde el lanzamiento de NGINX Plus R30 (en NGINX 1.25.2 y 1.25.3).

Funcionalidades

• Descubrimiento de la MTU de la ruta al usar QUIC – Anteriormente, se utilizaba un tamaño de MTU predeterminado de 1200 para todos los datagramas. Como parte de las mejoras de QUIC+HTTP/3, hemos añadido compatibilidad con el descubrimiento del tamaño de la MTU de la ruta, que se utiliza posteriormente para todos los datagramas salientes.
• Optimizaciones de rendimiento en QUIC – La versión 1.25.2 de la rama principal de NGINX introdujo optimizaciones en la implementación de QUIC para reutilizar el contexto criptográfico durante toda la sesión QUIC. Esto reduce los retrasos en el envío de paquetes ACK y coloca las tramas ACK al principio de la cola para reducir las retransmisiones de tramas y los retrasos en la entrega de tramas ACK.
• Compatibilidad con el conjunto de cifrado TLS_AES_128_CCM_SHA256 al utilizar HTTP/3 – Esta mejora añade 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 puede habilitarse con esta directiva: ssl_conf_command Ciphersuites TLS_AES_128_CCM_SHA256;
• Proporcionar nginx como appName al cargar configuraciones de OpenSSL – Al utilizar la interfaz OPENSSL_init_ssl(), en lugar de comprobar OPENSSL_VERSION_NUMBER, NGINX ahora comprueba 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 opciones adicionales de inicialización de la biblioteca (en particular, la llamada a OPENSSL_INIT_set_config_appname()).

Cambios

• Cambio en el algoritmo de ordenación de la cola de NGINX – Como se ha detallado anteriormente, NGINX utiliza ahora la ordenación por mezcla, cuya complejidad temporal es de O(n*log n). Esto permite una mejor experiencia de inicio de NGINX, especialmente cuando hay un número muy elevado de «ubicaciones» en la configuración.
• Límite de gestión de flujos por iteración de HTTP/2 – Esta mejora garantiza la detección temprana de ataques de inundación contra NGINX al limitar el número de flujos nuevos que pueden introducirse en una sola iteración del bucle de eventos. Este límite equivale al doble del valor configurado mediante http2_max_concurrent_streams. Se aplica incluso si nunca se alcanza el umbral máximo de flujos simultáneos permitidos, para tener en cuenta los casos en los que los flujos se restablecen inmediatamente después de enviar las solicitudes.

Correcciones de errores

• Se ha corregido la gestión del búfer con la detección automática de HTTP/2 – Como parte de la detección automática de HTTP/2 en conexiones TCP sin cifrar, los datos iniciales se leen primero en un búfer especificado por la directiva client_header_buffer_size, que no reserva espacio para el estado. Esto provocaba que se pudiera leer más allá de los límites del búfer al guardar el estado. La corrección actual permite leer únicamente el tamaño disponible del búfer, en lugar del tamaño fijo. Este error apareció por primera vez en la versión 1.25.1 de la rama principal de NGINX (NGINX Plus R30).
• Modo de transporte incorrecto en el modo de compatibilidad con OpenSSL – Antes de esta versión, la capa de compatibilidad con OpenSSL provocaba un retraso en la conexión cuando el cliente enviaba un parámetro de transporte incorrecto. La corrección gestiona adecuadamente este comportamiento notificando primero al usuario que el parámetro es incorrecto y cerrando después la conexión.
• Se ha corregido el tratamiento de las cabeceras de estado sin frase de motivo – Una cabecera de estado con una «frase de motivo» vacía, como Status: 404, era válida según la especificación de la interfaz de puerta de enlace común (CGI), pero perdía el espacio final durante el análisis. Esto daba lugar a una línea de estado HTTP/1.1 404 en la respuesta, lo que incumple la especificación HTTP debido a la ausencia de un espacio final. Con esta corrección, en las líneas de cabecera Status tan cortas solo se utiliza el código de estado, por lo que NGINX generará la propia línea de estado con el espacio y la frase de motivo correspondiente, si está disponible.
• Corregida una fuga de memoria al recargar la configuración con PCRE2 – Este problema se producía cuando NGINX estaba configurado para usar PCRE2 en la versión 1.21.5 o posterior.

Para consultar la lista completa de nuevos cambios, funcionalidades, correcciones de errores y soluciones alternativas heredados de versiones recientes, consulte el archivo CHANGES de NGINX.

Cambios en el módulo JavaScript de NGINX

NGINX Plus R31 incorpora cambios del módulo NGINX JavaScript (njs) versión 0.8.2. Esta es la lista de cambios destacados de njs desde la versión 0.8.0 (incluida en la versión R30 de NGINX Plus).

Características

• Se introdujo el objeto console. Se incorporaron los siguientes métodos: error(), info(), log(), time(), timeEnd(), y warn().
• Se ha introducido la directiva js_periodic para http y stream, que permite especificar un controlador de JS que se ejecute a intervalos regulares.
• Se ha implementado el método items() de un diccionario compartido. Este método devuelve todos los pares clave-valor que no han caducado.

Cambios

• Se ha ampliado el módulo «fs». Se ha añadido el método existsSync().

Correcciones de errores

• Se ha corregido el módulo «xml». Se ha corregido la gestión defectuosa de excepciones XML en el método parse().
• Se ha corregido RegExp.prototype.exec() con expresiones regulares globales (regexp) y entrada Unicode.
• Se han corregido los métodos size(), y keys() de un diccionario compartido.
• Se corrigió una excepción errónea en r.internalRedirect() que se introdujo en la versión 0.8.0.
• Se corrigió el orden incorrecto de las claves en Object.getOwnPropertyNames().
• Se ha corregido la gestión de las respuestas HEAD con un valor de Content-Length elevado en la API fetch.
• Se ha corregido el método items() de los diccionarios compartidos.

Para consultar una lista completa de todas las funcionalidades, cambios y correcciones de errores, consulte el registro de cambios de njs.

Actualice o pruebe NGINX Plus

Si utiliza NGINX Plus, le recomendamos encarecidamente que actualice a NGINX Plus R31 lo antes posible. Además de todas las fantásticas funciones nuevas, también obtendrá varias correcciones y mejoras adicionales. Asimismo, mantener el producto actualizado permitirá que NGINX pueda ayudarle mejor si necesita abrir una incidencia de soporte.

Si aún no has probado NGINX Plus, te animamos a hacerlo. Puedes utilizarlo para casos de uso de seguridad, balanceo de carga y puerta de enlace de API, o como servidor web con soporte completo y API avanzadas de supervisión y gestión. Empieza hoy mismo con una prueba gratuita de 30 días.

Sobre el autor

Prabhat Dixit

Más artículos de Prabhat Dixit