Debug dei colli di bottiglia di conntrack e dei limiti dei socket con un elevato numero di connessioni TCP

Se in un ambiente di hosting improvvisamente nuove connessioni TCP falliscono o i client segnalano in massa timeout, la domanda giusta raramente è „Perché si arresta l’app?“ ma „Quale tipo di limite di sistema impedisce le connessioni?“ In questo runbook operativo imparerete come debuggare i colli di bottiglia di Conntrack e i limiti delle socket: percorsi di verifica rapidi per la formulazione di ipotesi, punti di misura affidabili, cause tipiche e correzioni sicure con strategia di rollback. Il destinatario sono amministratori, ingegneri di sistema e operatori in ambienti hosting/cloud.

Conntrack-Engpässe e limiti delle socket: breve orientamento terminologico

Conntrack (Connection Tracking) è un sottosistema del kernel che gestisce i flussi di rete come oggetti di stato. Viene utilizzato per NAT (Source/Destination NAT) e firewalling stateful (Netfilter). Gli ephemeral port sono le porte sorgente dinamiche per le connessioni in uscita; il loro intervallo è definito da net.ipv4.ip_local_port_range. I backlog delle socket (listen-backlog) accumulano nuove connessioni fino a quando l’applicazione non le elabora con accept(); il limite a livello di kernel è controllato da net.core.somaxconn. TIME_WAIT è uno stato TCP dopo la chiusura che occupa le porte per un breve periodo.

Sintomi e loro prima valutazione

Verificate innanzitutto: il problema si manifesta inbound (i client non raggiungono il servizio), outbound (l’host non riesce a stabilire connessioni verso l’esterno) o entrambi?

Classi tipiche di sintomi

• Conntrack pieno: il log del kernel riporta „nf_conntrack: table full, dropping packet“; il traffico NAT si interrompe.
• Problemi SYN/Backlog: molti SYN_RECV, i client riscontrano timeout; l’applicazione non effettua gli accept abbastanza velocemente.
• Esaurimento delle porte effimere: le connessioni in uscita falliscono con „cannot assign requested address“; molti TIME_WAIT.
• Limiti di FD: i processi segnalano „too many open files“; il sistema raggiunge fs.file-max oppure il limite per processo Max open files è troppo basso.

In 10 minuti per un’ipotesi solida

La sequenza seguente separa la misurazione dalla modifica e fornisce rapidamente un’indicazione della direzione.

1) Log del kernel e ricerca iniziale

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“ è un indicatore netto di Conntrack; altri scenari di errore richiedono contatori più approfonditi.

2) Misurare il grado di occupazione di Conntrack

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

Se nf_conntrack_count è costantemente vicino a nf_conntrack_max, la tabella è il collo di bottiglia. Picchi anche brevi possono essere sufficienti a generare drop.

3) Stati TCP e backlog

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

Molti SYN_RECV indicano problemi di listen-backlog/accept; molti TIME_WAIT indicano un elevato churn di connessioni.

4) Limiti di file descriptor / del processo

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

Se fs.file-max è raggiunto o il limite per processo è basso, le nuove socket falliscono indipendentemente da Conntrack.

Colli di bottiglia di conntrack e limiti dei socket: cause e contromisure

Le voci di conntrack nascono dai flussi di connessione, non solo dal traffico utente „reale“. Tra i fattori frequenti ci sono gateway SNAT, reverse-proxy con molte connessioni brevi, health-check aggressivi e scanner/discovery. I timeout di conntrack prolungano la vita di una voce e possono riempire la tabella.

Mitigazione mirata

Prima di aumentare nf_conntrack_max in modo acritico, valutate alternative:

• Filtri prima di Conntrack: Alcuni percorsi di controllo (p. es. monitoring interno) possono essere esclusi dal tracking mediante NOTRACK/CT‑BYPASS, se non è necessario NAT o matching stateful.
• Ridurre il traffico: limitare gli intervalli dei Health-Checks, le scansioni parallele o churn non necessario.
• Segmentazione: più gateway distribuiscono il carico di Conntrack invece di riempire una grande tabella condivisa.

Aumentate nf_conntrack_max solo con sufficiente headroom di RAM; una tabella grande occupa memoria del kernel e, se sovradimensionata, può causare problemi di pRESTazioni.

Limiti dei socket: backlog, porte effimere, TIME_WAIT, limiti dei file descriptor

Listen-Backlog e somaxconn

Il listen-backlog mette in buffer le connessioni finché l’applicazione non le elabora con accept(). I limiti a livello kernel sono net.core.somaxconn e net.ipv4.tcp_max_syn_backlog. tcp_syncookies protegge da SYN-Floods, ma non sostituisce una capacità adeguata.

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

Porte effimere e intervallo di porte

