Débogage des goulots d'étranglement conntrack et des limites de sockets en cas d'un fort volume de connexions TCP

Si, dans un environnement d’hébergement, de nouvelles connexions TCP échouent soudainement ou que des clients signalent massivement des timeouts, la bonne question n’est que rarement « Pourquoi l’application plante ? » mais « Quel type de limite système empêche les connexions ? » Dans ce runbook pratique, vous apprendrez comment debugger les goulots Conntrack et les limites de sockets : chemins rapides pour formuler des hypothèses, points de mesure fiables, causes typiques et corrections sûres avec stratégie de repli. Le public visé est constitué d’administrateurs, d’ingénieurs systèmes et d’exploitants dans des environnements Hosting/Cloud.

Conntrack-Engpässe und Socket-Limits debuggen: Kurze Begriffsorientierung

Conntrack (Connection Tracking) est un sous-système du noyau qui gère les flux réseau comme des objets d’état. Il est utilisé pour le NAT (Source/Destination NAT) et le firewalling stateful (Netfilter). Les ports éphémères (Ephemeral Ports) sont les ports sources dynamiques pour les connexions sortantes ; leur plage est définie par net.ipv4.ip_local_port_range. Les socket-backlogs (listen-backlog) mettent en tampon les nouvelles connexions jusqu’à ce que l’application les traite via accept() ; la limite côté noyau est contrôlée par net.core.somaxconn. TIME_WAIT est un état TCP après fermeture qui occupe les ports pendant un court laps de temps.

Symptome und ihre erste Einordnung

Vérifiez d’abord : le problème est-il inbound (les clients n’atteignent pas le service), outbound (l’hôte ne peut pas établir de connexions sortantes) ou les deux ?

Typische Symptomklassen

• Conntrack voll : le journal du noyau signale «nf_conntrack: table full, dropping packet» ; le trafic NAT s’effondre.
• SYN/Backlog-Probleme : de nombreux SYN_RECV, les clients constatent des timeouts ; l’application n’accepte pas assez rapidement.
• Ephemeral-Port-Engpass : les connexions sortantes échouent avec «cannot assign requested address» ; de nombreux TIME_WAIT.
• FD-Limits : les processus signalent «too many open files» ; le système atteint fs.file-max ou la limite par processus Max open files est trop basse.

In 10 Minuten zur belastbaren Hypothese

La séquence suivante sépare la mesure de la modification et fournit rapidement une direction.

1) Kernel-Logs und erste Suche

journalctl -k -S "-30 min" | egrep -i "conntrack|nf_conntrack|table full|dropping packet|too many open files" || true
dmesg -T | egrep -i "conntrack|nf_conntrack|table full|dropping packet" || true

«table full» est un indicateur clair d’un engorgement Conntrack ; d’autres types d’erreurs requièrent des compteurs supplémentaires.

2) Conntrack-Füllstand messen

cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max
cat /proc/net/stat/nf_conntrack | tail -n 1

Si nf_conntrack_count reste durablement proche de nf_conntrack_max, la table est le goulot d’étranglement. Des pics, même brefs, peuvent suffire à provoquer des drops.

3) TCP-Zustände und Backlogs

ss -s
ss -ant | awk 'NR>1 {print $1}' | sort | uniq -c | sort -nr | head -n 15
ss -ant state syn-recv | wc -l
ss -ant state time-wait | wc -l

De nombreux SYN_RECV indiquent des problèmes de backlog d’écoute/accept ; de nombreux TIME_WAIT indiquent un turnover élevé des connexions.

4) File-Descriptor- / Prozesslimits

cat /proc/sys/fs/file-nr
cat /proc/sys/fs/file-max
PID=1234
cat /proc/$PID/limits | egrep -i "Max open files"

Si fs.file-max est atteint ou si la limite par processus est basse, de nouveaux sockets échouent indépendamment du Conntrack.

Goulots d’étranglement conntrack et limites de sockets : causes et contre-mesures

Les entrées Conntrack sont créées par des flux de connexions, pas seulement par le « vrai » trafic utilisateur. Les moteurs fréquents sont les passerelles SNAT, les reverse-proxies avec de nombreuses connexions courtes, des health checks agressifs et des scanners/discovery. Les timeouts Conntrack prolongent la durée de vie d’une entrée et peuvent remplir la table.

Allègement ciblé

Avant d’augmenter aveuglément nf_conntrack_max, examinez les alternatives :

