Analyse PCAP TCP Keepalive et Idle Timeout : pare-feu, NAT, équilibreurs de charge et connexions de longue durée

Les connexions TCP de longue durée peuvent échouer après des minutes ou des heures d'inactivité. Les sessions SSH se bloquent. les connexions à la base de données sont réinitialisées. Les connexions WebSocket sont interrompues. Les flux entrelacés RTSP TCP s'arrêtent après des périodes d'inactivité. Les clients API voient un tuyau cassé. Les utilisateurs recherchent « TCP keepalive pcap », « délai d'inactivité du pare-feu », « délai d'expiration de la session NAT », « réinitialisation de la connexion inactive de l'équilibreur de charge » et « interruptions de connexion TCP de longue durée » car l'erreur d'application apparaît souvent longtemps après la décision d'expiration réelle.

La chirurgie PCAP est utile car les enquêtes sur les délais d'inactivité dépendent du timing. Vous avez besoin du dernier paquet de données réel, de toutes les sondes TCP keepalive, des ACK, des paquets FIN/RST et de la durée d'inactivité exacte.

Qu'est-ce que TCP keepalive

TCP keepalive est un mécanisme facultatif qui envoie de petites sondes sur une connexion inactive pour vérifier si le homologue est toujours joignable. Il peut également maintenir l'état du NAT et du pare-feu en vie si les sondes se produisent plus fréquemment que le délai d'expiration du boîtier de médiation.

Mais les défauts sont souvent trop lents pour les infrastructures modernes. Un pare-feu peut expirer en état d'inactivité après 60 secondes tandis que le système d'exploitation TCP keepalive peut démarrer beaucoup plus tard.

Symptômes d'expiration du délai d'inactivité

Les symptômes courants comprennent :

• La connexion fonctionne, puis échoue après un temps d'inactivité fixe.
• La première demande après la réinitialisation du ralenti.
• WebSocket se déconnecte après exactement 60 secondes.
• Le pool de bases de données comporte des connexions obsolètes.
• SSH se bloque via NAT.
• L'équilibreur de charge envoie RST après l'expiration du délai.
• Le client envoie des données après une période d'inactivité et ne reçoit aucune réponse.

Le timing exact est l’indice.

FIN vs RST vs chute silencieuse

Les middlebox et les points de terminaison peuvent fermer les connexions inactives de différentes manières :

• FIN : clôture gracieuse.
• RST : clôture avortée.
• Dépôt silencieux : pas de paquet ; le trafic ultérieur est ignoré.

Si un pare-feu abandonne silencieusement son état, les deux points de terminaison peuvent penser que la connexion existe toujours. Le prochain paquet de données déclenche des retransmissions ou un comportement de réinitialisation.

Preuves à conserver

Dans une trace, recherchez les petits paquets pendant les périodes d'inactivité. Les sondes TCP keepalive utilisent souvent des numéros de séquence juste avant le prochain octet attendu. Un analyseur peut les étiqueter comme keepalive.

Questions :

• Des keepalives ont-ils été envoyés ?
• À quelle fréquence?
• Le pair les a-t-il ACQUITÉ ?
• Un boîtier de médiation s'est-il réinitialisé après un keepalive ?
• Les sondes ont-elles démarré trop tard ?
• La connexion a-t-elle été interrompue avant l'intervalle de maintien ?

Équilibreurs de charge et proxys

Les équilibreurs de charge imposent souvent des délais d'inactivité. Si le client s'attend à ce qu'une connexion survive 30 minutes mais que l'équilibreur de charge ferme les connexions inactives après 60 secondes, l'application doit envoyer des pulsations ou se reconnecter.

Les preuves par paquets peuvent montrer qui a envoyé la clôture ou la réinitialisation et combien de temps après les dernières données.

Checklist

Utilisez ce flux de travail :

1. Identifiez la connexion TCP de longue durée.
2. Marquez le dernier paquet de données d'application.
3. Mesurez le temps d’inactivité avant une panne.
4. Recherchez les sondes TCP keepalive.
5. Vérifiez si les sondes sont acquittées.
6. Identifiez l’expéditeur FIN ou RST.
7. Si aucune fermeture n’apparaît, recherchez les abandons silencieux et les retransmissions.
8. Comparez le délai d'expiration aux paramètres du pare-feu/de l'équilibreur de charge.
9. Préservez le timing lors de la taille.
10. Corréler avec les battements de cœur de l'application.

Diagnostic final

Les échecs d'inactivité TCP sont des problèmes de synchronisation. La preuve des paquets peut distinguer la fermeture du point de terminaison, l'expiration de l'état du pare-feu/NAT, le délai d'expiration de l'équilibreur de charge, le keepalive manquant, le keepalive trop lent et la suppression silencieuse.

La chirurgie PCAP aide à préserver l’intervalle d’inactivité et à fermer/réinitialiser les preuves afin que les échecs de connexion de longue durée puissent être expliqués avec précision.