Anunciando o NGINX Plus R28

Robert HaynesGerente de Marketing Técnico

Temos o prazer de anunciar a disponibilidade do NGINX Plus Release 28 (R28). Baseado no NGINX Open Source, o NGINX Plus é o único software completo que reúne servidor web, balanceador de carga, proxy reverso, cache de conteúdo e gateway de API.

Os recursos novos e aprimorados do NGINX Plus R28 incluem:

• Métricas adicionais de TLS – O NGINX Plus R28 coleta estatísticas adicionais de TLS nos níveis de sistema, cliente e servidor, fornecendo informações essenciais para solucionar erros relacionados a SSL/TLS na configuração do proxy e nas conexões com clientes e servidores upstream. O painel de monitoramento de atividades em tempo real do NGINX Plus foi atualizado para exibir os novos dados de sessão SSL.
• Suporte a TLVs do protocolo PROXY v2 em serviços privados de nuvem – Quando você disponibiliza recursos para clientes externos por meio de um “serviço privado” na AWS, no Google Cloud Platform e no Microsoft Azure, por padrão, o identificador de cliente específico do serviço, representado em um vetor de tipo-comprimento-valor (TLV) no cabeçalho do protocolo PROXY v2, não é repassado aos serviços de backend. O NGINX Plus R28 apresenta módulos para os contextos http e stream, que decodificam o TLV e definem uma variável para encaminhar o identificador do cliente aos serviços de backend.
• Suporte a variáveis para o parâmetro samesite do cookie persistente – No NGINX Plus R28, o valor do parâmetro samesite da diretiva sticky cookie pode ser uma variável. Essa melhoria facilita o gerenciamento do tráfego e aumenta a segurança.

Completando esta versão estão novos recursos e correções de bugs herdados do NGINX Open Source, além de atualizações no módulo JavaScript do NGINX.

Mudanças importantes de comportamento

Observação: Se você estiver atualizando de uma versão diferente do NGINX Plus R27, consulte a seção Alterações importantes de comportamento nos blogs de anúncio de todas as versões entre a sua versão atual e esta.

Alterações no suporte a plataformas

Novos sistemas operacionais e arquiteturas compatíveis:

• AlmaLinux 8 e 9 (x86_64, aarch64)
• Alpine 3.17 (x86_64, arm64)
• Oracle Linux 9 (x86_64)
• Rocky Linux 8 e 9 (x86_64, aarch64)

Sistemas operacionais mais antigos removidos:

• Debian 10, que chegou ao fim da vida útil (EOL) em agosto de 2022

Sistemas operacionais e arquiteturas mais antigos, descontinuados e com remoção programada no NGINX Plus R29:

• Alpine 3.13, que chegou ao fim da vida útil (EOL) em 1º de novembro de 2022

Alteração no tratamento de vários cabeçalhos com nomes idênticos

• A maioria dos cabeçalhos de resposta upstream duplicados conhecidos agora é ignorada, com a exibição de um aviso
• Cabeçalhos Content-Length e Transfer-Encoding duplicados agora são rejeitados, assim como respostas com cabeçalhos Content-Length ou Transfer-Encoding inválidos, ou quando ambos, Content-Length e Transfer-Encoding, estão presentes na resposta

Novos recursos em detalhes

Métricas adicionais de TLS

A observabilidade de eventos e erros de SSL/TLS é importante para solucionar problemas relacionados a TLS na configuração do proxy, nos servidores upstream e nos clientes. Desde a introdução da API do NGINX Plus no NGINX Plus R13, o NGINX Plus coleta três métricas de TLS em todo o sistema:

• handshakes – Número de handshakes SSL bem-sucedidos
• handshakes_failed – Número de falhas no handshake SSL (não inclui falhas de verificação de certificado que ocorrem após o handshake SSL)
• session_reuses – Número de reutilizações de sessão SSL

No NGINX Plus R27<.htmla> e versões posteriores, você pode configurar a coleta das três métricas para servidores upstream e servidores virtuais individuais.

O NGINX Plus R28 amplia o conjunto de métricas de TLS com novos contadores para erros de handshake e falhas na validação de certificados nos módulos HTTP e Stream (aqui fornecemos exemplos apenas para módulos HTTP, mas as métricas disponíveis para Stream são semelhantes). Para obter detalhes sobre como configurar a coleta de métricas para servidores upstream e servidores virtuais individuais, consulte o blog de anúncio do NGINX Plus R27<.htmlspan>.

Erros de handshake

Os contadores para os seguintes erros de handshake são novos no NGINX Plus R28:

• handshake_timeout – Número de falhas de handshake devido ao tempo limite do handshake
• no_common_cipher – Número de falhas de handshake devido à ausência de uma cifra em comum entre as partes envolvidas no handshake (não coletado para conexões com servidores upstream porque não se aplica)
• no_common_protocol – Número de falhas de handshake devido à ausência de um protocolo comum entre as partes
• peer_rejected_cert – Número de falhas de handshake causadas pela rejeição, pela outra parte, do certificado apresentado pelo NGINX Plus e pelo envio da mensagem de alerta apropriada

