Otimizando implantações de MQTT em ambientes corporativos com o NGINX Plus

Ao anunciar o lançamento R29 do NGINX Plus , abordamos brevemente seu novo suporte nativo para análise de mensagens MQTT . Nesta postagem, desenvolveremos isso e discutiremos como o NGINX Plus pode ser configurado para otimizar implantações MQTT em ambientes corporativos.

O que é o MQTT?

MQTT significa Transporte de Telemetria de Enfileiramento de Mensagens . É um protocolo de mensagens de publicação e assinatura leve e muito popular, ideal para conectar dispositivos e aplicativos de Internet das Coisas (IoT) ou máquina a máquina (M2M) pela Internet. O MQTT foi projetado para operar com eficiência em ambientes de baixa largura de banda ou baixo consumo de energia, o que o torna uma escolha ideal para aplicações com um grande número de clientes remotos. Ele é usado em diversos setores, incluindo eletrônicos de consumo, automotivo, transporte, manufatura e saúde.

Processamento de mensagens NGINX Plus MQTT

O NGINX Plus R29 suporta MQTT 3.1.1 e MQTT 5.0 . Ele atua como um proxy entre clientes e corretores, descarregando tarefas dos sistemas principais, simplificando a escalabilidade e reduzindo os custos de computação. Especificamente, o NGINX Plus analisa e reescreve partes de mensagens MQTT CONNECT , habilitando recursos como:

• Balanceamento de carga do broker MQTT 
• Persistência de sessão (reconectando clientes ao mesmo corretor) 
• Encerramento do SSL/TLS
• Autenticação de certificado de cliente 

As diretivas de processamento de mensagens MQTT devem ser definidas no contexto de fluxo de um arquivo de configuração NGINX e são fornecidas pelo ngx_stream_mqtt_preread_module
e ngx_stream_mqtt_filter_module .

O módulo de pré-leitura processa dados MQTT antes do proxy interno do NGINX, permitindo que decisões de balanceamento de carga e roteamento upstream sejam tomadas com base em dados de mensagens analisados.

O módulo de filtro permite a reescrita dos campos clientid , username e password nas mensagens CONNECT recebidas. A capacidade de definir esses campos como variáveis e valores complexos expande significativamente as opções de configuração, permitindo que o NGINX Plus mascare informações confidenciais do dispositivo ou insira dados como um nome distinto de certificado TLS.

Diretivas e variáveis MQTT

Várias novas diretivas e variáveis incorporadas agora estão disponíveis para ajustar sua configuração do NGINX para otimizar implantações MQTT e atender às suas necessidades específicas.

Diretivas de módulo de pré-leitura e variáveis incorporadas

• mqtt_preread – Habilita a análise MQTT, extraindo os campos clientid e username das mensagens CONNECT enviadas pelos dispositivos clientes. Esses valores são disponibilizados por meio de variáveis incorporadas e ajudam a fazer hash de sessões para balancear a carga dos servidores upstream (exemplos abaixo).
• $mqtt_preread_clientid – Representa o identificador do cliente MQTT enviado pelo dispositivo.
• $mqtt_preread_username – Representa o nome de usuário enviado pelo cliente para fins de autenticação.

Diretivas do módulo de filtro

• mqtt – Define se a reescrita MQTT está habilitada.
• mqtt_buffers – Substitui o número máximo de buffers de processamento MQTT que podem ser alocados por conexão e o tamanho de cada buffer. Por padrão, o NGINX imporá um limite de 100 buffers por conexão, cada um com 1k de comprimento. Normalmente, isso é ideal para desempenho, mas pode exigir ajustes em situações especiais. Por exemplo, mensagens MQTT mais longas exigem um tamanho de buffer maior. Sistemas que processam um volume maior de mensagens MQTT para uma determinada conexão em um curto período de tempo podem se beneficiar de um número maior de buffers. Na maioria dos casos, o ajuste dos parâmetros do buffer tem pouca influência no desempenho do sistema subjacente, pois o NGINX constrói buffers a partir de um pool de memória interna.
• mqtt_rewrite_buffer_size – Especifica o tamanho do buffer usado para construir mensagens MQTT. Esta diretiva foi descontinuada e está obsoleta desde o NGINX Plus R30.
• mqtt_set_connect – Reescreve parâmetros da mensagem CONNECT enviada de um cliente. Os parâmetros suportados incluem: clientid , username e password .

Exemplos de MQTT

Vamos explorar os benefícios do processamento de mensagens MQTT com o NGINX Plus e as práticas recomendadas associadas em mais detalhes. Observe que usamos as portas 1883 e 8883 nos exemplos abaixo. A porta 1883 é a porta MQTT não segura padrão, enquanto 8883 é a porta criptografada SSL/TLS padrão.

Balanceamento de carga do Broker MQTT

A natureza efêmera dos dispositivos MQTT pode fazer com que os IPs dos clientes mudem inesperadamente. Isso pode criar desafios ao rotear conexões de dispositivos para o broker upstream correto. A movimentação subsequente de conexões de dispositivos de um broker upstream para outro pode resultar em operações de sincronização caras entre brokers, aumentando a latência e o custo.

Ao analisar o campo clientid em uma mensagem MQTT CONNECT, o NGINX pode estabelecer sessões persistentes com corretores de serviço upstream. Isso é obtido usando o clientid como uma chave de hash para manter conexões com serviços de corretagem no backend.

Neste exemplo, usamos o proxy de dados do dispositivo MQTT usando o clientid como um token para estabelecer sessões persistentes para três corretores upstream. Usamos o parâmetro consistente para que, se um servidor upstream falhar, sua parcela do tráfego seja distribuída uniformemente entre os servidores restantes, sem afetar as sessões já estabelecidas nesses servidores.

