Conntrack-Engpässe und Socket-Limits debuggen bei hohem TCP-Verbindungsaufkommen

Wenn in einer Hosting-Umgebung plötzlich neue TCP-Verbindungen scheitern oder Clients massenhaft Timeouts melden, lautet die richtige Frage selten „Warum stürzt die App?“ sondern „Welcher System-Limit-Typ verhindert Verbindungen?“ In diesem Praxis-Runbook lernen Sie, wie Sie Conntrack-Engpässe und Socket-Limits debuggen: schnelle Prüfpfade zur Hypothesenbildung, belastbare Messpunkte, typische Ursachen und sichere Korrekturen mit Rückfallstrategie. Zielgruppe sind Administratoren, System Engineers und Betreiber in Hosting/Cloud-Umgebungen.

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

Conntrack (Connection Tracking) ist ein Kernel-Subsystem, das Netzwerkflüsse als Zustandsobjekte verwaltet. Es wird für NAT (Source/Destination NAT) und stateful Firewalling (Netfilter) benötigt. Ephemeral Ports sind die dynamischen Quell-Ports für ausgehende Verbindungen; ihr Bereich wird durch net.ipv4.ip_local_port_range definiert. Socket-Backlogs (Listen-Backlog) puffern neue Verbindungen bis die Anwendung sie per accept() verarbeitet; der Kernel‑Grenzwert wird über net.core.somaxconn gesteuert. TIME_WAIT ist ein TCP-Zustand nach dem Schließen, der Ports kurz belegt.

Symptome und ihre erste Einordnung

Prüfen Sie zunächst: Tritt das Problem inbound (Clients erreichen Dienst nicht), outbound (Host kann keine Verbindungen nach außen aufbauen) oder beides?

Typische Symptomklassen

• Conntrack voll: Kernel-Log meldet „nf_conntrack: table full, dropping packet“; NAT-Verkehr bricht zusammen.
• SYN/Backlog-Probleme: Viele SYN_RECV, Clients sehen Timeouts; Applikation akzeptiert nicht schnell genug.
• Ephemeral-Port-Engpass: Outbound Connects scheitern mit „cannot assign requested address“; viele TIME_WAIT.
• FD-Limits: Prozesse melden „too many open files“; System erreicht fs.file-max oder per-process Max open files ist zu klein.

In 10 Minuten zur belastbaren Hypothese

Die folgende Abfolge trennt Messung von Änderung und gibt schnell eine Richtung vor.

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“ ist ein harter Indikator für Conntrack; andere Fehlerbilder erfordern weitergehende Zähler.

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

Ist nf_conntrack_count dauerhaft nahe nf_conntrack_max, ist die Tabelle der Engpass. Spitzen können kurzzeitig genügen, um Drops zu erzeugen.

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

Viele SYN_RECV deuten auf Listen-Backlog/Accept-Probleme; viele TIME_WAIT auf hohen Connection-Churn.

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"

Wenn fs.file-max erreicht oder das per-Process-Limit niedrig ist, scheitern neue Sockets unabhängig von Conntrack.

Conntrack-Engpässe und Socket-Limits: Ursachen und Gegenmaßnahmen

Conntrack-Einträge entstehen durch Verbindungsflüsse, nicht nur durch „echten“ Nutzverkehr. Häufige Treiber sind SNAT-Gateways, Reverse-Proxys mit vielen kurzen Verbindungen, aggressive Health-Checks und Scanner/Discovery. Conntrack-Timeouts verlängern die Lebenszeit eines Eintrags und können die Tabelle füllen.

Gezielte Entlastung

Bevor Sie nf_conntrack_max blind erhöhen, prüfen Sie Alternativen:

• Filter vor Conntrack: Manche Prüfpfade (z. B. internes Monitoring) können mittels NOTRACK/CT‑BYPASS vom Tracking ausgenommen werden, wenn kein NAT oder stateful Matching nötig ist.
• Traffic reduzieren: Health-Check-Intervalle, parallele Scans oder unnötigen Churn einschränken.
• Segmentierung: Mehr Gateways verteilen Conntrack-Last statt eine große gemeinsame Tabelle zu füllen.

Erhöhen Sie nf_conntrack_max nur mit ausreichendem RAM-Headroom; eine große Tabelle belegt Kernel-Speicher und kann bei Überdimensionierung Performance-Probleme verursachen.

Socket-Limits: Backlog, Ephemeral Ports, TIME_WAIT, FD-Limits

Listen-Backlog und somaxconn

Der Listen-Backlog puffert Verbindungen, bis die Applikation sie per accept() verarbeitet. Kernel-Grenzen sind net.core.somaxconn und net.ipv4.tcp_max_syn_backlog. tcp_syncookies schützt vor SYN-Floods, ersetzt jedoch keine ausreichende Kapazität.

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

Ephemeral Ports und Port-Range