Falhas na verificação de certificados

As falhas na verificação de certificados agora são informadas na nova seção verify_failures da saída da API quando você configura a verificação de certificados:

• Para conexões com clientes usando a diretiva ssl_verify_client[HTTP][Stream]
• Para conexões com servidores que usam estas diretivas específicas de protocolo:
  • grpc_ssl_verify
  • proxy_ssl_verify[HTTP][Stream]
  • uwsgi_ssl_verify

Quando ocorre uma falha na verificação do certificado, a métrica correspondente à causa é incrementada e a conexão é encerrada. No entanto, observe que o contador básico de handshakes ainda é incrementado, pois essas falhas ocorrem após a conclusão bem-sucedida do handshake.

As métricas de falha na validação de certificados são:

• expired_cert – O par apresentou um certificado expirado
• hostname_mismatch – O certificado do servidor não corresponde ao nome do host (não coletado para conexões com clientes)
• no_cert – O cliente não forneceu um certificado conforme exigido (não coletado para conexões com servidores upstream)
• revoked_cert – A outra parte apresentou um certificado revogado
• other – Contador explícito para outras falhas de verificação de certificado

Exemplo de saída de métricas

Veja um conjunto de exemplos de métricas de TLS para conexões HTTP no nível de todo o 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    }}

Veja um conjunto de exemplos de métricas para conexões entre clientes e o servidor virtual HTTP s9 (conforme mencionado anteriormente, o contador hostname_mismatch não é coletado para essas conexões):

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

Veja a seguir um conjunto de exemplos de métricas para conexões HTTP com servidores no grupo upstream u2 (como mencionado anteriormente, os contadores no_cert e no_common_cipher não são coletados para essas conexões):

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

O painel do NGINX Plus exibe as métricas de TLS estendidas

No NGINX Plus R28 e versões posteriores, o painel de monitoramento de atividades em tempo real exibe as novas métricas de TLS descritas acima. Esta captura de tela mostra as métricas das conexões com clientes. Para visualizar as novas métricas, passe o mouse sobre o valor na coluna SSL > Falhas de handshake conforme mostrado.

Suporte a TLVs do PROXY Protocol v2 em Serviços Privados de Nuvem

Os três principais provedores de nuvem — Amazon Web Services (AWS), Google Cloud Platform (GCP) e Microsoft Azure — oferecem, cada um, um “serviço privado” que permite que clientes externos acessem seus serviços sem expô-los na Internet pública. Cada serviço utiliza um identificador de cliente, representado em um vetor tipo-comprimento-valor (TLV) em um cabeçalho do protocolo PROXY v2. Os identificadores específicos de cada serviço são:

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

Por padrão, esses identificadores de cliente não são repassados aos serviços de backend. O NGINX Plus R28 apresenta módulos para os contextos http e stream – ngx_http_proxy_protocol_vendor_module e ngx_stream_proxy_protocol_vendor_module – que decodificam o TLV e definem uma variável para encaminhar o identificador aos serviços de backend.

Para obter informações gerais sobre como o NGINX Plus usa o protocolo PROXY para obter endereços IP e outras informações sobre os clientes, consulte Aceitação do protocolo PROXY no Guia de Administração do NGINX Plus.

Suporte ao protocolo PROXY v2 para AWS

Na AWS, o endereço IP de origem do tráfego proveniente de clientes por meio de um serviço de endpoint da nuvem privada virtual (VPC) é o endereço IP privado do nó do Network Load Balancer. Se a aplicação de backend precisar dos endereços IP reais e de outros identificadores dos clientes, eles poderão ser obtidos nos cabeçalhos do protocolo PROXY v2.

Na AWS, um vetor TLV personalizado codifica o ID da VPC do endpoint no cabeçalho do PROXY protocol v2 PP2_SUBTYPE_AWS_VPCE_ID. (Para obter mais informações, consulte a documentação da AWS.)

NGINX Plus R28 decodifica o TLV e transmite o ID do endpoint aos aplicativos de backend na variável $proxy_protocol_tlv_aws_vpce_id.

Observação: No bloco server em que você faz referência à variável $proxy_protocol_tlv_aws_vpce_id, também é necessário incluir o parâmetro proxy_protocol na diretiva listen[HTTP][Stream]. Para ver um exemplo, consulte a linha 8 de proxy_protocol_v2.conf logo abaixo.

Este exemplo de configuração para a AWS verifica se o ID da VPC é aceitável e, em caso afirmativo, o transmite ao aplicativo de backend como o segundo parâmetro da diretiva add_header:

Carregando exemplo de código…

Suporte ao PROXY Protocol v2 para o GCP

No GCP Private Service Connect, o endereço IP de origem do tráfego proveniente dos clientes é um “endereço em uma das sub-redes do Private Service Connect na rede VPC do produtor do serviço”. Se a aplicação de backend precisar dos endereços IP reais e de outros identificadores dos clientes, eles poderão ser obtidos nos cabeçalhos do protocolo PROXY v2.