fluxo {     mqtt_preread em; 
   
    backend upstream {
        zona tcp_mem 64k;
        hash $mqtt_preread_clientid consistente;
  
        servidor 10.0.0.7:1883; # corretor mqtt upstream 1
        servidor 10.0.0.8:1883; # corretor mqtt upstream 2
        servidor 10.0.0.9:1883; # corretor mqtt upstream 3 
    }
  
    servidor {
        ouvir 1883;
        proxy_pass backend;
        proxy_connect_timeout 1s;
    }
}

O NGINX Plus também pode analisar o campo de nome de usuário de uma mensagem MQTT CONNECT. Para mais detalhes, consulte a especificação ngx_stream_mqtt_preread_module . 

Encerramento do SSL/TLS

Criptografar as comunicações do dispositivo é essencial para garantir a confidencialidade dos dados e proteger contra ataques do tipo man-in-the-middle. No entanto, o handshake TLS, a criptografia e a descriptografia podem ser um fardo de recursos para um corretor MQTT. Para resolver isso, o NGINX Plus pode descarregar a criptografia de dados de um corretor (ou um cluster de corretores), simplificando as regras de segurança e permitindo que os corretores se concentrem no processamento de mensagens do dispositivo. 

Neste exemplo, mostramos como o NGINX pode ser usado para fazer proxy de tráfego MQTT criptografado por TLS de dispositivos para um broker de backend. A diretiva ssl_session_cache define um cache de 5 megabytes, o que é suficiente para armazenar aproximadamente 20.000 sessões SSL. O NGINX tentará alcançar o broker com proxy por cinco segundos antes de atingir o tempo limite, conforme definido pela diretiva proxy_connect_timeout .

fluxo {     servidor {
        ouvir 8883 ssl;
        certificado_ssl /etc/nginx/certs/tls-cert.crt;
        chave_certificado_ssl /etc/nginx/certs/tls-key.key;
        cache_de_sessão_ssl compartilhado: SSL: 5 m;
        proxy_pass 10.0.0.8:1883;
        tempo_limite_de_conexão_proxy_5s;
    }
} 

Substituição de ID do cliente

Por motivos de segurança, você pode optar por não armazenar informações de identificação do cliente no banco de dados do corretor MQTT. Por exemplo, um dispositivo pode enviar um número de série ou outros dados confidenciais como parte de uma mensagem MQTT CONNECT. Ao substituir o identificador de um dispositivo por outros valores estáticos conhecidos recebidos de um cliente, uma chave exclusiva alternativa pode ser estabelecida para cada dispositivo que tenta alcançar os corretores proxy do NGINX Plus.

Neste exemplo, extraímos um identificador exclusivo do certificado SSL do cliente de um dispositivo e o usamos para mascarar seu ID de cliente MQTT. A autenticação do certificado do cliente (TLS mútuo) é controlada com a diretiva ssl_verify_client . Quando definido como o parâmetro on, o NGINX garante que os certificados do cliente sejam assinados por uma Autoridade de Certificação (CA) confiável. A lista de certificados CA confiáveis é definida pela diretiva ssl_client_certificate . 

fluxo {     mqtt em; 
  
    servidor {
        ouvir 8883 ssl;
        certificado ssl /etc/nginx/certs/tls-cert.crt;
        chave do certificado ssl /etc/nginx/certs/tls-key.key;
        certificado ssl_client /etc/nginx/certs/client-ca.crt;
        cache_de_sessão_ssl compartilhado: SSL: 10 m;
        ssl_verify_client ligado;
        proxy_pass 10.0.0.8:1883;
        proxy_connect_timeout 1s;
        
        mqtt_set_connect clientid $ssl_client_serial;
    }
}

Certificado de cliente como credencial de autenticação

Uma abordagem comum para autenticar clientes MQTT é usar dados armazenados em um certificado de cliente como nome de usuário. O NGINX Plus pode analisar certificados de cliente e reescrever o campo de nome de usuário MQTT, aliviando essa tarefa dos corretores de backend. No exemplo a seguir, extraímos o Nome Distinto do Assunto (DN do Assunto) do certificado do cliente e o copiamos para a parte do nome de usuário de uma mensagem MQTT CONNECT.

fluxo {     mqtt em; 
   
    servidor {
        ouvir 8883 ssl;
        certificado ssl /etc/nginx/certs/tls-cert.crt;
        chave do certificado ssl /etc/nginx/certs/tls-key.key;
        certificado ssl_client /etc/nginx/certs/client-ca.crt;
        cache_de_sessão_ssl compartilhado: SSL: 10 m;
        ssl_verify_client em;
        proxy_pass 10.0.0.8:1883;
        proxy_connect_timeout 1s;
        
        mqtt_set_connect nome de usuário $ssl_client_s_dn;
    }
} 

Para uma especificação completa sobre a reescrita de mensagens NGINX Plus MQTT CONNECT, consulte a especificação ngx_stream_mqtt_filter_module .

Comece hoje mesmo

Desenvolvimentos futuros do MQTT no NGINX Plus podem incluir a análise de outros tipos de mensagens MQTT, bem como uma análise mais profunda da mensagem CONNECT para habilitar funções como:

• Mecanismos adicionais de autenticação e controle de acesso
• Protegendo corretores limitando a taxa de clientes “tagarelas”
• Telemetria de mensagens e métricas de conexão

Se você é novo no NGINX Plus, inscreva-se para um teste gratuito de 30 dias para começar a usar o MQTT. Também gostaríamos de ouvir sua opinião sobre os recursos mais importantes para você. Deixe-nos saber o que você pensa nos comentários.