Análisis PCAP de tiempo de espera e inactividad de TCP: firewalls, NAT, equilibradores de carga y conexiones de larga duración

---

Las conexiones TCP de larga duración pueden fallar después de minutos u horas de inactividad. Las sesiones SSH se congelan. restablecer las conexiones de la base de datos. Las conexiones WebSocket caen. Las secuencias entrelazadas RTSP TCP se detienen después de períodos de inactividad. Los clientes de API ven una tubería rota. Los usuarios buscan "TCP keepalive pcap", "tiempo de espera de inactividad del firewall", "tiempo de espera de sesión NAT", "restablecimiento de la conexión inactiva del balanceador de carga" y "caídas de conexión TCP de larga duración" porque el error de la aplicación a menudo aparece mucho después de la decisión de tiempo de espera real.

La cirugía PCAP es útil porque las investigaciones de tiempo de inactividad dependen del tiempo. Necesita el último paquete de datos real, cualquier sonda TCP de mantenimiento de actividad, ACK, paquetes FIN/RST y la duración exacta de inactividad.

¿Qué es TCP keepalive?

TCP keepalive es un mecanismo opcional que envía pequeñas sondas en una conexión inactiva para comprobar si el interlocutor aún es accesible. También puede mantener activo el estado de NAT y del firewall si las sondas se realizan con más frecuencia que el tiempo de espera del middlebox.

Pero los impagos suelen ser demasiado lentos para la infraestructura moderna. Un firewall puede expirar en estado inactivo después de 60 segundos, mientras que el mantenimiento de TCP del sistema operativo puede iniciarse mucho más tarde.

Síntomas de tiempo de espera inactivo

Los síntomas comunes incluyen:

• La conexión funciona y luego falla después de un tiempo de inactividad fijo.
• Se restablece la primera solicitud después de la inactividad.
• WebSocket se desconecta después de exactamente 60 segundos.
• El grupo de bases de datos tiene conexiones obsoletas.
• SSH se congela a través de NAT.
• El equilibrador de carga envía RST después del tiempo de espera.
• El cliente envía datos después de estar inactivo y no recibe respuesta.

El momento exacto es la clave.

FIN vs RST vs caída silenciosa

Los middleboxes y los puntos finales pueden cerrar conexiones inactivas de diferentes maneras:

• FIN: cierre elegante.
• RST: cierre abortivo.
• Caída silenciosa: sin paquete; el tráfico posterior se ignora.

Si un firewall cae silenciosamente, ambos puntos finales pueden pensar que la conexión aún existe. El siguiente paquete de datos desencadena retransmisiones o un comportamiento de reinicio.

Evidencia de mantenimiento

En un seguimiento, busque paquetes pequeños durante los períodos de inactividad. Las sondas TCP keepalive suelen utilizar números de secuencia justo antes del siguiente byte esperado. Un analizador puede etiquetarlos como keepalive.

Preguntas:

• ¿Se enviaron keepalives?
• ¿Con qué frecuencia?
• ¿El compañero los RECONOCIÓ?
• ¿Se restableció un middlebox después de un keepalive?
• ¿Las investigaciones comenzaron demasiado tarde?
• ¿La conexión murió antes del intervalo de mantenimiento de actividad?

Equilibradores de carga y proxies

Los balanceadores de carga a menudo imponen tiempos de espera de inactividad. Si el cliente espera que una conexión sobreviva 30 minutos pero el equilibrador de carga cierra las conexiones inactivas después de 60 segundos, la aplicación debe enviar latidos o volver a conectarse.

La evidencia del paquete puede mostrar quién envió el cierre o el reinicio y cuánto tiempo después de los últimos datos.

Checklist

Utilice este flujo de trabajo:

1. Identifique la conexión TCP de larga duración.
2. Marque el último paquete de datos de la aplicación.
3. Mida el tiempo de inactividad antes de fallar.
4. Busque sondas de mantenimiento de actividad de TCP.
5. Compruebe si las sondas están confirmadas.
6. Identifique el remitente FIN o RST.
7. Si no aparece ningún cierre, busque caídas silenciosas y retransmisiones.
8. Compare el tiempo de espera con la configuración del firewall/equilibrador de carga.
9. Preserve el tiempo al recortar.
10. Correlacionar con los latidos de la aplicación.

Diagnóstico final

Las fallas de inactividad de TCP son problemas de sincronización. La evidencia del paquete puede distinguir el cierre del punto final, la caducidad del estado del firewall/NAT, el tiempo de espera del balanceador de carga, la falta de keepalive, el keepalive demasiado lento y la caída silenciosa.

La cirugía PCAP ayuda a preservar el intervalo de inactividad y cerrar/restablecer la evidencia para que las fallas de conexión de larga duración se puedan explicar con precisión.