Le relais VPN cesse d’accepter SSH : limites de descripteurs de fichiers

Une poignée de main WireGuard s’achève toujours, le pair affiche toujours un point de terminaison récent, et pourtant une nouvelle session SSH passant par le relais derrière lui reste suspendue sans bannière. Cette combinaison éloigne du tunnel et pointe vers le processus qui accepte la socket. Un relais comme socat se trouve sur le chemin de l’application avec son propre budget de descripteurs, ses propres enfants et ses propres limites héritées. La marche ci-dessous part du client et s’arrête au premier composant qui ne peut pas ouvrir une autre socket.

Suivez le chemin avant de changer un nombre

Suivez une requête en échec au lieu de raisonner sur le tunnel dans son ensemble. Le client écrit dans le tunnel, le démon VPN déchiffre et route, et le relais accepte de l’autre côté. Chaque étape consomme des descripteurs, et celle qui s’épuise habituellement est la dernière.

Commencez par une requête que vous pouvez reproduire et mesurez son temps. Si la poignée de main TCP s’achève mais qu’aucune bannière applicative n’arrive, le relais a pris la socket puis s’est bloqué dans un enfant ou sur sa patte amont. Si la poignée de main elle-même ne s’achève jamais, la cause est le routage, le pare-feu ou l’état de l’écouteur, pas un plafond de descripteurs. Notez laquelle des deux formes vous avez observée, car elles pointent vers des processus différents.

Comptez aussi les sauts qui dupliquent le travail. Un écouteur qui se dédouble remet chaque socket acceptée à un enfant qui garde sa propre copie, donc le total réel est une propriété de tout l’arbre, pas seulement du parent.

Lisez la limite héritée par le relais

La seule limite qui compte appartient au processus en cours, et elle a été fixée par ce qui a lancé ce processus. Taper ulimit -n dans un shell décrit le shell. Demandez au gestionnaire de services ce qu’il a appliqué, puis confirmez sur le PID.

systemctl show -p MainPID -p LimitNOFILE vpn-relay.service
cat /proc/$(systemctl show -p MainPID --value vpn-relay.service)/limits

Le fichier limits imprime les plafonds souple et dur tels que le processus les voit. Une valeur souple basse sous une valeur dure généreuse signifie que le démon peut relever son propre plafond, et certains le font au démarrage ; des valeurs souples égales et basses signifient que le fichier d’unité est la source.

Les fichiers drop-in se chargent dans l’ordre lexicographique et les fichiers ultérieurs l’emportent, donc systemctl cat vpn-relay.service est la vue faisant autorité de ce qui s’applique. Modifier un fichier que le gestionnaire ne lit jamais est la raison la plus courante pour qu’un nombre relevé reste sans effet.

Séparez la concurrence stable de l’état retenu

Deux processus peuvent atteindre le même plafond pour des raisons sans rapport, et les remèdes diffèrent. Une demande qui suit des sessions concurrentes utiles est une question de capacité. Une croissance qui continue après la fin du travail est une fuite ou un ensemble de sessions que personne n’a fermées.

Mesurez au repos, à votre pic habituel, et de nouveau quelques minutes après l’arrêt de la charge. Compter les entrées ouvertes avec ls /proc/PID/fd | wc -l face à la limite souple vous donne l’écart, et un compte un ou deux sous le plafond est un arrêt net plutôt qu’un chemin lent.

Quand le compte refuse de baisser, regardez les états des sockets plutôt que les totaux. Des descripteurs stationnés dans CLOSE_WAIT signifient que le pair a fermé et que votre côté ne l’a jamais fait, ce qui est un défaut de cycle de vie de l’application qu’une limite plus grande ne fait que repousser. Bornez aussi le modèle d’enfants : un relais qui se dédouble sans plafond d’enfants concurrents épuise descripteurs, emplacements de processus et mémoire ensemble.

Vérifiez la nouvelle valeur sur le processus vivant

Après avoir modifié l’unité, rechargez le gestionnaire et redémarrez le service, car un rechargement seul ne remplace jamais les limites déjà héritées par un processus en cours. Vérifiez sur le processus qui sert réellement le trafic.

systemctl daemon-reload
systemctl restart vpn-relay.service
awk '/Max open files/ {print}' /proc/$(systemctl show -p MainPID --value vpn-relay.service)/limits
ss -tnp state established '( sport = :2222 )' | wc -l

La ligne awk renvoie la nouvelle paire ; si elle affiche encore l’ancienne, le drop-in que vous avez modifié n’est pas celui qui est chargé. Le compte de ss est votre contrôle de charge, alors ouvrez le nombre de sessions attendu et regardez-le monter. Un compte qui continue de monter après la fermeture de ces sessions signifie que la limite n’a jamais été tout le problème.

Une réserve accompagne toute forte augmentation. Les applications qui interrogent avec select() ne peuvent pas surveiller les descripteurs au-delà de FD_SETSIZE, qui vaut 1024 sur les compilations typiques, donc un plafond relevé au-delà peut produire des échecs qui semblent sans rapport. La référence d’exécution de systemd porte le même avertissement pour les services qu’elle lance.

Gardez le redémarrage loin de la disponibilité du tunnel

Redémarrer le relais fait tomber ses sessions actives, et c’est un événement distinct de la chute du VPN. Ordonnez le changement pour que le tunnel reste debout pendant que le relais fait son cycle, et avertissez quiconque a une session longue qui le traverse.

Le retour arrière est le fichier d’unité précédent plus un autre redémarrage, et ce fichier reste en place jusqu’à ce que la nouvelle valeur ait survécu à une journée de travail. Fermez ensuite la boucle avec la requête qui a échoué à l’origine : une nouvelle session SSH par le relais, un transfert assez long pour compter, et un compte de descripteurs qui revient à son niveau de repos.