Le délai d'expiration de la connexion TCP est un paramètre du pare-feu SonicWall qui reçoit souvent peu d'attention lors du fonctionnement normal. Cependant, des valeurs de délai d'expiration inutilement élevées ou qui ne sont plus requises peuvent avoir des effets inattendus sur le fonctionnement du pare-feu.
Un pare-feu doit conserver des informations sur chaque connexion TCP active dans sa table de connexions. Le délai d'expiration de connexion TCP détermine combien de temps une connexion TCP inactive est conservée avant que le pare-feu ne la supprime de la table.
Un pare-feu SonicWall dispose d'un délai d'expiration global des connexions TCP. De plus, un délai d'expiration individuel peut être configuré pour des règles de pare-feu spécifiques.
Un tel ajustement peut être utile. Certaines applications ou connexions de longue durée peuvent nécessiter un délai d'attente plus élevé. Cependant, des problèmes peuvent survenir lorsque les valeurs de délai d'attente sont définies inutilement élevées ou lorsqu'un changement temporaire effectué pour le dépannage n'est pas réinitialisé par la suite.
Plus les connexions inactives restent dans la table des connexions, plus le pare-feu doit continuer à gérer ces sessions. Par conséquent, en particulier sur les systèmes fortement sollicités, des valeurs de délai d'attente inutilement élevées peuvent augmenter le nombre de connexions qui doivent être gérées simultanément.
Les modifications apportées au délai d'inactivité global des connexions TCP nécessitent une attention particulière car elles affectent bien plus qu'une simple règle de pare-feu.
Un exemple concret illustre les conséquences potentielles : chez un client disposant d'un cluster haute disponibilité SonicWall, le basculement de la haute disponibilité a pris beaucoup plus de temps que prévu. L'analyse a révélé que le délai d'inactivité des connexions TCP globales avait été augmenté auparavant, ce qui a entraîné la conservation d'un grand nombre de connexions pendant plus longtemps.
Un changement initialement effectué dans un autre but a ensuite affecté un domaine totalement différent du fonctionnement du pare-feu.
Les configurations de pare-feu qui ont évolué au fil de nombreuses années contiennent souvent des paramètres dont le but initial n'est plus connu.
Un exemple typique de dépannage est :
Une valeur de délai d'attente est augmentée pour enquêter sur un problème de connexion particulier ou le résoudre. Le problème est ensuite résolu et l'application fonctionne à nouveau, mais le paramètre modifié reste en place.
Des mois ou des années plus tard, il peut ne plus être possible de déterminer pourquoi la valeur a été modifiée à l'origine.
Il est donc conseillé de réviser régulièrement à la fois le délai d'attente global de la connexion TCP et les paramètres de délai d'attente individuels configurés pour des règles de pare-feu spécifiques.
Firewall Toolbox analyse le délai d'expiration des connexions TCP configuré globalement ainsi que les paramètres des règles de pare-feu individuelles.
Les règles avec un délai d'attente TCP individuel sont automatiquement identifiées et présentées clairement dans un rapport. Cela permet de déterminer facilement :
Cela permet d'examiner efficacement les paramètres inhabituels ou ceux qui ne sont peut-être plus nécessaires.
Firewall Toolbox n'est pas limité à l'analyse.
Lorsqu'une connexion API au pare-feu SonicWall est disponible, les règles identifiées peuvent être modifiées directement depuis Firewall Toolbox.
Vous pouvez sélectionner précisément les règles à modifier. Des paramètres de délai d'attente TCP identifiés, qu'ils soient individuels, multiples ou tous, peuvent être sélectionnés et réinitialisés à la valeur par défaut via l'API SonicWall.
De cette façon, Firewall Toolbox combine trois tâches pour la gestion des délais d'attente TCP :
Identifier – Documenter – Corriger
Cela permet de consulter plus facilement les anciennes configurations de pare-feu qui ont évolué au fil du temps et de supprimer les paramètres de délai d'attente TCP individuels qui ne sont plus nécessaires.
