Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

perte de session TCP à 10 minutes

17 réponses
Avatar
jcc
Bonjour,

J'ai un problème de perte de sessions TCP sur le protocole TDS
(utilisé par des bases de données comme Sybase) : les sessions sont
systématiquement fermées au bout de 10 minutes d'inactivité, si, *et
seulement si* le flux réseau passe par internet, alors qu'il n'y a pas
de problème de ce genre sur un réseau local ou sur un WAN
d'entreprise.
A 9 minutes 50 secondes d'inactivité les sessions peuvent reprendre,
mais à 10 minutes c'est mort !
De plus le problème se produit avec ou sans utilisation d'ipsec, donc
je suppose que ce n'est pas le protocole TDS lui même qui soit en
cause. Je suppose qu'il existe un paramétrage global chez les FAI pour
tuer les sessions inactives (j'ai fait le test avec easynet et wanadoo
avec le même résultat). Cependant ce serait uniquement sur des
relations port/port bien ciblées car même si je tiens actif d'autres
flux sur l'accès internet (surf, ftp etc) ma session TDS inactive
crève au bout de 10 mn.
Si celà vous dit quelque chose ?
Merci à vous.

--
jcc

10 réponses

1 2
Avatar
Mathieu Goutelle
Bonjour,

Dans l'article , jcc a
écrit:

J'ai un problème de perte de sessions TCP sur le protocole TDS
(utilisé par des bases de données comme Sybase) : les sessions sont
systématiquement fermées au bout de 10 minutes d'inactivité, si, *et
seulement si* le flux réseau passe par internet, alors qu'il n'y a pas
de problème de ce genre sur un réseau local ou sur un WAN
d'entreprise.


Cela pourrait venir d'un firewall (ou d'une passerelle NAT) entre les
deux : la table de connexions maintenue par cet équipement est purgée
des connexions inactives avec un timer de 10 minutes. Tant que des
paquets circulent, le timer est relancé. Mais au delà, la connexion est
filtrée puisque les paquets d'ouverture (SYN, SYN/ACK, etc.) n'ont pas
été vu par le pare-feu : pour lui, la connexion n'a jamais été ouverte
et les paquets de données sont rejetés.

Deux solutions sont possibles. La première n'est pas forcément
souhaitable ni très efficace : augmenter la durée du timer. Ça ne règle
de toute façon pas le problème pour des inactivités de durée plus
longue. La deuxième est d'essayer de trouver un moyen d'envoyer des
paquets périodiquement, des sortes de /keep alive/ (c'est ce que font
certains clients SSH).

Cordialement,
--
Q: Connaissez-vous la différence entre l'ignorance et l'apathie ?
R: J'en sais rien et je m'en fous.
Mathieu Goutelle - <URL:http://webperso.easyconnect.fr/goutelle/&gt;

Avatar
Eric Masson
"Mathieu" == Mathieu Goutelle writes:






Mathieu> Deux solutions sont possibles. La première n'est pas forcément
Mathieu> souhaitable ni très efficace : augmenter la durée du timer. Ça
Mathieu> ne règle de toute façon pas le problème pour des inactivités
Mathieu> de durée plus longue. La deuxième est d'essayer de trouver un
Mathieu> moyen d'envoyer des paquets périodiquement, des sortes de
Mathieu> /keep alive/ (c'est ce que font certains clients SSH).

J'en ajouterais une troisième, utiliser un firewall qui respecte la
sémantique tcp ;)

Éric Masson

--
je vous rappelle qu'il est fréquenté par une moyenne d'âge plus faible
que la moyenne. C'est facile de mettre des lois abscons, qui n'évoluent
pas à la vitesse du net, et de dire "eh ben vous n'aviez qu'à lire"
-+- DP in : <http://www.le-gnu.net&gt; - Si ya plus moyen de moyenner -+-





Avatar
jcc


Deux solutions sont possibles. La première n'est pas forcément
souhaitable ni très efficace : augmenter la durée du timer. Ça ne règle
de toute façon pas le problème pour des inactivités de durée plus
longue. La deuxième est d'essayer de trouver un moyen d'envoyer des
paquets périodiquement, des sortes de /keep alive/ (c'est ce que font
certains clients SSH).


