Anunciando o NGINX Plus R28

Temos o prazer de anunciar a disponibilidade do NGINX Plus Release 28 (R28) . Baseado no NGINX Open Source, o NGINX Plus é o único servidor web de software completo , 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 TLS adicionais – O NGINX Plus R28 coleta estatísticas TLS adicionais nos níveis de todo o sistema, do lado do cliente e do lado do servidor, fornecendo insights essenciais ao solucionar problemas relacionados a SSL/TLS na configuração de proxy e para conexões com clientes e servidores upstream.

  O painel de monitoramento de atividades ao vivo do NGINX Plus é atualizado para exibir os novos dados da sessão SSL.

• Suporte para 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, Google Cloud Platform e Microsoft Azure, por padrão, o identificador de cliente específico do serviço representado em um vetor tipo-comprimento-valor (TLV) no cabeçalho do protocolo PROXY v2 não é passado para 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 para serviços de backend.
• Suporte variável para o parâmetro samesite do cookie pegajoso – No NGINX Plus R28 , o valor do parâmetro samesite para a diretiva sticky cookie pode ser uma variável. Essa melhoria permite um gerenciamento mais fácil do tráfego e mais segurança.

Completando o lançamento, estão novos recursos e correções de bugs herdados do NGINX Open Source e atualizações do módulo JavaScript do NGINX.

Mudanças importantes no comportamento

Observação:  Se você estiver atualizando de uma versão diferente do NGINX Plus R27 , não deixe de conferir a seção Mudanças importantes no comportamento nos blogs de anúncios para todas as versões entre a atual e esta.

Mudanças no suporte da plataforma

Novos sistemas operacionais e arquiteturas suportados:

• AlmaLinux 8 e 9 (x86_64, aarch64)
• Alpino 3.17 (x86_64, braço64)
• Oracle Linux 9 (x86_64)
• Rocky Linux 8 e 9 (x86_64, aarch64)

Sistemas operacionais mais antigos removidos:

• Debian 10, que atingiu o fim da vida útil (EOL) em agosto 2022

Sistemas operacionais e arquiteturas mais antigos foram descontinuados e programados para remoção no NGINX Plus R29 :

• Alpine 3.13, que atingiu o EOL em 1º de novembro de 2022

Mudança no tratamento de vários cabeçalhos com nomes idênticos

• A maioria dos cabeçalhos de resposta upstream duplicados conhecidos agora são ignorados com um aviso
• Cabeçalhos Content-Length e Transfer-Encoding duplicados agora são rejeitados, bem como as respostas com cabeçalhos Content-Length ou Transfer-Encoding inválidos, ou se Content-Length e Transfer-Encoding estiverem presentes na resposta.

Novos recursos em detalhes

Métricas TLS adicionais

A observabilidade de eventos e erros de SSL/TLS é importante ao solucionar problemas relacionados a TLS com configuração de proxy, servidores upstream e clientes. Desde a introdução da API NGINX Plus no NGINX Plus R13 , o NGINX Plus coletou três métricas TLS no nível de todo o sistema:

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

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

O NGINX Plus R28 expande o conjunto de métricas TLS com novos contadores para erros de handshake e falhas de validação de certificado nos módulos HTTP e Stream (aqui fornecemos exemplos apenas para módulos HTTP, mas as métricas Stream disponíveis 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 aperto de mão

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 de handshake
• no_common_cipher – Número de falhas de handshake devido à falta de uma cifra comum entre as partes 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 à falta de um protocolo comum entre as partes
• peer_rejected_cert – Número de falhas de handshake devido à outra parte rejeitar o certificado apresentado pelo NGINX Plus e fornecer a mensagem de alerta adequada

Falhas na verificação do certificado

Falhas na verificação de certificado agora são relatadas na nova seção verify_failures da saída da API quando você configura a verificação de certificado:

• Para conexões com clientes com a diretiva ssl_verify_client [ HTTP ][ Stream ]

• Para conexões com servidores com essas diretivas específicas de protocolo:

  • grpc_ssl_verificar
  • proxy_ssl_verify [ HTTP ][ Fluxo ]
  • verificação uwsgi_ssl

Quando ocorre uma falha na verificação do certificado, a métrica para a causa correspondente é incrementada e a conexão é interrompida. Observe, no entanto, que o contador básico de handshakes ainda é incrementado porque essas falhas ocorrem depois que o handshake é bem-sucedido.

As métricas para validação de certificado com falha 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 necessário (não coletado para conexões com servidores upstream)
• revoked_cert – O par apresentou um certificado revogado
• outro – Contador explícito para outras falhas de verificação de certificado

Saída de métricas de amostra

Aqui está um conjunto de métricas TLS de exemplo 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
    }
}

Aqui está um conjunto de métricas de exemplo para conexões entre clientes e o servidor virtual HTTP s9 (conforme observado anteriormente, o contador hostname_mismatch não é coletado para tais 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
        }
    }
    ...
}