• Filtres avant Conntrack : certains chemins de vérification (p. ex. monitoring interne) peuvent être exclus du suivi à l’aide de NOTRACK/CT‑BYPASS, si aucun NAT ni matching stateful n’est nécessaire.
• Réduire le trafic : limiter les intervalles des health checks, les scans parallèles et le churn inutile.
• Segmentation : plusieurs passerelles répartissent la charge Conntrack au lieu de remplir une grosse table commune.

N’augmentez nf_conntrack_max que si vous disposez d’une marge RAM suffisante ; une table volumineuse consomme de la mémoire noyau et, en cas de surdimensionnement, peut entraîner des problèmes de performance.

Limites de sockets : backlog, ports éphémères, TIME_WAIT, limites de FD

Backlog d’écoute et somaxconn

Le backlog d’écoute tamponne les connexions jusqu’à ce que l’application les traite via accept(). Les limites du noyau sont net.core.somaxconn et net.ipv4.tcp_max_syn_backlog. tcp_syncookies protège contre les SYN-Floods, mais ne remplace pas une capacité suffisante.

sysctl net.core.somaxconn
sysctl net.ipv4.tcp_max_syn_backlog
sysctl net.ipv4.tcp_syncookies

Ports éphémères et plage de ports

Avec de nombreuses connexions sortantes vers les mêmes cibles, la plage de ports peut devenir insuffisante. Le noyau utilise net.ipv4.ip_local_port_range. En présence de NAT s’ajoutent des limites de mapping et le Conntrack.

sysctl net.ipv4.ip_local_port_range
ss -ant | awk 'NR>1 {print $4 " -> " $5}' | head -n 20

TIME_WAIT : cause plutôt que conséquence

De nombreuses connexions en TIME_WAIT résultent du churn de connexions. Les contre-mesures durables se trouvent généralement dans l’application : Keep-Alive, connection pooling et des health checks moins agressifs. L’ajustement du noyau n’est qu’un second choix.

ss -ant state time-wait | awk 'NR>1 {print $4}' | cut -d: -f1 | sort | uniq -c | sort -nr | head

Limites de descripteurs de fichiers et systemd

Sur les systèmes modernes, les units systemd définissent leurs propres limites. Les modifications dans un shell ne s’appliquent pas aux services démarrés par systemd.

systemctl show -p LimitNOFILE myservice.service
systemctl edit myservice.service

[Service]
LimitNOFILE=200000

systemctl daemon-reload
systemctl RESTart myservice.service
cat /proc/$(pgrep -f myservice)/limits | grep -i "Max open files"

Runbook de débogage pratique : étape par étape

Déterminer le périmètre

Est-ce inbound, outbound ou les deux ? Cela oriente les vérifications suivantes et les mesures immédiates possibles.

Analyse des points chauds : qui génère les flux ?

ss -ant | awk 'NR>1 {print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head
ss -ant | awk 'NR>1 {print $4}' | cut -d: -f1 | sort | uniq -c | sort -nr | head

Pour une analyse Conntrack plus précise, utilisez les conntrack-tools (conntrack -L) pour observer les motifs de flux et les timeouts.

Conntrack-tools : exemples concrets

# Listen mit Zeitstempel und TCP-Zustand
conntrack -L -o timestamp | head

# Alle Flows zu einer Client-IP auffinden
conntrack -L -s 10.0.0.5

# Flows nach Zustand filtern
conntrack -L -p tcp --state ESTABLISHED,SYN_RECV

# Schnellzählung bestimmter Zustände
conntrack -S | egrep "insert=|drop="

Pourquoi cela aide : conntrack -L montre combien de temps les flows RESTent dans la table. Cela donne des indices sur des timeouts élevés, de nombreuses connexions courtes ou une combinaison client/service spécifique comme facteur déclenchant.

Stabilisation à court terme (avec évaluation des risques)

En cas de risque de panne, des mesures temporaires sont envisageables — documentées et avec plan de retour en arrière :

A) Augmenter temporairement conntrack

sysctl -w net.netfilter.nf_conntrack_max=524288
cat > /etc/sysctl.d/99-conntrack-tuning.conf <<'EOF'
net.netfilter.nf_conntrack_max = 524288
EOF
sysctl --system

Effet : Réduit temporairement les échecs d’insertion (Insert-Fails). Risque : besoin accru de RAM noyau et simple report du problème si le churn RESTe inchangé.

