Como identifico a origem dos problemas de conectividade com meu Network Load Balancer?

Breve descrição

Os problemas de conectividade do Network Load Balancer podem incluir tempos limite de conexão, pacotes de redefinição de TCP (RST) ou falhas de conexão intermitentes. Para identificar a origem do problema, revise suas métricas do Amazon CloudWatch, os logs de fluxo da Amazon Virtual Private Cloud (Amazon VPC), os logs de acesso e as capturas de pacotes.

Resolução

Analise as métricas do CloudWatch para identificar a origem das redefinições de conexão

Abra o console do CloudWatch e revise as seguintes métricas para seu Network Load Balancer:

• ActiveFlowCount
• NewFlowCount
• PortAllocationErrorCount
• SecurityGroupBlockedFlowCount_Inbound_TCP
  Observação: Se você criou o Network Load Balancer sem um grupo de segurança, essa métrica não estará disponível. Em vez disso, use os logs de fluxo da Amazon VPC para identificar conexões rejeitadas.
• TCP_ELB_Reset_Count
• TCP_Client_Reset_Count
• TCP_Target_Reset_Count

Se as métricas de redefinição de TCP mostrarem que as redefinições se originam do lado do cliente ou do destino, o problema não é causado pelo balanceador de carga. Realize as seguintes ações:

• Investigue a aplicação ou o servidor no destino. Revise os logs da aplicação e, em seguida, verifique se ela aceita conexões na porta esperada.
• Verifique a utilização de recursos, incluindo descritores de CPU, memória e arquivos abertos.
• Para redefinições do lado do cliente, revise as configurações de tempo limite da aplicação cliente. Verifique também a configuração do grupo de conexões e o caminho da rede entre o cliente e o Network Load Balancer.

Ativar e analisar os logs de fluxo da Amazon VPC

Para verificar se o tráfego dos clientes chega ao Network Load Balancer e identificar conexões rejeitadas, use os logs de fluxo da Amazon VPC. Para criar logs de fluxo, conclua as seguintes etapas:

1. Abra o console do Amazon Elastic Compute Cloud (Amazon EC2).
2. Navegue até Interfaces de rede e filtre pelo nome do Network Load Balancer.
3. Obtenha as interfaces de rede elásticas (ENIs) do Network Load Balancer.
4. Ative os logs de fluxo da Amazon VPC no Network Load Balancer.
5. Crie um log de fluxo para os ENIs que publica no Amazon CloudWatch Logs, no Amazon Simple Storage Service (Amazon S3) ou no Amazon Data Firehose.
   Em Formato de registro de log, escolha Formato personalizado. Em seguida, escolha os campos de log de fluxo a seguir para capturar informações detalhadas da conexão TCP: account-id, action, bytes, dstaddr, dstport, end, flow-direction, interface-id, log-status, packets, pkt-dstaddr, pkt-srcaddr, protocol, srcaddr, srcport, start, subnet-id, tcp-flags, type, version e vpc-id.

Depois que o log de fluxo coletar dados, verifique os registros com o status REJECT para ver se os grupos de segurança dos logs de controle de acesso à rede (ACLs de rede) bloqueiam o tráfego. Além disso, verifique se o campo tcp-flags mostra os estados da conexão TCP com somente os seguintes valores de máscara de bits:

• SYN, valor 2
• SYN-ACK, valor 18
• FIN, valor 1
• RST, valor 4

Procure registros com sinalizadores RST para identificar se o cliente ou o destino inicia as redefinições de conexão. Em seguida, compare os campos srcaddr e flow-direction para determinar se as redefinições se originam do tráfego do lado do cliente ou do lado do destino.

Para obter mais informações sobre campos disponíveis e valores de sinalizadores TCP, consulte Registros de log de fluxo. Para exemplos de registros que mostram sequências de sinalizadores TCP, consulte Exemplos de registro de log de fluxo.

Use os logs de acesso do Network Load Balancer e os CloudWatch Logs para uma análise detalhada da conexão

O Network Load Balancer fornece opções de registro em log legadas e do CloudWatch para receptores de TLS que complementam os logs de fluxo da Amazon VPC.

Os logs de acesso legados armazenam arquivos de log compactados em um bucket do Amazon S3. Para ativar os logs de acesso legados, consulte Enable access logs for your Network Load Balancer.

A integração de logs do CloudWatch fornece logs de acesso ao CloudWatch Logs, Firehose ou Amazon S3 com o formato Apache Parquet. Para ativar os logs do CloudWatch, consulte CloudWatch logs for your Network Load Balancer.

Observação: Ambas as opções de log estão disponíveis somente para receptores TLS. Para receptores de TCP e UDP, use os logs de fluxo da Amazon VPC e as métricas do CloudWatch.

Para usar os logs de acesso do Network Load Balancer para solucionar problemas, execute as seguintes ações.

Falhas na negociação de TLS

