ServerAliveInterval SSH via VPN : quel côté envoie la sonde ?

La plupart des conseils pour garder une session SSH en vie s'arrêtent à « ajoutez ServerAliveInterval 30 » et laissent de côté les parties utiles. Le mot-clé est un minuteur côté client qui ne se déclenche que lorsque le canal est resté silencieux, il compte les sondes sans réponse plutôt que les secondes, et il vit dans un fichier où la première valeur correspondante l'emporte. Trompez-vous sur ces trois propriétés et une session VPN saine tombera quand même, tandis qu'une session morte restera suspendue.

Les deux directions appartiennent à des démons différents

ServerAliveInterval est lu par votre client ssh. ClientAliveInterval est lu par sshd de l'autre côté et sonde dans l'autre sens, du serveur vers le client. Ce ne sont pas des alias et ils ne coopèrent pas, donc régler l'un n'a aucun effet sur le comportement de l'autre extrémité. Les confondre est la raison habituelle pour laquelle un correctif semble fonctionner sur un hôte et pas sur le suivant.

Les deux acceptent zéro. À zéro, le client n'envoie absolument rien, et côté serveur un ClientAliveCountMax à zéro désactive la déconnexion qui suivrait autrement les vérifications sans réponse.

Ce qu'une sonde prouve, et ce qu'elle ne prouve pas

Une fois l'intervalle configuré écoulé sans qu'aucune donnée n'arrive du serveur, le client envoie une petite requête dans le canal chiffré existant et attend une réponse. ServerAliveCountMax fixe combien d'entre elles peuvent rester sans réponse avant que la session ne soit coupée. Avec un intervalle de 60 et un compteur de 3, le client abandonne après environ trois minutes de silence, et ce chiffre est une propriété de votre configuration, pas une norme réseau. Laissez l'intervalle à sa valeur par défaut 0 et aucune sonde n'est jamais envoyée, ce qui explique qu'un client standard puisse rester indéfiniment sur une connexion morte.

Parce que l'échange se déroule à l'intérieur du transport SSH, une réponse prouve que le processus SSH d'en face lit et écrit encore. Elle ne dit rien du programme que vous avez lancé dans cette session : un client de base de données, un port redirigé ou un script de longue durée peuvent être bloqués pendant que le transport répond gaiement aux sondes.

TCPKeepAlive est un mécanisme distinct, une couche plus bas. Le noyau s'en charge, il n'est pas chiffré, et une extrémité dont le démon SSH est bloqué peut encore le satisfaire. C'est pourquoi la sonde au niveau SSH est le signal le plus significatif lorsque c'est la session qui vous importe, et non la socket.

L'ordre décide quelle valeur survit

OpenSSH applique la première valeur qu'il obtient pour chaque paramètre, donc un bloc Host précis doit apparaître avant tout bloc plus large qui correspondrait aussi. Placez les valeurs par défaut à jokers en bas du fichier, pas en haut, et rappelez-vous qu'un bloc Match plus bas ne peut pas remplacer une valeur déjà définie. La référence de configuration du client OpenSSH énonce directement la règle de la première valeur, ce qui vaut une lecture avant de réorganiser une configuration partagée.

Les options de ligne de commande l'emportent sur le fichier, ce qui rend peu coûteuse une expérience temporaire :

ssh -o ServerAliveInterval=15 -o ServerAliveCountMax=4 office-shell

Pour voir ce que le client a réellement résolu plutôt que ce que vous croyez avoir écrit, demandez-lui de vider la configuration effective. La sortie contient les valeurs fusionnées pour ce nom d'hôte et c'est le moyen le plus rapide d'attraper un bloc antérieur égaré :

ssh -G office-shell | grep -i alive

Ce que font les keepalives à travers un tunnel

Le trafic périodique empêche une association NAT ou de pare-feu avec état d'expirer, ce qui est un vrai bénéfice sur un VPN dont la passerelle abandonne les flux inactifs au bout de quelques minutes. Les sondes qui arrivent toutes les 60 secondes rafraîchissent cette association sans transporter la moindre donnée applicative.

Ils ne peuvent pas reconstruire un chemin qui a disparu. Quand l'interface du tunnel disparaît, les sondes échouent comme tout le reste, et la session se termine une fois le compteur épuisé. La détection de vivacité et la récupération du chemin sont des problèmes différents, et seul le premier est configurable dans ssh_config. Ce que l'intervalle et le compteur vous achètent réellement, c'est la vitesse à laquelle le client s'en aperçoit, et c'est la partie que l'utilisateur ressent comme un blocage.

Les connexions multiplexées ajoutent un pli. Avec ControlMaster en jeu, les sondes appartiennent à la connexion maîtresse, et une nouvelle session sur une maîtresse existante hérite de ce que cette maîtresse a négocié. Si la maîtresse du mux est bloquée, ouvrir une autre fenêtre ne testera pas à nouveau le chemin.

Confirmer le réglage de bout en bout

Sur le serveur, videz la configuration effective du démon plutôt que de lire le fichier et de deviner quel include a gagné :

sshd -T | grep -i clientalive

Observez ensuite une vraie session avec la sortie de débogage activée. Le client imprime une ligne de délai d'attente lorsque le compteur s'épuise, et les horodatages autour montrent si le silence était continu ou si les sondes n'ont jamais été envoyées. Une session qui meurt sans aucun trafic de sonde a généralement le mot-clé dans un bloc qui n'a jamais correspondu.

Deux vérifications valent la peine pour tout hôte que vous n'atteignez que par un tunnel : confirmez que l'intervalle résolu est bien celui que vous vouliez, et confirmez que cet intervalle multiplié par le compteur est plus court que le délai d'inactivité de la passerelle VPN. Quand le second nombre est plus grand, la passerelle abandonne d'abord le flux en silence et la sonde SSH n'a jamais l'occasion de signaler quoi que ce soit.