B) Augmenter le backlog

sysctl -w net.core.somaxconn=4096
sysctl -w net.ipv4.tcp_max_syn_backlog=8192
cat > /etc/sysctl.d/99-tcp-backlog.conf <<'EOF'
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 8192
EOF
sysctl --system

Effet : Tamponne les pics à court terme. Risque : la latence augmente si l’application est effectivement trop lente.

C) Définir les limites FD via systemd

systemctl edit myservice.service

[Service]
LimitNOFILE=200000

systemctl daemon-reload
systemctl RESTart myservice.service

Effet : Empêche les coupures de descripteurs de fichiers (FD) du service. Risque : la valeur système globale fs.file-max doit également être suffisante.

Mesures durables et surveillance

Vérifier et ajuster les timeouts de conntrack (avec prudence)

Conntrack gère des paramètres de timeout spécifiques au TCP sous /proc/sys/net/netfilter comme nf_conntrack_tcp_timeout_established. Des timeouts plus courts réduisent l’occupation moyenne de la table, mais peuvent affecter le trafic TCP, p. ex. en interrompant des connexions de longue durée.

# Beispiele zum Lesen/Setzen (vorsichtig verwenden)
sysctl net.netfilter.nf_conntrack_tcp_timeout_established
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=1200

Recommandation : ne modifiez les timeouts qu’après analyse et test sous charge représentative ; documentez et automatisez le rollback.

Taille des buckets (hashsize) et NUMA

La table conntrack est organisée en interne en buckets / tables de hachage. Vérifiez le réglage actuel :

cat /sys/module/nf_conntrack/parameters/hashsize || cat /sys/module/nf_conntrack/parameters/ hashsize

Sous forte charge et sur des systèmes NUMA, des dispositions de hash inappropriées peuvent provoquer des contentions CPU. Un réglage correct de nf_conntrack_max et de la hashsize peut améliorer les performances des lookups. Les modifications de la hashsize sont des paramètres de démarrage du noyau / du module et nécessitent un reboot ou un rechargement du module.

Spécificités Kubernetes : kube-proxy et conntrack du nœud

Dans les environnements Kubernetes, conntrack s’exécute souvent sur chaque nœud et est influencé par kube-proxy / iptables. Les limites et timeouts sont critiques pour les services avec un fort churn de pods ou des probes de liveness courtes. Vérifiez :

# Nombre d'entrées conntrack sur un nœud
cat /proc/sys/net/netfilter/nf_conntrack_count
# Vérifier les flags de kube-proxy (kube-proxy dans DaemonSet)
kubectl -n kube-system get ds kube-proxy -o yaml

Si nécessaire : kube-proxy peut être configuré en mode ipvs, ce qui modifie les caractéristiques de performance et le comportement du conntrack. Les fournisseurs cloud disposent également de limites de NAT-Gateway au niveau du sous‑réseau ou du compte ; consultez la documentation du fournisseur.

Stratégie de monitoring et d’alerte

Valeurs à collecter sur le long terme : nf_conntrack_count, nf_conntrack_max, Conntrack-Drops, répartition des états TCP (TIME_WAIT, SYN_RECV, ESTABLISHED), utilisation globale des descripteurs de fichiers et erreurs applicatives. La corrélation est essentielle.

# Exemple : alerte Prometheus (Recording/Rule) pour l'utilisation du conntrack
- alert: HighConntrackUsage
  expr: (node_textfile_mtime{job="node"} == 1) OR (conntrack_count / conntrack_max) > 0.8
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Utilisation du conntrack élevée sur {{ $labels.instance }}"
    description: "nf_conntrack_count > 80% de nf_conntrack_max depuis plus de 5 minutes."

Utilisez un exporter ou le textfile-collector de node-exporter si aucun exporter natif n’est disponible.

Tests et déploiement

Modifications Canary et tests de charge

Appliquez d’abord les modifications de configuration sur un nœud canary. Les tests de charge peuvent simuler un trafic réaliste (par ex. avec wrk, hey ou tcpreplay). Mesurez le nombre de conntrack, la charge CPU et les latences pendant le test.

# Exemple : test de charge HTTP simple
wrk -t4 -c200 -d60s http://backend.service/health

Rollback

Toute modification de sysctl et tout override systemd doivent être documentés dans un ticket avec les valeurs d’origine. Le rollback consiste généralement à supprimer le fichier de configuration temporaire et à exécuter un sysctl --system ou à annuler l’override systemd :

