TCP RST e análise PCAP de redefinição de conexão: quem fechou a conexão e por quê
Como analisar TCP RST, redefinição de conexão por peer, redefinição após SYN, redefinição durante TLS, redefinições de firewall, fechamento de aplicativos e evidências de captura de pacotes.
Conexão redefinida por peer é um erro comum em clientes HTTP, bancos de dados, ferramentas TLS, proxies e aplicativos TCP personalizados. Os usuários procuram por "análise TCP RST pcap", "redefinição de conexão por par Wireshark", "RST após SYN", "redefinição de conexão TLS" e "redefinição de TCP de firewall" porque precisam saber quem encerrou a conexão e se a redefinição veio do aplicativo, sistema operacional, firewall, balanceador de carga ou servidor.
Um TCP RST é explícito. Diz "abortar esta conexão". A parte difícil é a atribuição.
A cirurgia PCAP é útil porque as investigações de redefinição precisam de um rastreamento limpo e focado com direção, carimbos de data e hora, números de sequência e pacotes suficientes antes da redefinição.
Padrões de redefinição comuns
RST pode acontecer:
- Imediatamente após SYN.
- Após SYN-ACK.
- Depois de ClientHello.
- Após solicitação HTTP.
- Durante o tempo limite de inatividade.
- Após dados de protocolo inválidos.
- Quando um aplicativo fecha um soquete com dados não lidos.
- Quando um firewall rejeita uma política.
- Quando um balanceador de carga não tem um back-end íntegro.
- Quando um processo do servidor trava ou recusa o estado.
O tempo diz onde procurar.
Quem enviou o RST
Primeiro identifique o IP de origem, a porta de origem, o IP de destino e a porta de destino do pacote de redefinição. Se o IP do servidor enviar RST, o lado do servidor ou algo que represente esse lado o encerrou. Se o IP do cliente enviar RST, o lado do cliente o encerrou. Se o comportamento de TTL, MAC ou caminho sugerir um middlebox, a redefinição poderá ser injetada.
Não confie apenas no texto do aplicativo. "Reset by peer" pode ser reportado pelo lado que recebeu o RST.
Redefinir após SYN
RST após SYN geralmente significa que a porta está fechada ou a política rejeita a conexão. Se SYN receber RST imediatamente, o aplicativo nunca alcançou TLS ou HTTP.
Procurar:
- SYN -> RST,ACK
- Sem servidorOlá
- Nenhum dado do aplicativo
- Comportamento consistente entre tentativas
Isto não é uma falha de certificado ou erro de HTTP; é uma falha de acessibilidade/estado de serviço do TCP.
Redefinir durante TLS
RST após ClientHello pode ser causado por porta errada, TLS não compatível, incompatibilidade de SNI, política de middlebox ou rejeição de servidor. Preserve os metadados DNS e ClientHello para que você possa ver o nome do host, ALPN, versões TLS e tempo.
Se a redefinição chegar após um alerta TLS, o alerta será mais informativo que a redefinição. Se não houver alerta, a redefinição poderá ser de nível inferior ou orientada por políticas.
Redefinir após solicitação
RST após solicitação HTTP, consulta ao banco de dados ou comando de protocolo geralmente significa que o aplicativo é compreendido o suficiente para rejeitar ou travar a solicitação. Também pode significar que um proxy foi fechado porque o upstream não estava disponível.
Correlacionar:
- Últimos bytes do aplicativo enviados.
- Resposta do servidor ou falta de resposta.
- Tempo ocioso antes da reinicialização.
- Logs de back-end/balanceador de carga.
- Se a redefinição ocorre apenas para determinados tamanhos de solicitação.
Checklist
Use este fluxo de trabalho:
- Identifique o primeiro RST na conversa.
- Identifique quem o enviou.
- Inspecione o que aconteceu imediatamente antes.
- Verifique se o handshake TCP foi concluído.
- Verifique se o TLS começou ou foi concluído.
- Verifique se os dados do aplicativo foram enviados.
- Verifique o tempo limite de inatividade.
- Compare as dicas de TTL/MAC/caminho para injeção de middlebox.
- Preservar DNS, TCP, TLS e bytes de aplicativo durante a redefinição.
- Use logs de servidor/balanceador de carga para confirmar a atribuição.
Diagnóstico final
TCP RST é uma interrupção da conexão, mas o motivo depende do tempo e do remetente. Um pcap pode distinguir porta fechada, rejeição de firewall, rejeição de TLS, fechamento de aplicativo, tempo limite de inatividade, falha no balanceador de carga e redefinição de middlebox.
A Cirurgia PCAP ajuda a preservar a sequência de pacotes que responde à pergunta mais importante: quem redefiniu a conexão e o que aconteceu antes dela?