No GCP, um vetor TLV personalizado codifica o ID de conexão exclusivo (naquele momento) no cabeçalho do PROXY protocol v2 pscConnectionId. (Para obter mais informações, consulte a documentação do GCP.)

O NGINX Plus R28 decodifica o TLV e transmite o valor de pscConnectionId aos aplicativos de backend na variável $proxy_protocol_tlv_gcp_conn_id.

Observação: No bloco server em que você faz referência à variável $proxy_protocol_tlv_gcp_conn_id, também é necessário incluir o parâmetro proxy_protocol na diretiva listen[HTTP][Stream]. Para ver um exemplo, consulte a linha 8 do arquivo proxy_protocol_v2.conf acima.

Suporte ao PROXY Protocol v2 para Microsoft Azure

No Microsoft Azure Private Link, o endereço IP de origem do tráfego proveniente dos clientes é o “endereço de rede traduzido (NAT) no lado do provedor de serviços usando o [endereço] IP de NAT alocado da rede virtual do provedor”. Se a aplicação de backend precisar dos endereços IP reais e de outros identificadores dos clientes, eles poderão ser obtidos nos cabeçalhos do PROXY protocol v2.

No Azure, um vetor TLV personalizado codifica o LinkID do cliente no cabeçalho do protocolo PROXY v2 PP2_SUBTYPE_AZURE_PRIVATEENDPOINT_LINKID. (Para obter mais informações, consulte a documentação do Azure.)

NGINX Plus R28 decodifica o TLV e transmite o LinkID aos aplicativos de backend na variável $proxy_protocol_tlv_azure_pel_id.

Observação: No bloco server em que você faz referência à variável $proxy_protocol_tlv_azure_pel_id, também é necessário incluir o parâmetro proxy_protocol na diretiva listen[HTTP][Stream]. Para ver um exemplo, consulte a linha 8 de proxy_protocol_v2.conf acima.

Suporte a variáveis para o parâmetro samesite do cookie de persistência

Nas versões anteriores do NGINX Plus, três valores estáticos (strict, lax e none) eram aceitos para o parâmetro samesite da diretiva sticky cookie. No NGINX Plus R28, o valor também pode ser uma variável.

Por padrão (quando não há o parâmetro samesite), o NGINX não insere o atributo SameSite no cookie. Quando o parâmetro samesite é uma variável, o resultado depende do valor que ela assume em tempo de execução:

• Para um dos valores padrão (strict, lax, ou none) – o NGINX insere o atributo SameSite definido com esse valor
• Para um valor vazio ("") – o NGINX não insere o atributo SameSite attribute
• Para qualquer outro valor, o que indica uma configuração incorreta – o NGINX insere o atributo SameSite definido como Strict (a configuração mais segura)

Esta configuração de exemplo define o atributo samesite com base no valor do cabeçalho HTTP User-Agent (isso é útil para clientes legados que não são compatíveis com o atributo SameSite):

Carregando exemplo de código…

Outras melhorias no NGINX Plus R28

Alterações herdadas do NGINX Open Source

O NGINX Plus R28 é baseado no NGINX Open Source 1.23.2 e herda alterações funcionais e correções de bugs feitas desde o lançamento do NGINX Plus R27 (do NGINX 1.23.0 ao 1.23.2). As alterações e correções de bugs incluem:

• O novo parâmetro ipv4=off da diretiva HTTP resolver desativa a pesquisa de endereços IPv4.
• Quando você habilita um cache compartilhado para informações de sessão HTTP usando o parâmetro shared da diretiva ssl_session_cache, as chaves de tíquetes de sessão TLS passam a ser alternadas automaticamente.
• O nível de gravidade no qual vários tipos de erros de TLS/SSL são registrados foi reduzido de crit para info.

Para conferir a lista completa de novos recursos, alterações e correções de bugs herdados dessas versões, consulte o arquivo CHANGES.

Alterações no módulo JavaScript do NGINX

O NGINX Plus R28 incorpora alterações e correções feitas nas versões 0.7.5 a 0.7.8 do módulo JavaScript do NGINX (njs). Destacamos algumas das mais significativas no artigo Torne sua configuração do NGINX ainda mais modular e reutilizável com o njs 0.7.7 em nosso blog. Para conferir a lista completa, consulte o arquivo Alterações.

Atualize ou experimente o NGINX Plus

Se você estiver usando o NGINX Plus, recomendamos enfaticamente que faça a atualização para o NGINX Plus R28 o mais rápido possível. Você também terá acesso a várias correções e melhorias adicionais, além de facilitar o suporte da NGINX quando precisar abrir um chamado.

Se você ainda não experimentou o NGINX Plus, recomendamos que faça um teste – seja para segurança, balanceamento de carga e gateway de API, seja como um servidor web com suporte completo e APIs avançadas de monitoramento e gerenciamento. Você pode começar hoje mesmo com uma avaliação gratuita de 30 dias.

Sobre o autor

Robert HaynesGerente de Marketing Técnico

Mais publicações de Robert Haynes