TCP Keepalive et pare-feu tuant les sessions inactives

Dans un site client, l'équipe réseau a ajouté un pare-feu entre le client et le serveur. Cela provoque la déconnexion des connexions inactives après environ 40 minutes d'inactivité. Les gens du réseau disent que le pare-feu n'a pas de délai d'expiration de connexion inactive, mais le fait est que les connexions inactives sont rompues.

Afin de contourner ce problème, nous avons d'abord configuré le serveur (une machine Linux) avec les keepalives TCP activés avec tcp_keepalive_time = 300, tcp_keepalive_intvl = 300 et tcp_keepalive_probes = 30000. Cela fonctionne et les connexions restent viables pendant des jours ou plus. Cependant, nous aimerions également que le serveur détecte les clients morts et tue la connexion.Nous avons donc modifié les paramètres en time = 300, intvl = 180, probes = 10, en pensant que si le client était effectivement en vie, le serveur sonderait toutes les 300 secondes. (5 minutes) et le client répondrait avec un ACK et cela empêcherait le pare-feu de voir cela comme une connexion inactive et de le tuer. Si le client était mort, après 10 sondes, le serveur abandonnerait la connexion. À notre grande surprise, les connexions inactives mais vivantes sont tuées après environ 40 minutes comme avant.

Wireshark s'exécutant côté client n'affiche aucune conservation du tout entre le serveur et le client, même lorsque les conservation sont activées sur le serveur.

Que pourrait-il se passer ici?

Si les paramètres keepalive sur le serveur sont time = 300, intvl = 180, probes = 10, je m'attendrais à ce que si le client est vivant mais inactif, le serveur enverrait des sondes keepalive toutes les 300 secondes et laisserait la connexion seule, et si le client est mort, il en enverrait une après 300 secondes, puis 9 autres sondes toutes les 180 secondes avant de couper la connexion. Ai-je raison?

Une possibilité est que le pare-feu intercepte en quelque sorte les sondes keepalive du serveur et ne les transmette pas au client, et le fait qu'il ait obtenu une sonde donne à penser que la connexion est active. Ce comportement est-il courant pour un pare-feu? Nous ne savons pas quel type de pare-feu est impliqué.

Le serveur est un nœud Teradata et la connexion se fait depuis un utilitaire client Teradata vers le serveur de base de données, port 1025 côté serveur, mais nous avons vu le même problème avec une connexion SSH, nous pensons donc qu'il affecte toutes les connexions TCP.

Un pare-feu d'état vérifie les paquets et confirme également si la connexion est active. Je crois que le pare-feu devrait également avoir les paramètres affinés de la même manière que les ordinateurs. Par défaut, de nombreux pare-feu ne maintiennent les connexions inactives ouvertes que pendant 60 minutes, mais cette durée peut changer en fonction du fournisseur.

Certains fournisseurs auront des fonctionnalités telles que TCP Intercept, TCP State Bypass et Dead Connection Detection qui permettront de gérer des situations spéciales comme la vôtre.

Une autre option consiste à configurer le pare-feu lui-même avec les mêmes paramètres que vous avez sur les serveurs pour vous assurer que tout est cohérent.

Sur un pare-feu Cisco, vous disposez de la commande suivante pour le configurer.

nom d'hôte (config) # timeout feature time

timeout conn hh: mm: ss: le temps d'inactivité après lequel une connexion se ferme, entre 0: 5: 0 et 1193: 0: 0. La valeur par défaut est 1 heure (1: 0: 0).

vous avez plusieurs paramètres selon vos besoins.

Je conseillerais de parler avec l'équipe qui gère le pare-feu et d'ajuster les horaires en fonction de vos besoins ou de vérifier les fonctionnalités.