Optimizing MQTT Deployments in Enterprise Environments with NGINX Plus (Optimización de las implementaciones MQTT en entornos empresariales con NGINX Plus)

Cuando anunciamos el lanzamiento de la versión R29 de NGINX Plus , cubrimos brevemente su nuevo soporte nativo para analizar mensajes MQTT . En esta publicación, nos basaremos en eso y analizaremos cómo se puede configurar NGINX Plus para optimizar las implementaciones de MQTT en entornos empresariales.

¿Qué es MQTT?

MQTT significa Message Queueing Telemetry Transport . Es un protocolo de mensajería de publicación-suscripción ligero y muy popular, ideal para conectar dispositivos y aplicações de Internet de las cosas (IoT) o de máquina a máquina (M2M) a través de Internet. MQTT está diseñado para funcionar de manera eficiente en entornos de bajo ancho de banda o de bajo consumo, lo que lo convierte en una opción ideal para aplicações con una gran cantidad de clientes remotos. Se utiliza en una variedad de industrias, incluidas la electrónica de consumo, la automotriz, el transporte, la fabricación y la atención médica.

Procesamiento de mensajes MQTT de NGINX Plus

NGINX Plus R29 es compatible con MQTT 3.1.1 y MQTT 5.0 . Actúa como proxy entre clientes y corredores, descargando tareas de los sistemas centrales, simplificando la escalabilidad y reduciendo los costos computacionales. Específicamente, NGINX Plus analiza y reescribe partes de mensajes MQTT CONNECT , lo que permite funciones como:

• Balanceo de carga del agente MQTT 
• Persistencia de la sesión (reconectar clientes al mismo bróker) 
• Terminación SSL/TLS
• Autenticación del certificado de cliente 

Las directivas de procesamiento de mensajes MQTT deben definirse en el contexto de flujo de un archivo de configuración NGINX y son proporcionadas por ngx_stream_mqtt_preread_module
y ngx_stream_mqtt_filter_module .

El módulo de prelectura procesa los datos MQTT antes del proxy interno de NGINX, lo que permite tomar decisiones de equilibrio de carga y enrutamiento ascendente en función de los datos de mensajes analizados.

El módulo de filtro permite reescribir los campos clientid , username y password dentro de los mensajes CONNECT recibidos. La capacidad de configurar estos campos como variables y valores complejos amplía significativamente las opciones de configuración, lo que permite a NGINX Plus enmascarar información confidencial del dispositivo o insertar datos como un nombre distinguido de certificado TLS.

Directivas y variables MQTT

Ahora hay varias directivas nuevas y variables integradas disponibles para ajustar su configuración de NGINX para optimizar las implementaciones de MQTT y satisfacer sus necesidades específicas.

Directivas de módulo de prelectura y variables integradas

• mqtt_preread – Habilita el análisis de MQTT, extrayendo los campos clientid y username de los mensajes CONNECT enviados por los dispositivos cliente. Estos valores se ponen a disposición a través de variables integradas y ayudan a equilibrar la carga de las sesiones en los servidores ascendentes (ejemplos a continuación).
• $mqtt_preread_clientid – Representa el identificador de cliente MQTT enviado por el dispositivo.
• $mqtt_preread_username – Representa el nombre de usuario enviado por el cliente para fines de autenticación.

Directivas del módulo de filtro

• mqtt – Define si la reescritura de MQTT está habilitada.
• mqtt_buffers : anula la cantidad máxima de buffers de procesamiento MQTT que se pueden asignar por conexión y el tamaño de cada buffer. De forma predeterminada, NGINX impondrá un límite de 100 buffers por conexión, cada uno de 1k de longitud. Normalmente, esto es óptimo para el rendimiento, pero puede requerir ajustes en situaciones especiales. Por ejemplo, los mensajes MQTT más largos requieren un tamaño de búfer mayor. Los sistemas que procesan un mayor volumen de mensajes MQTT para una conexión determinada dentro de un período corto de tiempo pueden beneficiarse de una mayor cantidad de buffers. En la mayoría de los casos, el ajuste de los parámetros del buffer tiene poca influencia en el rendimiento del sistema subyacente, ya que NGINX construye buffers a partir de un grupo de memoria interna.
• mqtt_rewrite_buffer_size : especifica el tamaño del búfer utilizado para construir mensajes MQTT. Esta directiva ha quedado obsoleta desde NGINX Plus R30.
• mqtt_set_connect – Reescribe los parámetros del mensaje CONNECT enviado desde un cliente. Los parámetros admitidos incluyen: clientid , username y password .

Ejemplos de MQTT

Exploremos los beneficios de procesar mensajes MQTT con NGINX Plus y las mejores prácticas asociadas con más detalle. Tenga en cuenta que utilizamos los puertos 1883 y 8883 en los ejemplos siguientes. El puerto 1883 es el puerto MQTT no seguro predeterminado, mientras que 8883 es el puerto cifrado SSL/TLS predeterminado.

Balanceo de carga del bróker MQTT

La naturaleza efímera de los dispositivos MQTT puede provocar que las IP de los clientes cambien inesperadamente. Esto puede generar desafíos al enrutar las conexiones del dispositivo al agente ascendente correcto. El movimiento posterior de conexiones de dispositivos de un agente ascendente a otro puede generar costosas operaciones de sincronización entre agentes, lo que aumenta la latencia y los costos.

Al analizar el campo clientid en un mensaje MQTT CONNECT, NGINX puede establecer sesiones persistentes con intermediarios de servicios ascendentes. Esto se logra utilizando el clientid como clave hash para mantener las conexiones con los servicios del broker en el backend.