Aqui está um conjunto de métricas de exemplo para conexões HTTP com servidores no grupo upstream u2 (conforme observado anteriormente, os contadores no_cert e no_common_cipher não são coletados para tais 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 NGINX Plus exibe as métricas TLS estendidas

Para o NGINX Plus R28 e posteriores, o painel de monitoramento de atividades ao vivo exibe as novas métricas TLS descritas acima. Esta captura de tela mostra métricas para conexões com clientes. Para visualizar as novas métricas, passe o mouse sobre o valor na coluna SSL > Handshakes com falha, conforme mostrado.

Suporte para TLVs do protocolo PROXY v2 em serviços privados na 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” onde você pode permitir que clientes externos acessem seus serviços sem expô-los na Internet pública. Cada serviço faz uso de um identificador de cliente que é representado em um vetor tipo-comprimento-valor (TLV) em um cabeçalho do protocolo PROXY v2. Os identificadores específicos do serviço são:

• AWS PrivateLink – PP2_SUBTYPE_AWS_VPCE_ID
• Conexão de serviço privado do GCP – pscConnectionId
• Link privado do Microsoft Azure – PP2_SUBTYPE_AZURE_PRIVATEENDPOINT_LINKID

Por padrão, esses identificadores de cliente não são passados para 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 para 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 clientes, consulte Aceitando o 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 para o tráfego proveniente de clientes por meio de um serviço de endpoint de Nuvem Privada Virtual (VPC) é o endereço IP privado do nó do Balanceador de Carga de Rede. Se o aplicativo de backend exigir endereços IP reais e outros identificadores para clientes, eles poderão ser obtidos dos cabeçalhos do protocolo PROXY v2.

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

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

Observação:  No bloco do servidor onde você faz referência à variável $proxy_protocol_tlv_aws_vpce_id , você também deve incluir o parâmetro proxy_protocol na diretiva listen [ HTTP ][ Stream ]. Para um exemplo, veja a linha 8 do proxy_protocol_v2.conf logo abaixo.

Esta configuração de exemplo para AWS verifica se o ID da VPC é aceitável e, se for, o passa para o aplicativo de backend como o segundo parâmetro da diretiva add_header :

Suporte ao protocolo PROXY v2 para GCP

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

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

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

Observação:  No bloco do servidor onde você referencia a variável $proxy_protocol_tlv_gcp_conn_id , você também deve incluir o parâmetro proxy_protocol na diretiva listen [ HTTP ][ Stream ]. Para um exemplo, veja a linha 8 do proxy_protocol_v2.conf acima.

Suporte ao protocolo PROXY v2 para Microsoft Azure

No Microsoft Azure Private Link, o endereço IP de origem para o tráfego proveniente de clientes é o “endereço de rede traduzido (NAT) no lado do provedor de serviços usando o IP NAT [endereço] alocado da rede virtual do provedor”. Se o aplicativo de backend exigir endereços IP reais e outros identificadores para clientes, eles poderão ser obtidos dos cabeçalhos do protocolo PROXY 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 .)

O NGINX Plus R28 decodifica o TLV e passa o LinkID para aplicativos de backend na variável $proxy_protocol_tlv_azure_pel_id .

Observação:  No bloco do servidor onde você faz referência à variável $proxy_protocol_tlv_azure_pel_id , você também deve incluir o parâmetro proxy_protocol na diretiva listen [ HTTP ][ Stream ]. Para um exemplo, veja a linha 8 do proxy_protocol_v2.conf acima.

Suporte variável para o parâmetro samesite do cookie pegajoso

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

Por padrão (não há parâmetro samesite ), o NGINX não injeta o atributo SameSite no cookie. Quando o parâmetro samesite é uma variável, o resultado depende de como a variável é resolvida em tempo de execução:

• Para um dos valores padrão ( strict , lax e none ) – NGINX injeta o conjunto de atributos SameSite para esse valor
• Para um valor vazio ( "" ) – NGINX não injeta o atributo SameSite
• Para qualquer outro valor, que indique uma configuração incorreta – o NGINX injeta 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 é bom para clientes legados que não oferecem suporte ao atributo SameSite ):

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 (no NGINX 1.23.0 até 1.23.2). As alterações e correções de bugs incluem:

• O novo parâmetro ipv4=off na diretiva do resolvedor HTTP desabilita a consulta de endereços IPv4.
• Quando você habilita um cache compartilhado para informações de sessão HTTP com o parâmetro shared para a diretiva ssl_session_cache , as chaves de tíquete de sessão TLS agora são rotacionadas automaticamente.
• O nível de gravidade no qual vários tipos de erros TLS/SSL são registrados é reduzido de crit para info .

Para obter 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 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 NGINX JavaScript (njs). Destacamos alguns dos mais significativos em Torne sua configuração NGINX ainda mais modular e reutilizável com o njs 0.7.7 em nosso blog. Para uma lista completa, consulte o arquivo Alterações .

Atualize ou experimente o NGINX Plus

Se você estiver executando o NGINX Plus, recomendamos fortemente que atualize para o NGINX Plus R28 o mais rápido possível. Você também receberá diversas correções e melhorias adicionais, e isso ajudará o NGINX a ajudar você quando precisar abrir um tíquete de suporte.

Se você ainda não experimentou o NGINX Plus, recomendamos que experimente – para segurança, balanceamento de carga e gateway de API, ou como um servidor web totalmente suportado com APIs aprimoradas de monitoramento e gerenciamento. Você pode começar hoje mesmo com um teste gratuito de 30 dias .