Análisis PCAP de restablecimiento de conexión y TCP RST: quién cerró la conexión y por qué
Cómo analizar TCP RST, restablecimiento de conexión por igual, restablecimiento después de SYN, restablecimiento durante TLS, restablecimiento de firewall, cierre de aplicaciones y evidencia de captura de paquetes.
El "restablecimiento de conexión por parte del par" es un error común en clientes HTTP, bases de datos, herramientas TLS, servidores proxy y aplicaciones TCP personalizadas. Los usuarios buscan "análisis TCP RST pcap", "restablecimiento de conexión por parte de Wireshark", "RST después de SYN", "restablecimiento de conexión TLS" y "restablecimiento de firewall TCP" porque necesitan saber quién finalizó la conexión y si el reinicio provino de la aplicación, el sistema operativo, el firewall, el equilibrador de carga o el servidor.
Un TCP RST es explícito. Dice "anular esta conexión". La parte difícil es la atribución.
La cirugía PCAP es útil porque las investigaciones de reinicio necesitan un seguimiento limpio y enfocado con dirección, marcas de tiempo, números de secuencia y suficientes paquetes antes del reinicio.
Patrones de reinicio comunes
La RST puede ocurrir:
- Inmediatamente después de SYN.
- Después de SYN-ACK.
- Después ClienteHola.
- Después de la solicitud HTTP.
- Durante el tiempo de inactividad.
- Después de datos de protocolo no válidos.
- Cuando una aplicación cierra un socket con datos no leídos.
- Cuando un firewall rechaza una política.
- Cuando un balanceador de carga no tiene un backend saludable.
- Cuando un proceso del servidor falla o rechaza el estado.
El momento te dice dónde mirar.
¿Quién envió el RST?
Primero identifique la IP de origen, el puerto de origen, la IP de destino y el puerto de destino del paquete de reinicio. Si la IP del servidor envía RST, el lado del servidor o algo que se hace pasar por ese lado lo finalizó. Si la IP del cliente envía RST, el lado del cliente lo finalizó. Si el comportamiento de TTL, MAC o ruta sugiere un middlebox, se puede inyectar el reinicio.
No confíe únicamente en la redacción de la solicitud. La parte que recibió el RST puede informar "Restablecer por igual".
Restablecer después de SYN
RST después de SYN a menudo significa que el puerto está cerrado o que la política rechaza la conexión. Si SYN recibe RST inmediatamente, la aplicación nunca alcanzó TLS o HTTP.
Buscar:
- SINC -> PRIMERA, ACK
- Sin servidorHola
- Sin datos de la aplicación
- Comportamiento consistente entre intentos
Esto no es una falla del certificado ni un error HTTP; es una falla de estado de servicio/accesibilidad de TCP.
Restablecer durante TLS
RST después de ClientHello puede deberse a un puerto incorrecto, TLS no compatible, falta de coincidencia de SNI, política de middlebox o rechazo del servidor. Conserve los metadatos de DNS y ClientHello para que pueda ver el nombre de host, las versiones de ALPN, TLS y la sincronización.
Si el reinicio llega después de una alerta TLS, la alerta es más informativa que el reinicio. Si no hay ninguna alerta, el restablecimiento puede ser de nivel inferior o impulsado por políticas.
Restablecer después de la solicitud
RST después de una solicitud HTTP, una consulta de base de datos o un comando de protocolo a menudo significa que la aplicación entendió lo suficiente como para rechazar o bloquear la solicitud. También puede significar que un proxy se cerró porque el flujo ascendente no estaba disponible.
Correlación:
- Últimos bytes de aplicación enviados.
- Respuesta del servidor o falta de respuesta.
- Tiempo de inactividad antes del reinicio.
- Registros de backend/equilibrador de carga.
- Si el restablecimiento ocurre solo para ciertos tamaños de solicitud.
Checklist
Utilice este flujo de trabajo:
- Identifique el primer RST de la conversación.
- Identify who sent it.
- Inspeccione lo que sucedió inmediatamente antes.
- Compruebe si se completó el protocolo de enlace TCP.
- Compruebe si TLS comenzó o se completó.
- Compruebe si se enviaron los datos de la solicitud.
- Verifique el tiempo de espera de inactividad.
- Compare pistas TTL/MAC/ruta para la inyección de middlebox.
- Conserve DNS, TCP, TLS y bytes de aplicaciones durante el reinicio.
- Utilice registros del servidor/equilibrador de carga para confirmar la atribución.
Diagnóstico final
TCP RST es una interrupción de la conexión, pero el motivo depende del tiempo y del remitente. Un pcap puede distinguir puerto cerrado, rechazo de firewall, rechazo de TLS, cierre de aplicación, tiempo de espera de inactividad, falla del balanceador de carga y reinicio del middlebox.
La cirugía PCAP ayuda a preservar la secuencia de paquetes que responde a la pregunta más importante: ¿quién restableció la conexión y qué sucedió justo antes?