SSH coupe sur le VPN chaque minute ? Ce n’est pas le keepalive

SSH se connecte, fonctionne une minute environ, puis se fige à peu près au même intervalle à chaque fois. L’explication courante est un délai d’inactivité, alors les gens baissent le MTU et configurent des keepalives côté client. La liaison WireGuard sur laquelle je travaillais avait déjà tout essayé : un MTU de tunnel plus petit, des réglages client-alive, un keepalive de tunnel configuré. Les coupures continuaient sans changement. La cause s’est révélée être une route LAN asymétrique, et le schéma vaut la peine d’être reconnu car il défait toute correction basée sur des minuteurs.

Un keepalive prouve que votre hôte est toujours disposé à envoyer. Il ne peut pas faire voir à un équipement à état une réponse qui ne le traverse jamais.

Le mythe : les keepalives corrigent une coupure silencieuse

Les keepalives SSH existent pour une seule tâche : empêcher que quelque chose qui compte le silence ne récupère une session inactive. Ils le font bien. Ils ne règlent pas le cas d’un équipement à état qui a vu le premier paquet dans un sens puis n’a jamais vu la réponse, car rien de ce que le client envoie ne change l’interface qu’utilise la réponse.

Changer le MTU est l’autre correction populaire, et elle a le même mode de défaillance. Réduire le MTU aide la fragmentation et les problèmes de MTU de chemin, et ne fait rien à une route. Si vos minuteurs et votre MTU sont déjà raisonnables et que la coupure se produit toujours à intervalle régulier, l’intervalle vous parle d’un délai quelque part, pas de la taille des paquets. Notez l’intervalle et comparez-le aux délais d’état sur chaque équipement du chemin.

L’indice est la régularité combinée à une session qui reste utilisable dans cet intervalle. Les délais d’inactivité frappent quand rien ne se passe ; celui-ci frappe pendant que vous tapez.

Ce que fait réellement la passerelle supplémentaire

Placez le portable et la passerelle VPN sur le même LAN, avec un pare-feu LAN distinct comme passerelle par défaut. Le portable envoie le trafic destiné au VPN au pare-feu, le pare-feu le transmet à la passerelle, et les réponses de la passerelle reviennent directement par le LAN jusqu’au portable. Ce second tronçon ne passe jamais par le pare-feu, donc sa table d’état ne retient qu’une demi-connexion.

Les adresses ci-dessous reflètent cette disposition :

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

Les redirections et la gestion d’état transforment alors une poignée de main fonctionnelle en une connexion qui meurt plus tard plutôt qu’immédiatement. Le retard est l’entrée d’état qui expire ou une vérification plus stricte qui échoue, et c’est pourquoi l’intervalle paraît si mécanique.

Rien de tout cela n’apparaît dans la configuration du client, et c’est pourquoi sa recherche commence généralement dans le mauvais fichier.

Choisissez un chemin délibéré

Pour la disposition ci-dessus, router le sous-réseau distant directement vers la passerelle VPN supprime la demi-connexion :

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

Ce sont des adresses d’exemple. Le saut suivant doit être joignable sur votre LAN, le préfixe doit être le réseau distant voulu, et la seconde commande vous montre le résultat avant que vous ne vous y fiiez. Si la passerelle n’est pas sur votre sous-réseau, cette route n’est pas la correction que vous voulez.

Si le pare-feu est censé contrôler le trafic entre ces systèmes, router à côté est une mauvaise conception. Faites plutôt traverser la frontière aux deux directions et configurez les routes de chaque côté pour que le chemin de retour corresponde. Le but est un seul chemin délibéré, pas moins de vérification d’état.

Les notes sur le routage asymétrique de Netgate décrivent la même asymétrie au niveau de l’interface et les problèmes d’état qu’elle crée, alors lisez-les avant d’assouplir la gestion d’état globalement. Les déconnexions minutées semblables à ce cas ne sont pas une preuve en soi. Traitez l’article comme la description d’un mode de défaillance, puis prouvez que votre propre réseau y correspond avant de changer la politique d’état globale.

Testez des deux côtés

Lisez la route du portable vers la destination et la route de la destination vers le portable ; ce sont deux décisions distinctes et une seule d’entre elles est probablement fausse. Un ping qui réussit depuis la passerelle elle-même peut masquer entièrement le problème, car il part de la machine dont le chemin est déjà correct. Vous avez besoin des deux directions telles que les voient les deux extrémités de la session réelle.

Après la correction, rouvrez SSH et gardez la session ouverte bien au-delà de l’intervalle qui échouait. Rendez ensuite la route persistante dans la configuration réseau approuvée, car une commande ponctuelle n’est pas un plan de redémarrage et le problème reviendra au prochain redémarrage avec un nouveau mystère.

Quand l’asymétrie est acceptable

Le routage asymétrique est normal dans de nombreux réseaux et n’est pas cassé par définition. Il devient un problème quand le suivi d’état, la traduction ou la politique dépendent de voir un chemin qu’ils ne voient pas, et chacun a un remède différent. Vérifiez ce dont l’équipement intermédiaire a réellement besoin avant de reconcevoir autour de lui.

La réponse durable nomme les deux chemins, l’équipement qui doit voir les deux et la route qui rend cela possible. Si vous ne pouvez pas nommer l’équipement, vous n’avez pas encore trouvé la cause.