Merci pour ta réponse,
Tes explications et les tests que j'ai faits semblent bien indiquer
cette voie.
Je vais tacher de voir comment augmenter la durée de vie du cache arp
sur le petit firewall Netscreen côté utilisateur. Ce n'est peut-être
pas la solution la plus élégante mais si ça pouvait dépanner ce serait
extra. Une cdt type "set arp age" je suppose.

--
jc

Avatar
Mathieu Goutelle
Bonjour,

Dans l'article
services.com>, Eric Masson a écrit:

J'en ajouterais une troisième, utiliser un firewall qui respecte la
sémantique tcp ;)


Effectivement, 10 min est peut-être un peu court : des sessions ssh
ouvertes sans qu'il ne se passe rien pendant 10 min, j'en ai plein !

Néanmoins, ces timers (ou un mécanisme équivalent) existent toujours :
il faut en effet que cet équipement soit capable de virer de sa table
des connexions qui n'ont pas été fermées correctement. Il serait trop
facile de faire un déni de service en saturant la table de connexions
avec des connexions ouvertes sans jamais les fermer.

Cordialement,
--
Q: Connaissez-vous la différence entre l'ignorance et l'apathie ?
R: J'en sais rien et je m'en fous.
Mathieu Goutelle - <URL:http://webperso.easyconnect.fr/goutelle/&gt;

Avatar
Eric Masson
"Mathieu" == Mathieu Goutelle writes:






Mathieu> Néanmoins, ces timers (ou un mécanisme équivalent) existent
Mathieu> toujours : il faut en effet que cet équipement soit capable de
Mathieu> virer de sa table des connexions qui n'ont pas été fermées
Mathieu> correctement.

Ce que je n'aime pas, c'est que ce soit basé sur des timers. Les deux
outils que j'utilise principalement pf et ipf, te permettent de purger
la table d'état des connections pour lesquelles l'échange initial n'a
pas été complet, mais c'est manuel et amha, c'est mieux ainsi.

Tu purges la table par une action volontaire (tu peux scripter le tout
pour ne le faire que si tu trouves une majorité de connections dont
l'échange initial n'est pas complet).

Ce scénario ne resiste pas à un attaquant qui dispose d'un outil lui
permettant de compléter les échanges d'établissement de session, c'est
certain, mais cela permet d'éviter de poser problème à des applications
générant un trafic tout à fait légitime.

Après, c'est amha une question de sensibilité de l'admin...

Mathieu> Il serait trop facile de faire un déni de service en saturant
Mathieu> la table de connexions avec des connexions ouvertes sans
Mathieu> jamais les fermer.

Pour un dos, tu as plus vite fait de saturer le lien utilisé par la
cible en utilisant le paquet de zombies trojanés disponibles, non ?

Éric Masson

--
il y a quatre mots dans votre phrase et si vous ne décelez pas les
conséquences rhétoriques de vos propres paroles, c'est facheux et vous
conduira sans doute à d'autres difficultés d'ordre communicationnelles!
-+- PG in <http://www.le-gnu.net&gt; : C'est cela, oui. -+-





Avatar
Mathieu Goutelle
Bonjour,

Dans l'article <ueus8c4ps7tg$, jcc a
écrit:
Je vais tacher de voir comment augmenter la durée de vie du cache arp
sur le petit firewall Netscreen côté utilisateur. Ce n'est peut-être
pas la solution la plus élégante mais si ça pouvait dépanner ce serait
extra. Une cdt type "set arp age" je suppose.


Ce n'est pas une problème de cache arp, mais d'expiration de la
connexion au niveau d'un équipement de niveau supérieur (pare-feu ou
passerelle NAT) qui doit se trouver entre les deux machines. Relis ma
réponse calmement ;).

Cordialement,
--
Q: Connaissez-vous la différence entre l'ignorance et l'apathie ?
R: J'en sais rien et je m'en fous.
Mathieu Goutelle - <URL:http://webperso.easyconnect.fr/goutelle/&gt;