Bei vielen Outbound-Connections zu denselben Zielen kann der Portbereich knapp werden. Der Kernel nutzt net.ipv4.ip_local_port_range. Bei NAT kommen zusätzliche Mapping-Limits und Conntrack hinzu.

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

TIME_WAIT: Ursache statt Ziel

Viele TIME_WAIT-Verbindungen sind Folge von Connection-Churn. Nachhaltige Gegenmaßnahmen sitzen meist in Anwendungen: Keep-Alive, Connection-Pooling und weniger aggressive Health-Checks. Kernel-Tuning ist nur zweite Wahl.

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

File-Descriptor-Limits und systemd

In modernen Systemen setzen systemd-Units eigene Limits. Änderungen in einer Shell wirken nicht für Dienste, die von systemd gestartet wurden.

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"

Praktisches Debug-Runbook: Schritt-für-Schritt

Scope bestimmen

Ist es inbound, outbound oder beides? Das steuert die folgenden Prüfungen und möglichen Sofortmaßnahmen.

Hot-Spot-Analyse: Wer erzeugt die Flows?

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

Für präzisere Conntrack-Analyse nutzen Sie die conntrack-tools (conntrack -L), um Flow-Muster und Timeouts zu sehen.

Conntrack-Tools: konkrete Beispiele

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

Warum das hilft: conntrack -L zeigt, welche Flows wie lange in der Tabelle stehen. Das liefert Hinweise auf hohe Timeouts, viele kurze Verbindungen oder eine spezifische Client-/Service-Kombination als Treiber.

Kurzfristige Stabilisierung (mit Risikoabschätzung)

Wenn Ausfall droht, kommen temporäre Maßnahmen in Frage — dokumentiert und mit Rückfallplan:

A) Conntrack temporär erhöhen

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

Wirkung: Reduziert Insert-Fails kurzfristig. Risiko: Höherer Kernel-RAM-Bedarf und nur Verschiebung des Problems bei unvermindertem Churn.

B) Backlog erhöhen

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

Wirkung: Pufferung kurzfristiger Peaks. Risiko: Latenz steigt, wenn die Anwendung tatsächlich zu langsam ist.

C) FD-Limits via systemd setzen

systemctl edit myservice.service

[Service]
LimitNOFILE=200000

systemctl daemon-reload
systemctl restart myservice.service

Wirkung: Verhindert FD-Abbrüche des Dienstes. Risiko: Systemweite fs.file-max muss ebenfalls ausreichen.

Nachhaltige Maßnahmen und Monitoring

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

Conntrack pflegt TCP-spezifische Timeout-Parameter unter /proc/sys/net/netfilter wie nf_conntrack_tcp_timeout_established. Kürzere Timeouts reduzieren die durchschnittliche Tabellenbelegung, können aber TCP-Verkehr beeinträchtigen, z. B. lang laufende Verbindungen abbrechen.

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

Empfehlung: Ändern Sie Timeouts nur nach Analyse und testen Sie mit repräsentativer Last; dokumentieren und automatisieren Sie Rollback.

Bucket-Größe (Hashsize) und NUMA

Die Conntrack-Tabelle wird intern in Buckets/Hash-Tabellen organisiert. Prüfen Sie die aktuelle Einstellung:

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

Bei hoher Last und NUMA-Systemen können falsche Hash-Layouts zu CPU-Contention führen. Eine richtige Abstimmung von nf_conntrack_max und Hashsize kann Lookup-Performance verbessern. Änderungen an Hashsize sind kernel/modul-boot-Parameter und erfordern Reboot oder Modul-Reload.

Kubernetes-spezifika: kube-proxy und node‑Conntrack

In Kubernetes-Umgebungen läuft Conntrack oft auf jedem Node und wird durch kube-proxy / iptables beeinflusst. Limits und Timeouts sind kritisch bei Services mit hoher Pod‑Churn oder kurzen Liveness-Probes. Prüfen Sie:

# 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

Bei Bedarf: kube-proxy kann in ipvs-Mode konfiguriert werden, was andere Performance-Charakteristika hat und Conntrack-Verhalten verändert. Cloud-Anbieter haben außerdem NAT-Gateway-Limits auf Subnetz- oder Account-Ebene; prüfen Sie Provider-Dokumentation.

Monitoring- und Alert-Strategie

Werte, die Sie langfristig sammeln sollten: nf_conntrack_count, nf_conntrack_max, Conntrack-Drops, Verteilung der TCP-Zustände (TIME_WAIT, SYN_RECV, ESTABLISHED), systemweite FD-Auslastung und Applikations‑Errors. Korrelation ist entscheidend.

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

Nutzen Sie Exporter oder node-exporter textfile-collector, falls kein nativer Exporter vorhanden ist.

Testen und Rollout

Canary-Änderungen und Lasttests

