Análise TCP Keepalive e Idle Timeout PCAP: Firewalls, NAT, balanceadores de carga e conexões de longa duração
Como analisar pacotes de manutenção de atividade TCP, tempo limite de inatividade, expiração de sessão NAT, quedas de conexão de firewall, redefinições de balanceador de carga, conexões de API de longa duração e evidências de captura de pacotes.
Conexões TCP de longa duração podem falhar após minutos ou horas de inatividade. As sessões SSH congelam. conexões de banco de dados redefinidas. As conexões WebSocket caem. Os fluxos intercalados RTSP TCP param após períodos ociosos. Os clientes da API veem um cano quebrado. Os usuários procuram por "TCP keepalive pcap", "tempo limite de inatividade do firewall", "tempo limite de sessão NAT", "conexão inativa de redefinição do balanceador de carga" e "quedas de conexão TCP de longa duração" porque o erro do aplicativo geralmente aparece muito depois da decisão de tempo limite real.
A cirurgia PCAP é útil porque as investigações do tempo limite de inatividade dependem do tempo. Você precisa do último pacote de dados real, de quaisquer testes de manutenção de atividade TCP, ACKs, pacotes FIN/RST e da duração exata da inatividade.
O que é manutenção de atividade TCP
Keepalive TCP é um mecanismo opcional que envia pequenas sondagens em uma conexão ociosa para verificar se o par ainda está acessível. Ele também pode manter o estado do NAT e do firewall ativo se as investigações ocorrerem com mais frequência do que o tempo limite do middlebox.
Mas os padrões são muitas vezes demasiado lentos para as infra-estruturas modernas. Um firewall pode expirar no estado inativo após 60 segundos, enquanto o keepalive do TCP do sistema operacional pode iniciar muito mais tarde.
Sintomas de tempo limite ocioso
Os sintomas comuns incluem:
- A conexão funciona e falha após um tempo de inatividade fixo.
- A primeira solicitação após a inatividade é redefinida.
- O WebSocket se desconecta após exatamente 60 segundos.
- O pool de bancos de dados possui conexões obsoletas.
- SSH congela através do NAT.
- O balanceador de carga envia RST após o tempo limite.
- O cliente envia dados após inatividade e não recebe resposta.
O momento exato é a pista.
FIN vs RST vs queda silenciosa
Middleboxes e endpoints podem fechar conexões ociosas de diferentes maneiras:
- FIN: fechamento gracioso.
- RST: fechamento abortivo.
- Queda silenciosa: sem pacote; o tráfego posterior é ignorado.
Se um firewall cair silenciosamente, ambos os endpoints poderão pensar que a conexão ainda existe. O próximo pacote de dados aciona retransmissões ou comportamento de redefinição.
Evidência de manutenção
Em um rastreamento, procure pacotes pequenos durante períodos inativos. As sondagens de manutenção de atividade TCP geralmente usam números de sequência logo antes do próximo byte esperado. Um analisador pode rotulá-los como keepalive.
Questões:
- Os keepalives foram enviados?
- Com que frequência?
- O par os reconheceu?
- Uma middlebox foi redefinida após um keepalive?
- As sondagens começaram tarde demais?
- A conexão morreu antes do intervalo de manutenção de atividade?
Balanceadores de carga e proxies
Os balanceadores de carga geralmente impõem tempos limite de inatividade. Se o cliente espera que uma conexão sobreviva por 30 minutos, mas o balanceador de carga fecha conexões inativas após 60 segundos, o aplicativo deverá enviar pulsações ou reconectar-se.
A evidência do pacote pode mostrar quem enviou o fechamento ou redefinição e quanto tempo depois dos últimos dados.
Checklist
Use este fluxo de trabalho:
- Identifique a conexão TCP de longa duração.
- Marque o último pacote de dados do aplicativo.
- Meça o tempo ocioso antes da falha.
- Procure testes de manutenção de atividade TCP.
- Verifique se as sondas foram reconhecidas.
- Identifique o remetente FIN ou RST.
- Se nenhum fechamento aparecer, procure por queda silenciosa e retransmissões.
- Compare o tempo limite com as configurações do firewall/balanceador de carga.
- Preservar o tempo ao aparar.
- Correlacione com pulsações do aplicativo.
Diagnóstico final
Falhas de inatividade de TCP são problemas de tempo. A evidência do pacote pode distinguir o fechamento do endpoint, a expiração do estado do firewall/NAT, o tempo limite do balanceador de carga, a falta de manutenção de atividade, a manutenção de atividade muito lenta e a queda silenciosa.
A cirurgia PCAP ajuda a preservar o intervalo ocioso e as evidências de fechamento/redefinição para que falhas de conexão de longa duração possam ser explicadas com precisão.