Avatar
jcc

Ce n'est pas une problème de cache arp, mais d'expiration de la
connexion au niveau d'un équipement de niveau supérieur (pare-feu ou
passerelle NAT) qui doit se trouver entre les deux machines. Relis ma
réponse calmement ;).


je suis calme :)
Entre le poste et la ressource distante il y a effectivement un couple
de firewall pour de l'ipsec.
Mais si arp n'est pas la solution (pourtant c'est justement 10 minutes
de durée de vie dans les tables du firewall pour les sessions
inactives, ça m'aurait arrangé:) , sur quoi intervenir pour allonger
le délai de connexion ???

--
jc

Avatar
Eric Masson
"jcc" == jcc de spamXXXrama.net> writes:






'Lut,

jcc> sur quoi intervenir pour allonger le délai de connexion ???

Tu devrais trouver dans l'interface de paramétrage un truc du genre "tcp
session timeout"

Éric Masson

--
SP> Ah désolé, mais alors là Tristant il a bu le filtre
Non, le philtre. C'est pas pareil. Je te renvoie à fr.sci.filo
pour que tu conçoives la diphérence.
-+- TP in Guide du neuneu sur Usenet - C'est phou, non ? -+-





Avatar
Mathieu Goutelle
Dans l'article <27rpdon3rnc2$, jcc a
écrit:
Entre le poste et la ressource distante il y a effectivement un couple
de firewall pour de l'ipsec.
Mais si arp n'est pas la solution (pourtant c'est justement 10 minutes
de durée de vie dans les tables du firewall pour les sessions
inactives, ça m'aurait arrangé:) , sur quoi intervenir pour allonger
le délai de connexion ???


Arp n'est pas la solution parce qu'ARP n'a rien à voir là dedans. Le
fait que tu es trouvé une durée de vie de 10 min dans les tables du
firewall montre que le problème a des chances de se trouver là et qu'il
faut peut-être augmenter cette durée (même si ça ne fera que repousser
le problème), mais ça n'a toujours rien à voir avec ARP.

Cordialement,
--
Q: Connaissez-vous la différence entre l'ignorance et l'apathie ?
R: J'en sais rien et je m'en fous.
Mathieu Goutelle - <URL:http://webperso.easyconnect.fr/goutelle/&gt;

Avatar
fleuryar
Bonsoir,


De façon parallèle, j'ai été confrontée à un problème assez insoluble
pour moi en apparence. L'enjeu, à la base était simple : partager un
accès Internet depuis un WLAN. Or, le routeur/point d'accès
WiFi/Passerelle NAT sur lequel je n'ai, pour des raisons politiques, pas
la main, me demande une clé WAP ; tant que le protocole est activé,
impossible d'atteindre la passerelle (toujours ce même équipement
multifonctions donc super-opaque), par contre, sans WEP, pas de
problème. J'ai quelque peu décroché au niveau technique et je ne connais
rien à WEP, mais par contre, je suis absolument certaine de ma
configuration IP et de mes compétences en routage.

Serait-il possible que la session TCP soit rendue impossible à maintenir
à cause de ce protocole WEP ou bien par la façon dont le constructeur a
implémenté NAT sur son équipement, sachant que la qualité de
transmission sur mon réseau local radio est déplorable (interférence,
notamment) ? Je n'ai malheureusement pas l'environnement ad hoc pour
tester convenablement la qualité du réseau. JE dois me contenter
d'hypothèses...

A.

Bonjour,

Dans l'article <ueus8c4ps7tg$, jcc a
écrit:

Je vais tacher de voir comment augmenter la durée de vie du cache arp
sur le petit firewall Netscreen côté utilisateur. Ce n'est peut-être
pas la solution la plus élégante mais si ça pouvait dépanner ce serait
extra. Une cdt type "set arp age" je suppose.



Ce n'est pas une problème de cache arp, mais d'expiration de la
connexion au niveau d'un équipement de niveau supérieur (pare-feu ou
passerelle NAT) qui doit se trouver entre les deux machines. Relis ma
réponse calmement ;).

Cordialement,



1 2