Bonsoir,
désolé pour le titre peu explicite, voici de quoi il retourne :
je suis chez free non dégroupé, et comme de nombreuses
lecteurs j'ai constaté des problèmes pour maintenir des
connexions, notamment en soirée.
Or, ce soir, j'avais besoin de tirer un tunnel via un ssh, et bien
entendu le ssh se cassait la figure toutes les 3 minutes... jusqu'au
moment ou dans la session ssh j'ai lancé un 'top'. Depuis, plus
de déconnexion.
Alors, lien de cause à effet ou simple coïncidence ?
Quelqu'un pourrait tenter la même expérience et nous
dire ce que ça donne ?
(oh, le dico de linuxfr.org ne connait même pas ssh, si c'est
pas une honte ça !)
Journal [free non degrp] déco si idle en tcp ?!?
28
sept.
2006
# man ssh_config
Posté par Mouns (site web personnel) . Évalué à 2.
[^] # Re: man ssh_config : ah oui mais non !
Posté par fasthm . Évalué à 3.
Merci, je connais un peu les keepalive, ce qui m'intéresse dans le
cas présent c'est que mes 2 noeuds (client et serveur) vont très bien(*),
mais que la présence de traffic en permanence sur la session ferait
que les noeuds intermédiaires (routeurs, filtres ou autres firewalls -- je
laisse le soin d'en débattre aux victimes de free) ne coupent plus la
connexion.
Un peu comme si, me faisait-on remarquer tout à l'heure, on avait un
conntrack sous-dimensionné qui perdrait les connexions utilisées
depuis trop longtemps.
(*) Car si je ne m'abuse, le keep alive ne concerne que le client et son
serveur lorsqu'ils tentent de maintenir une connexion contre vents et
marées, et pas les routeurs. Si je m'abuse, n'hésitez pas à m'insulter
copieusement.
La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".
[^] # Re: man ssh_config : ah oui mais non !
Posté par fasthm . Évalué à 2.
Un peu comme si, me faisait-on remarquer tout à l'heure, on avait un
conntrack sous-dimensionné qui perdrait les connexions pas utilisées
depuis trop longtemps (celles dans lesquelles ne passe qu'un
keepalive de temps en temps).
La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".
[^] # Re: man ssh_config
Posté par fasthm . Évalué à 3.
ssh que j'avais ouvert pour bosser et que j'ai trop longtemps
délaissé s'est fait couper la chique, alors que l'autre, sur le même
serveur, continue, fringant, à afficher son 'top'.
On peut multiplexer plusieurs sessions ssh sur une seule connexion
je crois... mais je suis sur putty sur un windows.
La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".
[^] # Re: man ssh_config
Posté par M . Évalué à 3.
je crois... mais je suis sur putty sur un windows.
Ben tu redirige un port bidon sur lequel tu fais passé du traffic bindon.
[^] # Re: man ssh_config
Posté par Nicolas Bourdais (Mastodon) . Évalué à 1.
Ça te permettra d'avoir deux consoles à travers ton ssh. Tu lances top sur une, et tu travailles sur l'autre.
Ctrl+a, c pour créer une console une fois screen lancé.
Ctrl+a, p pour la console précédente
Ctrl+a, n pour la suivante.
[^] # Re: man ssh_config
Posté par fasthm . Évalué à 2.
La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".
[^] # Re: man ssh_config
Posté par Sébastien Koechlin . Évalué à 6.
caption always "%{=b wK}%-w%{=b rY}%n %t%{-}%+w %=%{= wB}%c%{-} "
Screen affiche entre autre l'heure en bas, mis à jour toutes les minutes; comme ça ça génère du traffic.
La lecture du manuel ne fait pas de mal; pour changer les couleurs en particulier.
# NAT chez l'utilisateur ?
Posté par Guillaume G. . Évalué à 3.
Tout ceci ressemble quand même très fort à un problème de saturation et/ou d'expiration d'entrées dans une table de NAT. Le client ssh en question n'est-il pas derrière un NAT ? (C'est une Freebox ?) Le NAT en question n'est-il pas surchargé par une machine située derrière qui ouvrirait plein de connexions TCP ? (Typiquement, un client P2P ?) Le comportement du NAT serait alors de purger les entrées sans trafic depuis le plus longtemps, et une entrée correspondant à une session ssh inactive répond assez bien à ce critère...
Sinon, il serait intéressant de faire tourner une capture de chaque côté de la session TCP pour voir s'il y a des envois et/ou des réceptions de paquets RST et comprendre ce qu'il se passe exactement en termes techniques quand « le ssh se casse la figure ».
[^] # Re: NAT chez l'utilisateur ?
Posté par fasthm . Évalué à 2.
sur l'unique machine derrière ma fbx (en routage, et donc nat), que :
- 2 ssh (dont 1 qui passe 4 tunnels : imap, smtp et 2 web),
- 1 firefox,
- 1 thunderbird.
A tout casser, j'avais une vingtaine de connexions tcp sortantes, en
comptant les CLOSE_WAIT. Je suppose que ma machine ne sert pas
de nid à spammer ou autre cochonnerie... enfin j'espère :-)
D'où l'idée que c'est peut être un équipement sur le réseau de free
qui a ce comportement.
La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".
# un peu le meme probleme
Posté par Marc Quinton . Évalué à 1.
Si j'ai un flux TCP ouvert, je n'ai plus ce timeout. Ce qui pourrait signifier que c'est plutot SSH(d) qui serait en cause. Mais j'ai positionné le fameux TCPKeepAlive.
Est-ce qu'il y aurait une variable coté client qui serait forcée et pour laquelle en tant que non administrateur je ne pourrais pas changer sa valeur ?
Restons dans le domaine SSH. J'ai une configuration ou je n'arrive pas a transmettre le display X. Alors que pour les autres machines distantes cela se gere completement automatiquement.
# Exactement le meme problème
Posté par Dario Spagnolo (site web personnel) . Évalué à 3.
J'ai d'ailleurs arreté de mettre en doute mon serveur lorsque je me suis aperçu qu'avec un top en marche, la connexion ne se coupait plus. Tout comme toi donc.
Le seul indice que j'ai en plus, c'est que c'est peut-etre du aux fonctionnalités routeur de la freebox car j'ai commencé à constater le problème quand j'ai eliminé la machine linux qui me servait de routeur et que j'ai commencé à utiliser la freebox elle meme en mode routeur.
Il faudrait que j'essaye avec un autre modem-routeur pour en etre sur.
--
Dario
[^] # Re: Exactement le meme problème
Posté par Miguel Moquillon (site web personnel) . Évalué à 2.
En effet, je dispose d'un vieux modem routeur ADSL (SpeedTouch Pro), et j'ai essayé avec ce dernier. Je n'ai jamais eu de coupure avec. Par contre, dès que je l'ai remplacé par la Freebox (V4 comme toi et en non dégroupé), j'ai eu droit à nouveau aux coupures !
[^] # Re: Exactement le meme problème
Posté par fasthm . Évalué à 2.
Ça signifierait que l'on peut résoudre plus ou moins le truc en
repassant la freebox en pont et en gérant le NAT sur une autre
machine.
Je vais essayer ça dans quelques jours alors.
La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".
[^] # Re: Exactement le meme problème
Posté par jms . Évalué à 1.
- la nat qui pose problème est en sortie (masquerade)
- je n'utilise pas (en ce moment) la freebox (simple boitier soekris avec modem adsl ethernet)
- pas de problème de mon point de vue (depuis l'intérieur ou avec les nats entrant)
alors ?
c'est grave docteur ?
ps: j'ai pas encore investigué
# ClientAliveInterval, ClientAliveCountMax, ...
Posté par andeus . Évalué à 3.
ClientAliveInterval 60
ClientAliveCountMax 1440
# Client SSH ?
Posté par Olivier (site web personnel) . Évalué à 3.
qu'est-ce que tu utilises comme client SSH ? Personnellement, j'utilise de temps en temps un client SSH cygwin à travers un tunnel SSH (proxytunnel), et l'option "ProtocolKeepAlives" ne marche pas sous Cygwin.
C'est assez clairement indiqué dans le man de SSH Cygwin. L'option à utiliser est "ServerAliveInterval"
J'ai donc mis dans le ~/.ssh/config" de mon cygwin l'option suivante :
ServerAliveInterval 90
(90 = 90 secondes)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.