En este ejemplo, redirigimos los datos del dispositivo MQTT utilizando el ID del cliente como token para establecer sesiones persistentes con tres intermediarios ascendentes. Utilizamos el parámetro consistente para que, si un servidor ascendente falla, su parte del tráfico se distribuya de manera uniforme entre los servidores restantes sin afectar las sesiones que ya están establecidas en esos servidores.

stream {     mqtt_preread activado; 
   
    backend ascendente {
        zona tcp_mem 64k;
       hash $mqtt_preread_clientid consistente;
  
        servidor 10.0.0.7:1883; # agente mqtt ascendente 1
        servidor 10.0.0.8:1883; # agente mqtt ascendente 2
        servidor 10.0.0.9:1883; # agente mqtt ascendente 3 
}
}
}

NGINX Plus también puede analizar el campo de nombre de usuario de un mensaje MQTT CONNECT. Para obtener más detalles, consulte la especificación ngx_stream_mqtt_preread_module . 

Terminación SSL/TLS

Cifrar las comunicaciones del dispositivo es clave para garantizar la confidencialidad de los datos y protegerse contra ataques del tipo "man-in-the-middle". Sin embargo, el protocolo de enlace TLS, el cifrado y el descifrado pueden representar una carga de recursos para un agente MQTT. Para resolver esto, NGINX Plus puede descargar el cifrado de datos de un bróker (o un grupo de brókeres), simplificando las reglas de seguridad y permitiendo que los brókeres se concentren en procesar los mensajes del dispositivo. 

En este ejemplo, mostramos cómo se puede usar NGINX para redirigir tráfico MQTT cifrado con TLS desde dispositivos a un agente backend. La directiva ssl_session_cache define un caché de 5 megabytes, que es suficiente para almacenar aproximadamente 20.000 sesiones SSL. NGINX intentará comunicarse con el agente proxy durante cinco segundos antes de expirar el tiempo de espera, tal como lo define la directiva proxy_connect_timeout .

stream {     servidor {
        escucha 8883 ssl;
        certificado_ssl /etc/nginx/certs/tls-cert.crt;
        clave_certificado_ssl /etc/nginx/certs/tls-key.key;
        caché_sesión_ssl compartida:SSL:5m;
        contraseña_proxy 10.0.0.8:1883;
       tiempo_espera_conexión_proxy 5s;
    }
} 

Sustitución de ID de cliente

Por razones de seguridad, puede optar por no almacenar información identificable del cliente en la base de datos del broker MQTT. Por ejemplo, un dispositivo puede enviar un número de serie u otros datos confidenciales como parte de un mensaje MQTT CONNECT. Al reemplazar el identificador de un dispositivo con otros valores estáticos conocidos recibidos de un cliente, se puede establecer una clave única alternativa para cada dispositivo que intente acceder a los intermediarios proxy NGINX Plus.

En este ejemplo, extraemos un identificador único del certificado SSL de cliente de un dispositivo y lo usamos para enmascarar su ID de cliente MQTT. La autenticación del certificado de cliente (TLS mutuo) se controla con la directiva ssl_verify_client . Cuando se configura en el parámetro activado, NGINX garantiza que los certificados de cliente estén firmados por una autoridad de certificación (CA) confiable. La lista de certificados CA de confianza está definida por la directiva ssl_client_certificate . 

stream {     mqtt activado; 
  
    servidor {
        escuchar 8883 ssl;
        certificado_ssl /etc/nginx/certs/tls-cert.crt;
        clave_certificado_ssl /etc/nginx/certs/tls-key.key;
        certificado_cliente_ssl /etc/nginx/certs/client-ca.crt;
        caché_session_ssl compartido:SSL:10m;
ssl_verify_client activado;
proxy_pass 10.0.0.8:1883;
proxy_connect_timeout 1s;
mqtt_set_connect clientid $ssl_client_serial;
}
}

Certificado de cliente como credencial de autenticación

Un enfoque común para autenticar clientes MQTT es utilizar datos almacenados en un certificado de cliente como nombre de usuario. NGINX Plus puede analizar certificados de cliente y reescribir el campo de nombre de usuario MQTT, descargando esta tarea de los intermediarios del backend. En el siguiente ejemplo, extraemos el nombre distinguido del sujeto (DN del sujeto) del certificado del cliente y lo copiamos en la parte del nombre de usuario de un mensaje MQTT CONNECT.

stream {     mqtt activado; 
   
    servidor {
        escuchar 8883 ssl;
        certificado_ssl /etc/nginx/certs/tls-cert.crt;
        clave_certificado_ssl /etc/nginx/certs/tls-key.key;
        certificado_cliente_ssl /etc/nginx/certs/client-ca.crt;
        caché_session_ssl compartida:SSL:10m;
ssl_verify_client activado;
proxy_pass 10.0.0.8:1883;
proxy_connect_timeout 1s;
mqtt_set_connect nombre_usuario $ssl_client_s_dn;
}
} 

Para obtener una especificación completa sobre la reescritura de mensajes NGINX Plus MQTT CONNECT, consulte la especificación ngx_stream_mqtt_filter_module .

Empieza hoy

Los desarrollos futuros de MQTT en NGINX Plus pueden incluir el análisis de otros tipos de mensajes MQTT, así como un análisis más profundo del mensaje CONNECT para habilitar funciones como:

• Mecanismos adicionales de autenticación y control de acceso
• Proteger a los corredores limitando la tasa de clientes "conversadores"
• Telemetría de mensajes y métricas de conexión

Si es nuevo en NGINX Plus, regístrese para una prueba gratuita de 30 días para comenzar a utilizar MQTT. También nos encantaría conocer tus comentarios sobre las características que más te interesan. Déjanos saber lo que piensas en los comentarios.