Bonjour à tous.
 
Dans le cadre de mon taff, j'ai mis en place un montage automatique de tunnels SSH entre plusieurs machines.
 
La machine du client initie la connexion vers mon serveur public, avec un peu de RemoteForward pour les redirections 22 et 3389.  
 
De temps à autre, il doit y avoir des coupures du lien etre mes clients et moi, et la connexion se coupe.
Le processus SSH est toujours en exécution du côté client, aussi mon script de test ne le relance pas (car déjà existant).
 
J'aimerais avoir une solution pour tester si le tunnel est toujours ouvert, et l'automatiser.
 
J'avais songé à récupérer les PID des différentes connexions en LISTENING sur mon serveur, de comparer avec les PID des process ssh sur le serveur...
Mais en fait il me semble (car le problème ne s'est pas reproduit depuis un long moment et je ne peux pas le reproduire manuellement) que lors d'une coupure, le process SSH disparait également sur le serveur.
 
Sur mon client j'ai une connexion ESTABLISHED unique vers mon serveur public, associée au PID du script SSH.  
(tiens en passant, je me demande si cette connexion ne passerait pas en LISTENING ou TIME_WAIT si la coupure de connexion se reproduisait... a tester quand cela se reproduira).
 
Si vous avez quelques idées de pistes à creuser, je suis demandeur !

tu peux pas intergrer un bëte "ssh machinedistante date " pour tester la com entre tes deux machines ?  
si OK, on touche à rien, si KO , tu kill ton tunnel et tu le relances?  

Ca va pas relancer le tunnel tout simplement de faire ça ?
Ca va le relancer le temps de la commande date...
 
Les certifs ont été échangés donc le tunnel monte en deux deux.
Si je teste "ssh monserveurdistant date", il va me monter le tunnel (un nouveau tunnel donc) et ne va pas vérifier le bon établissement des premiers liens.

j'ai un peu de mal à visulaiser ton archi et ton montage de tunnel ...
Qu'appelle tu un tunnel SSH ? et comment est il monté/appellé ? il n'est pas persistant ? il monte lors de la sollicitation d'une com entre les deux serveurs ?
 
Tunnel ssh crypté ?
 
edit : pour le test :  
 lsof -i tcp | grep "^ssh" | grep ESTABLISHED

Merci pour la commande, je regarde ça au prochain crash de la liaison.
 
En fait mon SSH est monté via un script, tout bêtement, en cron.  
Il est persistant, et c'est bien là le souci.  
Lorsque j'ai une coupure, le process ssh reste sur la machine cliente, tout va bien pour elle. La liaison est elle, dans les choux complètement.
 
Faut que je regarde à la prochaine coupure.
 
Merci

je pense qu'effectivement, tu dois pouvoir jouer sur le ESTABLISHED pour faire ton check. il faudrait vérifier, si lors du crash de ton tunnel tu est toujours en paire "ESTABLISHED"  
si t'as un environnement de test, tu peux jetter un oeil la dessus  
http://www.harding.motd.ca/autossh/

Essaye

 
Déjà mise en place comme option, directement dans les fichiers de conf pour cette connexion

Et ça ne coupe pas la connexion automatiquement ?

La connexion oui. Le serveur coupe bien, il n'y a plus de traces.

Le process SSH sur le client tourne toujours lui.

Mon script automatique recherche ce process et relance le tunnel si le process n'est pas existant.
En l'occurence il existe, donc le tunnel n'est pas relancé.
La connexion est coupée, mais le script n'en sait rien et ne relance rien.

Je testerai la méthode avec les ESTABLISHED

C'est pas normal. Tu as activé l'option côté client ou côté serveur ?
 
Par défaut, si on active le ServerAliveInterval, le client attend 3 keepalives (réglable par le paramètre ServerAliveCountMax) avant de considérer la connexion comme dead et terminer le process.
 
Peux-tu donner la ligne de commande complète qui te sert à lancer le processus côté client ?

Le process client est lancé par une commande simple :
ssh -fN monserveur.masociete.fr
 
C'est dans le ssh_config que j'ai les options ensuite :
Host *.masociete.fr
port XXXX
RemoteForward
ServerAliveInterval

Il n'y a pas de valeur définie à ton paramètre ServerAliveInterval, essaye de mettre 10
 
Je pense qu'il reste avec la valeur par défaut sinon (0, qui veut dire "jamais" ).

D'ailleurs, tu peux vérifier qu'il envoie bien les keepalive en lançant une connexion inactive, et en faisant un tcpdump.

Bonne idée le tcpdump. je vais faire ça.
 
Par contre, j'ai pas mis les valeurs, mais elles sont bien renseignées.  
Mon keepalive est à 15
(et btw, le remoteforward tout seul comme ça ne peut pas marcher non plus, mais je ne vous emmerde pas au point de mettre les params   )

Le tcpdump remonte bien les keepAlive

Le délai de 15 secondes est bon (j'ai deux clients, d'où les deux WANs)

Il y a quelque chose qui m'échappe.
 
Si je comprends bien, la liaison a une coupure, qui pète le tunnel, le process s'arrête côté serveur, mais persiste côté client.
 
Je vois bien le paramètre "ExitOnForwardFailure=yes" qui pourrait jouer un rôle, mais à priori s'applique seulement en cas d'échec à l'établissement du tunnel, ce qui ne semble pas être ton cas. Enfin ça ne coûte rien d'essayer.
 
Sinon, j'ai trouvé cet article sympa, dont tu pourrais t'inspirer si le trafic qui transite à travers ton tunnel utilise une connexion persistante :
http://www.g-loaded.eu/2006/11/24/ [...] h-tunnels/

C'est exactement ce comportement, N-mi...
 
Je regarde ton article ce soir en rentrant.
En effet l'option (qui est d'ailleurs par défaut, il me semble) n'agit que sur l'établissement.

