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.
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/>
Bonjour,
Dans l'article <1mh2u1k9thfgo.1voicbqnvweo5.dlg@40tude.net>, 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/>
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/>
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> - Si ya plus moyen de moyenner -+-
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> - Si ya plus moyen de moyenner -+-
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> - Si ya plus moyen de moyenner -+-
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
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.
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
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/>
Bonjour,
Dans l'article <866532pdm9.fsf@srvbsdnanssv.interne.kisoft-
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/>
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/>
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> : C'est cela, oui. -+-
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> : C'est cela, oui. -+-
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> : C'est cela, oui. -+-
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/>
Bonjour,
Dans l'article <ueus8c4ps7tg$.1aaimzwkau6k8.dlg@40tude.net>, 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/>
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/>
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
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 ???
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
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 ? -+-
"jcc" == jcc <jice@pilotoXXXpas 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 ? -+-
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 ? -+-
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/>
Dans l'article <27rpdon3rnc2$.1tgkwpiyic5fa.dlg@40tude.net>, 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/>
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/>
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,
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$.1aaimzwkau6k8.dlg@40tude.net>, 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 ;).
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 ;).