Les nouvelles connexions échouent : conntrack est-il saturé ?

Les processus de l’application fonctionnent normalement et les connexions de longue durée déjà établies continuent de transmettre des données, mais les nouvelles requêtes expirent par intermittence. Ce symptôme ne vient pas nécessairement de la file d’attente des connexions entrantes de l’application. Lorsqu’un serveur dédié assure le rôle de pare-feu à états ou de traduction d’adresses réseau (NAT), la table de suivi des connexions de Linux peut aussi devenir un goulot d’étranglement. Le diagnostic consiste à rapprocher les moments où les échecs surviennent, l’occupation de la table et les compteurs du noyau, plutôt qu’à augmenter le plafond dès que le nombre de connexions paraît élevé.

Cet article prend Debian 13 comme exemple. Toutes les vérifications sont effectuées dans l’espace de noms réseau de l’hôte. Après le paiement d’un serveur CloudUDP, les identifiants d’accès sont consultables dans la console. L’accès à Linux se fait par SSH ; si plusieurs adresses sont disponibles, utilisez la première. Les opérations ci-dessous ne modifient aucune règle réseau et ne suppriment pas les états des connexions existantes.

1. Vérifier que le trafic concerné passe par le suivi des connexions

Le suivi des connexions, ou conntrack, enregistre le protocole, les adresses, l’état et le délai d’expiration des flux. Ces informations servent au filtrage par état et au NAT. Une connexion applicative ne correspond pas à un thread de l’application, et son entrée peut rester dans la table quelque temps après sa fermeture par l’application. La création intensive de connexions courtes, des scans anormaux ou une charge de trafic transféré peuvent accroître l’occupation.

Commencez par installer les outils de vérification et lire la configuration :

sudo apt-get update
sudo apt-get install conntrack
sysctl net.netfilter.nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max
sudo conntrack -S
sudo nft list ruleset

La présence de ct state ou de NAT dans les règles indique qu’il faut examiner la capacité de suivi. Leur absence ne prouve toutefois pas qu’aucun suivi n’est effectué. Si la lecture des paramètres indique qu’ils n’existent pas, vérifiez d’abord les modules et le chemin réellement emprunté par le trafic. Ne chargez pas de modules à l’aveugle dans le seul but d’obtenir la sortie attendue.

Les résultats obtenus dans un conteneur ne remplacent pas directement ceux de l’hôte. Le transfert de trafic par l’hôte et le traitement à l’intérieur du conteneur peuvent passer par des espaces de noms différents : notez impérativement où les commandes ont été exécutées. Sinon, une faible occupation dans le conteneur risque d’être utilisée à tort pour expliquer les pertes de paquets sur l’hôte.

N’utilisez pas conntrack -F comme procédure habituelle de rétablissement. Vider la table supprime les états existants et peut interrompre les sessions qui dépendent du filtrage par état ou du NAT. Cela fait également disparaître des éléments de diagnostic qu’il aurait fallu conserver.

2. Relever l’occupation et la variation des compteurs d’erreurs sur une même période

nf_conntrack_count indique le nombre actuel d’entrées, tandis que nf_conntrack_max fixe le plafond. Une occupation proche du plafond signifie que la marge diminue, mais ne suffit pas à prouver qu’elle provoque les échecs des requêtes. conntrack -S affiche des statistiques par processeur : additionnez les valeurs de chaque compteur sur l’ensemble des processeurs, puis comparez deux relevés. Une seule ligne ne représente pas le total du serveur.

umask 077
out=$(mktemp -d /var/tmp/ct-check.XXXXXX)
for sample in 1 2; do
  {
    date -Is
    sysctl net.netfilter.nf_conntrack_count
    sysctl net.netfilter.nf_conntrack_max
    sudo conntrack -S
  } > "$out/sample-$sample.txt"
  if [ "$sample" -eq 1 ]; then
    sleep 10
  fi
done
sudo journalctl -k --since "-10 min" --no-pager \
  > "$out/kernel.txt"
printf '%s\n' "$out"

L’intervalle entre les relevés n’est ici qu’un exemple pratique. La période observée doit couvrir les échecs de l’application. Vérifiez en priorité si insert_failed, drop et early_drop continuent d’augmenter, et si le noyau signale que la table des connexions est pleine. Les champs peuvent varier selon la version du noyau : l’absence d’un champ ne permet pas de conclure que tout fonctionne normalement.

Conservez en parallèle le nombre d’échecs d’établissement de nouvelles connexions côté application, le volume de requêtes et le texte original des erreurs. Si le serveur vient de redémarrer, la référence des compteurs cumulés a changé : ne soustrayez pas directement les valeurs relevées avant et après le redémarrage. De même, l’arrêt de la progression des erreurs en période creuse ne valide pas la capacité pour les pointes de charge.

3. Déterminer pourquoi les entrées s’accumulent

Distinguez d’abord une hausse normale du nombre de connexions simultanées d’un rythme anormal de création. Comparez les requêtes entrantes, les connexions sortantes initiées par l’application, le trafic transféré et la réutilisation des connexions. Même des connexions très brèves peuvent s’accumuler si elles sont créées à un rythme élevé ; pour les connexions de longue durée, le nombre réel de connexions simultanées est plus déterminant.

Ne pas commencer par exporter toute la table

Sur un hôte chargé, l’énumération complète des entrées ajoute elle-même un coût au diagnostic, et la sortie contient des adresses de communication. Consultez d’abord les compteurs agrégés. Si un examen détaillé est réellement nécessaire, limitez le protocole et le volume de sortie :