rm -f /etc/sysctl.d/99-conntrack-tuning.conf /etc/sysctl.d/99-tcp-backlog.conf
sysctl --system
systemctl revert myservice.service
systemctl daemon-reload
systemctl RESTart myservice.service

Pièges pratiques

• Appliquer les modifications uniquement dans un shell au lieu d’un fichier persistant : elles ne survivent pas au redémarrage ni pour les services.
• Ignorer les unités systemd : le ulimit en shell n’affecte pas les services.
• Augmenter le conntrack sans réduire les causes : le problème est simplement déplacé et alourdit l’utilisation de la RAM.
• Augmenter le backlog sans mise à l’échelle de l’application : les latences augmentent sans gain de débit.
• Oublier les limites NAT spécifiques au cloud : augmenter la table conntrack locale n’aide pas si la passerelle du fournisseur est limitée.

Conclusion

Les goulots d’étranglement liés au conntrack et les limites de sockets résultent souvent d’une combinaison d’architecture (NAT/pare-feu en tant que goulot partagé), de stratégie de connexion (trop de sessions courtes) et de paramètres système conservateurs. La démarche appropriée est : mesurer systématiquement, stabiliser à court terme avec des mesures documentées et réversibles, et travailler à long terme sur le comportement source des connexions (Keep-Alive, pooling, segmentation). Ainsi, un incident de production aigu devient un cas opérationnel maîtrisé.

Conseils complémentaires de monitoring et d’alerte

Mesurez de façon continue : nf_conntrack_count, les Conntrack-Drops dans les logs du noyau, la répartition des états TCP (TIME_WAIT, SYN_RECV, ESTABLISHED), l’utilisation des FD (/proc/sys/fs/file-nr) et le couplage avec les métriques applicatives (taux d’erreur, latence). La corrélation est cruciale : c’est le seul moyen de distinguer de véritables Conntrack-Drops des pertes de paquets liées à la NIC, au CPU ou aux E/S.

Conntrack-Engpässe: Architektur- und Betriebsaspekte

Au-delà des mesures ponctuelles, l’architecture et l’organisation opérationnelle déterminent si les limites de Conntrack ou de sockets restent un incident isolé ou deviennent une charge continue. Trois perspectives pratiques aident à procéder de manière structurée :

1) Kapazitätsrechnung und Sicherheitsmargen

Les entrées Conntrack occupent de la mémoire noyau (typiquement quelques centaines d’octets par entrée). Dimensionnez nf_conntrack_max selon un calcul simple : flux simultanés prévus × taille d’entrée + marge (min. 25–50%). Utilisez les métriques Slab/mémoire sur le système de test pour mesurer les tailles réelles d’entrée. Les modifications du layout de hachage (hashsize) nécessitent généralement un redémarrage ou le rechargement du module et doivent être effectuées en fenêtre de maintenance.

2) Architekturmuster zur Entlastung

Distribuer plutôt qu’augmenter : SNAT/Conntrack peut être mis à l’échelle horizontalement en utilisant plusieurs adresses SNAT ou des passerelles NAT dédiées. En alternative, un load balancer L4 avec Direct-Server-Return ou un proxy avec connexions Keep‑Alive persistantes réduit le nombre de flux courts. Dans les environnements cloud, vérifiez les limites de NAT du fournisseur — les ajustements locaux n’y ont pas d’effet.

3) Operative Kontrolle und Observability

Mettez en place des alertes avec des seuils proportionnels (p. ex. 70/85/95 % d’utilisation) et corrélez les métriques Conntrack avec la latence applicative et l’utilisation des FD. Pour une compréhension plus fine, un traçage eBPF temporaire est pertinent : il mesure le churn de connexions sans alourdir la table Conntrack elle-même. Toute modification de configuration doit être saisie dans un ticket de changement, avec canary, métriques‑gates et rollback documenté, car l’optimisation des performances peut induire des effets mémoire ou liés aux zones NUMA.

Ces leviers opérationnels et architecturaux transforment des correctifs ponctuels en solutions durables : moins de goulots d’étranglement aigus, une croissance contrôlable et des responsabilités plus claires entre réseau, plateforme et application exploitante.

Pour ce sujet, les messages Nf_Conntrack Table Full sont également importants. Cet article remet ces aspects en perspective de manière claire et montre ce qui compte au quotidien.