Führen Sie Konfigurationsänderungen zunächst auf einem Canary-Node durch. Lasttests können mit realistischem Traffic simuliert werden (z. B. mit wrk, hey oder tcpreplay). Messen Sie Conntrack-Count, CPU-Load und Latenzen während des Tests.

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

Rollback

Jede sysctl-Änderung und jedes systemd-Override sollte in einem Ticket mit Ausgangswerten dokumentiert werden. Rollback ist in der Regel das Entfernen der temporären Konfigurationsdatei und ein sysctl --system oder das Revertieren des systemd-Overrides:

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

Praxis-Stolperfallen

• Änderungen nur in einer Shell setzen statt persistenter Datei: wirkt nicht nach Neustart oder bei Services.
• systemd-Units außer Acht lassen: Shell-ulimit hilft nicht für Services.
• Conntrack erhöhen ohne Ursachenreduktion: Problem verschiebt sich und belastet RAM.
• Backlog hochsetzen ohne Applikationsskaling: Latenzen steigen, Durchsatz nicht.
• Cloud-spezifische NAT-Limits übersehen: Erhöhen der lokalen Conntrack-Tabelle hilft nicht, wenn ein Provider-Gateway limitiert.

Fazit

Conntrack-Engpässe und Socket-Limits sind oft Folge einer Kombination aus Architektur (NAT/Firewall als Shared-Bottleneck), Verbindungsstrategie (zu viele kurze Sessions) und konservativen Systemdefaults. Das richtige Vorgehen ist: systematisch messen, kurzfristig stabilisieren mit dokumentierten, reversiblen Maßnahmen und langfristig am Quellverhalten der Verbindungen arbeiten (Keep-Alive, Pooling, Segmentierung). So wird ein akutes Produktionsproblem in einen kontrollierbaren Betriebsfall verwandelt.

Weiterführende Monitoring- und Alarmtipps

Erfassen Sie dauerhaft: nf_conntrack_count, Conntrack-Drops aus Kernel-Logs, Verteilung der TCP-Zustände (TIME_WAIT, SYN_RECV, ESTABLISHED), FD-Auslastung (/proc/sys/fs/file-nr) und Applikationsmetrikenkopplung (Fehlerquote, Latenz). Korrelation ist entscheidend: Nur so unterscheiden Sie echte Conntrack-Drops von NIC/CPU- oder I/O-bedingten Paketverlusten.

Conntrack-Engpässe: Architektur- und Betriebsaspekte

Jenseits der akuten Messungen entscheiden Architektur und Betriebsorganisation, ob Conntrack- oder Socket‑Limits ein Einmalereignis oder stetige Belastung werden. Drei Praxis‑Perspektiven helfen, strukturiert vorzugehen:

1) Kapazitätsrechnung und Sicherheitsmargen

Conntrack‑Einträge belegen Kernel‑Speicher (typischerweise einige hundert Bytes pro Eintrag). Planen Sie nf_conntrack_max entlang einer einfachen Rechnung: erwartete gleichzeitige Flows × Eintragsgröße + Headroom (min. 25–50%). Nutzen Sie Slab‑/Speicher‑Metriken im Testsystem, um reale Eintragsgrößen zu messen. Änderungen am Hash‑Layout (hashsize) erfordern meist Reboot oder Modul‑Reload und sollten in Wartungsfenstern erfolgen.

2) Architekturmuster zur Entlastung

Verteilen statt vergrößern: SNAT/Conntrack lässt sich horizontal skalieren, indem Sie mehrere SNAT‑IPs oder dedizierte NAT‑Gateways einsetzen. Alternativ reduziert ein L4‑Loadbalancer mit Direct‑Server‑Return oder ein Proxy mit persistenten Keep‑Alive‑Verbindungen die Anzahl kurzer Flows. In Cloud‑Setups prüfen Sie Provider‑NAT‑Limits — lokale Tuningmaßnahmen greifen dort nicht.

3) Operative Kontrolle und Observability

Richten Sie Alerts mit proportionalen Schwellwerten (z. B. 70/85/95 % Auslastung) und korrelieren Sie Conntrack‑Metriken mit Applikationslatenz und FD‑Usage. Für tieferes Verständnis lohnt sich kurzfristig eBPF‑Tracing: es misst Connection‑Churn ohne die Conntrack‑Tabelle selbst zu belasten. Jede Konfigurationsänderung gehört ins Change‑Ticket, mit Canary, Metrik‑Gates und dokumentiertem Rollback, denn Performance‑Tuning kann Speicher‑ oder NUMA‑Seitenwirkungen hervorrufen.

Diese betrieblichen und architektonischen Hebel machen aus punktuellen Fixes nachhaltige Lösungen: weniger akute Engpässe, kontrollierbares Wachstum und klarere Verantwortlichkeiten zwischen Netz, Plattform und der betreibenden Anwendung.

Für dieses Thema sind auch Nf_Conntrack Table Full wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.