Con molte connessioni outbound verso gli stessi endpoint l’intervallo di porte può esaurirsi. Il kernel usa net.ipv4.ip_local_port_range. In presenza di NAT si aggiungono limiti di mapping e Conntrack.

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

TIME_WAIT: sintomo, non obiettivo

Molte connessioni in TIME_WAIT sono conseguenza del connection-churn. Le contromisure sostenibili si applicano generalmente nelle applicazioni: Keep-Alive, connection-pooling e Health-Checks meno aggressivi. Il tuning del kernel è una seconda scelta.

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

Limiti dei file descriptor e systemd

Nei sistemi moderni le unità systemd impostano limiti propri. Le modifiche in una shell non si applicano ai servizi avviati da 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 pratico di debug: passo-für-Schritt

Determinare l’ambito

È inbound, outbound o entrambi? Questo determina i controlli successivi e le possibili contromisure immediate.

Analisi dei punti caldi: chi genera i flussi?

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

Per un’analisi più precisa di Conntrack utilizzate i conntrack-tools (conntrack -L), per vedere pattern di flusso e timeout.

Conntrack-Tools: esempi concreti

# 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="

Perché questo è utile: conntrack -L mostra per quanto tempo i Flow rimangono nella tabella. Questo fornisce indicazioni su timeout elevati, molte connessioni di breve durata o su una specifica combinazione client/service come fattore scatenante.

Stabilizzazione a breve termine (con valutazione del rischio)

Se è imminente un’interruzione, sono possibili misure temporanee — documentate e con piano di rollback:

A) Aumentare temporaneamente 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

Effetto: riduce a breve termine gli Insert-Fails. Rischio: maggiore consumo di RAM del kernel e solo uno spostamento del problema se il churn non diminuisce.

B) Aumentare il 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

Effetto: ammortizza picchi a breve termine. Rischio: la latenza aumenta se l’applicazione è effettivamente troppo lenta.

C) Impostare i limiti FD tramite systemd

systemctl edit myservice.service

[Service]
LimitNOFILE=200000

systemctl daemon-reload
systemctl RESTart myservice.service

Effetto: evita che il servizio raggiunga il limite dei file descriptor. Rischio: il valore di sistema fs.file-max deve essere adeguato.

Misure sostenibili e monitoraggio

Conntrack-Timeouts prüfen und anpassen (mit Vorsicht)

Conntrack mantiene parametri di timeout specifici per TCP sotto /proc/sys/net/netfilter come nf_conntrack_tcp_timeout_established. Timeout più brevi riducono l’occupazione media della tabella, ma possono compromettere il traffico TCP, ad esempio interrompendo connessioni a lunga durata.

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

Raccomandazione: modificate i timeout solo dopo analisi e test con carico rappresentativo; documentate e automatizzate il rollback.

Dimensione dei Bucket (Hashsize) e NUMA

La tabella Conntrack è organizzata internamente in bucket/hashtable. Verificate la configurazione attuale:

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

Sotto carico elevato e su sistemi NUMA, layout degli hash non ottimizzati possono causare contention della CPU. Un corretto bilanciamento tra nf_conntrack_max e Hashsize può migliorare le pRESTazioni delle lookup. Le modifiche alla Hashsize sono parametri del kernel/modulo all’avvio e richiedono reboot o reload del modulo.

Specificità Kubernetes: kube-proxy e node‑Conntrack

In ambienti Kubernetes, Conntrack spesso gira su ogni nodo ed è influenzato da kube-proxy / iptables. Limiti e timeout sono critici per servizi con alto churn di pod o sonde di liveness brevi. Verificate:

# Zahl der Conntrack-Einträge auf einem Node
cat /proc/sys/net/netfilter/nf_conntrack_count
# kube-proxy flags (kube-proxy in DaemonSet) prüfen
kubectl -n kube-system get ds kube-proxy -o yaml

Se necessario: kube-proxy può essere configurato in modalità IPVS, che presenta caratteristiche di performance diverse e modifica il comportamento di conntrack. I provider cloud hanno inoltre limiti sui NAT-Gateway a livello di subnet o account; consultare la documentazione del provider.

Strategia di monitoraggio e di alert

Metriche da raccogliere a lungo termine: nf_conntrack_count, nf_conntrack_max, Conntrack-Drops, distribuzione degli stati TCP (TIME_WAIT, SYN_RECV, ESTABLISHED), utilizzo globale dei FD di sistema ed errori applicativi. La correlazione è cruciale.

# Beispiel: Prometheus Alert (Recording/Rule) für Conntrack-Auslastung
- alert: HighConntrackUsage
  expr: (node_textfile_mtime{job="node"} == 1) OR (conntrack_count / conntrack_max) > 0.8
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Conntrack-Auslastung hoch auf {{ $labels.instance }}"
    description: "nf_conntrack_count > 80% von nf_conntrack_max seit mehr als 5 Minuten."