Os campos tls_cipher e tls_protocol_version nos logs de acesso do Network Load Balancer mostram o conjunto de cifras e a versão do TLS. Um valor de "-" nesses campos indica que o handshake TLS falhou antes da conclusão da negociação. Se você observar falhas no handshake, verifique se a política de segurança no receptor TLS oferece suporte às versões TLS e aos conjuntos de cifras de que seus clientes precisam. Para testar quais versões e cifras de TLS o Network Load Balancer aceita, execute o seguinte comando openssl no lado do cliente:

openssl s_client -connect Network Load Balancer_DNS_NAME:443 -tls1_2

Se a conexão falhar, tente diferentes versões de TLS, como -tls1_3, para identificar as versões que o cliente e o Network Load Balancer compartilham. Em seguida, atualize a política de segurança do receptor.

Erros no nível da conexão

O campo tls_handshake_time nos logs de acesso do Network Load Balancer ajuda a identificar problemas de latência do handshake TLS. Se tls_handshake_time for excepcionalmente alto, mas não "-", o handshake TLS foi concluído, mas com lentidão. Um handshake lento pode identificar problemas como atrasos na validação da cadeia de certificados ou lentidão na negociação de TLS do lado do cliente. Se tls_handshake_time exibir "-", o handshake TLS não ocorreu ou falhou. Verifique se o cliente estabeleceu uma conexão TCP e também a configuração do certificado e da política de segurança do receptor.

**Correlação com endereços IP do cliente **

O campo client_port nos logs de acesso do Network Load Balancer ajuda a rastrear conexões específicas do cliente. Filtre os logs por esse campo para determinar se o problema afeta um cliente específico ou todos os clientes. Se o problema afetar somente clientes específicos, investigue o caminho da rede e a configuração de TLS nesses clientes. Se todos os clientes forem afetados, o problema provavelmente está na configuração do receptor do Network Load Balancer ou nos destinos. Faça referência cruzada dos valores de client_port com os logs de fluxo da Amazon VPC e as métricas do CloudWatch.

Com a integração do CloudWatch Logs, use as consultas do CloudWatch Logs Insights para analisar padrões de tráfego em tempo real e criar filtros de métricas para monitoramento.

Para obter mais informações, consulte Access logs for your Network Load Balancer e CloudWatch logs for your Network Load Balancer.

Realizar análise de captura de pacotes

Realize capturas simultâneas de pacotes no cliente e no destino para verificar o comportamento de redefinição da conexão e identificar o lado que está iniciando o encerramento das conexões.

No lado do cliente, execute o seguinte comandotcpdump:

tcpdump -ni any host NLB_IP -w client_capture.pcap

Observação: Substitua NLB_IP pelo endereço IP do seu Network Load Balancer.

Na extremidade de destino, o endereço IP de origem visível para o destino depende se você ativou a preservação do IP do cliente. Se você ativou a preservação do IP do cliente, o destino verá o IP original do cliente.

Para filtrar pelo endereço IP do cliente, execute o seguinte comando tcpdump:

tcpdump -ni any host CLIENT_SOURCE_IP -w target_capture.pcap

Observação: Substitua CLIENT_SOURCE_IP pelo endereço IP do seu cliente.

Se você desativar a preservação do IP do cliente, o destino verá o endereço IP privado do Network Load Balancer.

Para filtrar pelo endereço IP privado de carga de rede do Network Load Balancer, execute o seguinte comando tcpdump:

tcpdump -ni any host NLB_PRIVATE_IP -w target_capture.pcap

Observação: Substitua NLB_PRIVATE_IP pelo endereço IP privado do seu Network Load Balancer.

Para revisar os endereços IP de origem e a direção do fluxo nas capturas para determinar qual lado inicia o encerramento da conexão, execute as seguintes ações:

• Revise os pacotes FIN para ver um encerramento normal da conexão. Verifique qual lado envia o primeiro FIN para identificar qual endpoint encerra a conexão.
• Revise os pacotes RST para ver um encerramento de conexão anormal. Se o destino enviar o RST imediatamente após receber uma solicitação, a aplicação rejeitará a conexão ou travará.
• Analise as retransmissões para identificar os pacotes que estão caindo no caminho da rede entre o cliente e o destino.
• Revise as capturas do lado do cliente que mostram uma solicitação completa, enquanto a captura do lado do destino não mostra nenhuma resposta. Verifique se a aplicação de destino não está respondendo ou se um firewall está bloqueando o tráfego de retorno.
• Compare as capturas do lado do cliente de ambos os lados. Se ambas as capturas mostrarem trocas corretas para os mesmos pacotes, investigue os fatores do lado do destino, como o comportamento da aplicação ou a utilização de recursos. Se as capturas forem diferentes, é provável que o problema esteja no caminho da rede entre os dois pontos de captura.

Informações relacionadas

How do I troubleshoot connections that fail to establish with my Network Load Balancer?

How do I troubleshoot connections that drop or intermittently fail with my Network Load Balancer?

Troubleshoot your Network Load Balancer

Health checks for Network Load Balancer target groups