Moi j'utilise autossh pour maintenir ma connection ssh vers mon server/proxy automatiquement.
 
Peut être que ça résoudra ton problème ?
 
https://wiki.archlinux.fr/Autossh

Bon j'avais une hypothèse, mais impossible de reproduire le problème depuis chez moi, donc j'ai un doute sur la validité de mon raisonnement.
 
Voici la réponse que j'étais sur le point d'envoyer :
 

 
Problème : lorsque je reproduis ton fonctionnement et que je coupe la connexion vers la machine de test (d'une manière non détectée facilement par ssh), au bout de 3 keepalive ratés le processus client reset la connexion vers le processus local (un apache dans mon cas) et se termine.
 
Il y a vraiment un comportement spécifique à ta plate-forme

Ta citation doit coller au comportement.
 
Malheureusement comme ça ne s'est pas reproduit depuis un moment, je n'ai pas pu vérifier quels process étaient encore en cours, mais je pense que tu as vu juste.
 
En effet je n'arrive pas non plus à le reproduire.
 
Zorglub : une des machines est une distro un peu limitée, donc autossh n'y est pas (oui je sais c'est nul...) et comme c'est une machine cliente, je n'ai pas le droit d'y installer de paquets ! Mais merci de l'idée
 
Nous verrons bien à la prochaine coupure, j'essaierai de choper un max d'infos. Sauf que souvent je m'en rends compte quand il faut que j'intervienne rapidement chez le client, aussi je remonte le tunnel à toute vitesse pour le satisfaire...

J'ai trouvé des liens qui parlent de problèmes similaires (et pouvant se produite de manière non reproductible), mais pas dans un contexte de tunneling malheureusement, mais en effet mon idée pourrait être assez proche du comportement observé.

http://stackoverflow.com/questions [...] -sometimes
http://www.snailbook.com/faq/background-jobs.auto.html

Bingo !
 
J'ai (presque) reproduit le problème.
 
1) Dans un term sur mon PC, je lance la commande suivante pour streamer à basse vitesse un gros fichier à toute connexion entrante sur le port 10000

 
2) Dans un autre term, je lance un reverse tunnel SSH vers un serveur du taff, qui écoute sur le port 12345 et se connect au port 10000 du PC :

 
3) Depuis server1, je me connecte à localhost:12345 pour accéder au port 10000 de mon PC :

 
4) Je coupe mon VPN qui me permet d'accéder à server1, et interrompt donc tout possibilité de communiquer à travers le tunnel SSH
 
5) Un quart d'heure après avoir coupé le VPN, le processus client est toujours présent, parce que netcat est encore en train d'essayer de balancer du trafic :

 
6) Je me connecte par un autre chemin sur server1. Je constate que le processus serveur SSH est toujours là, ainsi que le netcat. C'est là que le comportement diverge (verge ) à cause sûrement de réglages différents pour les timeout TCP. Je kille le process serveur SSH, ce qui entraîne le netcat de server1 dans la foulée.
 
7) Je relance le VPN. Mais je constate que même après plusieurs minutes, le client SSH est toujours là et pense toujours être connecté (note: 192.168.2.1 est l'adresse du VPN (ppp0) ) :

 
Le pire dans tout ça, c'est que la connexion est bien dans l'état ESTABLISHED pour les 2 sockets du client SSH.
 

Eh bah bravo ! C'est exactement ce que j'ai chez moi
 
Sauf pour le process coté serveur encore présent.
 
Bon tu me résouds ça pour demain ?
 
Merci beaucoup pour tes investigations N-Mi

Ah ben le temps de finir de taper le message, le processus client SSH s'est terminé avec un message "Write failed: Broken pipe".
 
Après, c'est peut-être dû à un timeout de netcat ou a des différences de config. Ou alors pv a trop bufferisé de données dans le pipe vers netcat. Bref, difficile de savoir.
 
En tout cas, ça ressemble furieusement à ton problème.
 
L'idéal serait donc de trouver un moyen de tester périodiquement (via une tâche cron) que le tunnel fonctionne bien, et de le tuer/redémarrer si ce n'est pas le cas.

That's the point.
 
Mon autre soluce est de kill le process tous les matins et de le relancer. Mais c'est sale, j'aime pas

Solution à la con :
 
Sur le client, lancer périodiquement un script qui se connecte vers le port du serveur en écoute localement. Exemple :

 
Si le port est fermé, c'est que le process ssh s'est terminé côté serveur. Donc tu tues ton client SSH bloqué et tu relances le tunnel.