Usare Exporter o il textfile-collector di node-exporter se non è disponibile un exporter nativo.

Test e Rollout

Modifiche Canary e test di carico

Eseguire le modifiche di configurazione inizialmente su un nodo canary. I test di carico possono simulare traffico realistico (ad es. con wrk, hey o tcpreplay). Misurare il conteggio conntrack, il carico CPU e le latenze durante il test.

# Beispiel: einfacher HTTP-Loadtest
wrk -t4 -c200 -d60s http://backend.service/health

Rollback

Ogni modifica sysctl e ogni systemd-override devono essere documentati in un ticket con i valori iniziali. Il rollback consiste in genere nella rimozione del file di configurazione temporaneo e in un sysctl --system o nel ripristino dell’override di 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

Insidie operative

• Applicare le modifiche solo in una shell anziché in un file persistente: non sopravvivono a un riavvio o ai servizi.
• Ignorare le unità systemd: il ulimit da shell non influisce sui servizi.
• Aumentare conntrack senza ridurre le cause: il problema si sposta e aumenta il consumo di RAM.
• Aumentare il backlog senza scalare l’applicazione: le latenze aumentano, il throughput no.
• Trascurare i limiti NAT specifici del cloud: aumentare la tabella conntrack locale non aiuta se il gateway del provider è limitato.

Conclusione

I colli di bottiglia di conntrack e i limiti di socket sono spesso il risultato di una combinazione di architettura (NAT/firewall come collo di bottiglia condiviso), strategia di connessione (troppi sessioni brevi) e valori di sistema conservativi. L’approccio corretto è: misurare sistematicamente, stabilizzare a breve termine con misure documentate e reversibili e, a lungo termine, intervenire sul comportamento sorgente delle connessioni (Keep-Alive, pooling, segmentazione). In questo modo un problema acuto in produzione diventa un caso operativo controllabile.

Suggerimenti avanzati per monitoraggio e allarmi

Rilevate in modo continuativo: nf_conntrack_count, Conntrack-Drops dai log del kernel, la distribuzione degli stati TCP (TIME_WAIT, SYN_RECV, ESTABLISHED), l’utilizzo degli FD (/proc/sys/fs/file-nr) e l’accoppiamento con le metriche applicative (tasso di errore, latenza). La correlazione è cruciale: solo così potete distinguere i veri Conntrack-Drops dalle perdite di pacchetti dovute a NIC, CPU o I/O.

Colli di bottiglia di Conntrack: aspetti architetturali e operativi

Oltre alle misurazioni acute, sono l’architettura e l’organizzazione operativa a determinare se i limiti di Conntrack o dei socket resteranno un evento isolato o diventeranno un carico continuo. Tre prospettive pratiche aiutano a procedere in modo strutturato:

1) Calcolo della capacità e margini di sicurezza

Le voci di conntrack occupano memoria kernel (tipicamente alcune centinaia di byte per voce). Pianificate nf_conntrack_max con una semplice formula: flussi simultanei previsti × dimensione della voce + headroom (min. 25–50%). Usate le metriche Slab/memoria nel sistema di test per misurare le dimensioni reali delle voci. Le modifiche al layout dell’hash (hashsize) richiedono di norma un riavvio o il reload del modulo e dovrebbero essere eseguite in finestre di manutenzione.

2) Pattern architetturali per alleggerire il carico

Distribuire invece di aumentare: SNAT/Conntrack può essere scalato orizzontalmente impiegando più IP SNAT o gateway NAT dedicati. In alternativa, un load balancer L4 con Direct-Server-Return o un proxy con connessioni Keep‑Alive persistenti riducono il numero di flussi brevi. Negli ambienti cloud verificate i limiti del NAT del provider — le ottimizzazioni locali lì non hanno effetto.

3) Controllo operativo e osservabilità

Impostate alert con soglie proporzionali (es. 70/85/95% di utilizzo) e correlate le metriche di Conntrack con la latenza applicativa e l’utilizzo degli FD. Per una comprensione più profonda può valere la pena usare temporaneamente l’eBPF‑Tracing: questo misura il connection‑churn senza gravare sulla tabella Conntrack. Ogni modifica di configurazione deve essere inserita nel change‑ticket, con canary, metric‑gates e rollback documentato, perché il tuning delle prestazioni può provocare effetti sulla memoria o sui domini NUMA.

Queste leve operative e architetturali trasformano fix puntuali in soluzioni sostenibili: meno colli di bottiglia acuti, crescita controllabile e responsabilità più chiare tra rete, piattaforma e l’applicazione in esercizio.

Anche gli eventi Nf_Conntrack Table Full sono importanti per questo tema. L’articolo inquadra questi aspetti in modo chiaro e mostra cosa conta nella pratica quotidiana.