sudo timeout 5s conntrack -L -p tcp -o extended 2>/dev/null \
  | head -n 100

Cette sortie n’est qu’un échantillon biaisé, pas une statistique de répartition des états. L’expiration du délai ou la fermeture anticipée du pipeline peut aussi entraîner un code de sortie non nul ; cela ne signifie pas que la table est corrompue. Ne conservez les relevés contenant des adresses que dans un répertoire à accès restreint, et retirez les informations sans rapport avec le problème avant d’ouvrir un ticket d’assistance.

Vérifiez également les processus à l’écoute, les erreurs de l’application et les réponses des services en amont. Si la table dispose d’une marge et que les compteurs concernés n’augmentent pas, recherchez plutôt un blocage applicatif, un problème de routage ou des pertes de paquets ailleurs sur le trajet. Ne poursuivez pas les réglages de conntrack sans éléments qui les justifient.

Ne commencez pas par raccourcir les délais d’expiration de tous les protocoles. Ces délais déterminent combien de temps l’état d’une connexion inactive reste conservé ; les réduire excessivement peut perturber les connexions de longue durée. L’absence de réutilisation des connexions dans un pool, les tentatives répétées incontrôlées après un échec et les problèmes similaires doivent être corrigés côté appelant.

4. Appliquer une modification réversible en tenant compte de la mémoire

Augmenter le plafond autorise simplement la présence d’un plus grand nombre d’entrées ; cela ne corrige pas la source du trafic anormal. Les entrées consomment de la mémoire du noyau, et leur coût dépend notamment des extensions de protocole et de la configuration du noyau. Une valeur fixe de « tant d’octets par entrée » ne permet donc pas de calculer un budget précis.

Avant toute modification, conservez la sortie de free -h et le contenu de /proc/meminfo, puis examinez les caches d’objets du noyau avec sudo slabtop -o. Slab est le mécanisme de cache utilisé par le noyau pour gérer les objets. Les statistiques des objets de suivi des connexions qui y figurent ne couvrent pas non plus l’ensemble de la mémoire associée.

Si les éléments recueillis confirment un manque de capacité et qu’il reste de la mémoire disponible, procédez par petits ajustements pour en vérifier l’effet. L’exemple suivant augmente le plafond initial d’un quart. Il s’agit uniquement de l’ampleur d’un essai, pas d’une configuration fixe recommandée :

old=$(sysctl -n net.netfilter.nf_conntrack_max) || exit 1
case "$old" in
  ''|*[!0-9]*) exit 1 ;;
esac
new=$((old + old / 4))
printf 'old=%s new=%s\n' "$old" "$new"
sudo sysctl -w net.netfilter.nf_conntrack_max="$new"

Gardez cette session ouverte et conservez la valeur initiale. Effectuez de nouveaux relevés avec un volume de requêtes comparable. Si les échecs ne diminuent pas, n’augmentez pas le paramètre à répétition : rétablissez la valeur initiale et examinez d’autres éléments de diagnostic.

sudo sysctl -w net.netfilter.nf_conntrack_max="$old"

Avant de revenir en arrière, vérifiez l’occupation actuelle. Si elle dépasse déjà le plafond initial, réduisez d’abord la pression liée à la création de nouvelles connexions ; sinon, le retour à l’ancienne valeur peut déclencher à nouveau un problème de capacité. Ne modifiez pas simultanément le nombre de compartiments de hachage, les délais d’expiration des protocoles et les règles du pare-feu : la validation doit porter sur une seule variable à la fois.

5. Décider de la persistance d’après les résultats applicatifs

La validation doit réunir trois types de preuves : le taux de réussite des nouvelles connexions est rétabli à charge comparable, les compteurs d’erreurs concernés ne continuent plus d’augmenter, et la mémoire ainsi que les caches d’objets du noyau ne subissent pas de nouvelle pression. Une simple baisse du taux d’occupation ne suffit pas à considérer le problème comme résolu.

Une fois l’efficacité confirmée, inscrivez la valeur numérique validée dans /etc/sysctl.d/90-conntrack-capacity.conf. Avant de l’écrire, vérifiez si d’autres fichiers de configuration définissent déjà le même paramètre, afin d’éviter qu’il soit écrasé selon l’ordre de chargement. Chargez uniquement ce fichier, sans appliquer au passage d’autres réglages non validés du serveur :

sudo sysctl -p /etc/sysctl.d/90-conntrack-capacity.conf
sysctl net.netfilter.nf_conntrack_max

Le fichier doit contenir une ligne net.netfilter.nf_conntrack_max = entier_validé, dans laquelle le texte explicatif doit être remplacé par le nombre réel. Après le prochain redémarrage planifié par l’équipe d’exploitation, vérifiez de nouveau la valeur effective et les éventuelles erreurs de chargement. Ne redémarrez pas immédiatement un serveur de production pour la seule vérification de ce paramètre.

Enfin, conservez les valeurs initiale et nouvelle, la période de mesure, le volume de requêtes, les écarts entre compteurs et les conditions de retour arrière. Le but de la gestion de capacité de conntrack n’est pas d’obtenir un nombre plus élevé, mais de pouvoir expliquer les échecs de connexion, démontrer l’efficacité du changement et vérifier à nouveau les mêmes éléments lorsque la charge évolue.

Questions fréquentes