Depurar cuellos de botella de conntrack y límites de sockets en entornos con alto número de conexiones TCP

Cuando en un entorno de hosting de repente fallan nuevas conexiones TCP o los clientes reportan timeouts masivos, la pregunta correcta rara vez es «¿por qué se cae la app?» sino «¿qué tipo de límite del sistema está impidiendo las conexiones?». En este runbook práctico aprende a depurar cuellos de botella de Conntrack y límites de sockets: rutas de comprobación rápidas para formular hipótesis, puntos de medida fiables, causas típicas y correcciones seguras con estrategia de reversión. Público objetivo: administradores, Ingenieros de Sistemas y operadores en entornos de hosting/cloud.

Depurar Conntrack y límites de sockets: breve orientación terminológica

Conntrack (Connection Tracking) es un subsistema del kernel que gestiona los flujos de red como objetos de estado. Se utiliza para NAT (Source/Destination NAT) y para firewalling stateful (Netfilter). Los puertos efímeros son los puertos de origen dinámicos para conexiones salientes; su rango está definido por net.ipv4.ip_local_port_range. Los socket-backlogs (listen-backlog) encolan nuevas conexiones hasta que la aplicación las procesa con accept(); el límite del kernel se controla mediante net.core.somaxconn. TIME_WAIT es un estado TCP tras el cierre que mantiene los puertos ocupados temporalmente.

Síntomas y su primera clasificación

Compruebe primero: ¿el problema ocurre inbound (los clientes no alcanzan el servicio), outbound (el host no puede establecer conexiones salientes) o en ambos sentidos?

Clases de síntomas típicas

• Conntrack lleno: el registro del kernel informa „nf_conntrack: table full, dropping packet“; el tráfico NAT se interrumpe.
• Problemas SYN/Backlog: muchos SYN_RECV, los clientes registran timeouts; la aplicación no acepta con suficiente rapidez.
• Cuello de botella de puertos efímeros: las conexiones salientes fallan con „cannot assign requested address“; muchos TIME_WAIT.
• Límites de FD: procesos informan „too many open files“; el sistema alcanza fs.file-max o el límite por proceso Max open files es demasiado bajo.

En 10 minutos hacia una hipótesis fiable

La siguiente secuencia separa la medición del cambio y proporciona rápidamente una orientación.

1) Registros del kernel y búsqueda inicial

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“ es un indicador contundente de Conntrack; otros patrones de error requieren contadores adicionales.

2) Medir ocupación de 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

Si nf_conntrack_count permanece de forma sostenida cerca de nf_conntrack_max, la tabla es el cuello de botella. Picos breves pueden bastar para provocar descartes.

3) Estados TCP y 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

Muchos SYN_RECV indican problemas de listen-backlog/accept; muchos TIME_WAIT indican una alta rotación de conexiones.

4) Límites de descriptores de archivo y de procesos

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

Si se alcanza fs.file-max o el límite por proceso es bajo, los sockets nuevos fallan independientemente de Conntrack.

Cuellos de botella de conntrack y límites de sockets: causas y contramedidas

Las entradas de conntrack se generan por flujos de conexiones, no solo por tráfico de usuario „real“. Impulsores frecuentes son gateways SNAT, reverse proxies con muchas conexiones cortas, Health-Checks agresivos y escáneres/descubrimiento. Los timeouts de conntrack prolongan la vida útil de una entrada y pueden llenar la tabla.

Alivio dirigido

Antes de aumentar a ciegas nf_conntrack_max, pruebe alternativas:

• Filtros antes de conntrack: Algunos caminos de comprobación (p. ej. monitorización interna) pueden excluirse del tracking mediante NOTRACK/CT‑BYPASS, si no se requiere NAT ni stateful matching.
• Reducir tráfico: Limitar intervalos de Health-Checks, escaneos paralelos o churn innecesario.
• Segmentación: Más gateways distribuyen la carga de conntrack en lugar de llenar una única tabla compartida.

Aumente nf_conntrack_max únicamente con suficiente margen de RAM; una tabla grande ocupa memoria del kernel y, si está sobredimensionada, puede causar problemas de rendimiento.

Límites de sockets: Backlog, Ephemeral Ports, TIME_WAIT, FD-Limits

Listen-Backlog y somaxconn

El listen-backlog almacena en búfer conexiones hasta que la aplicación las procesa con accept(). Los límites del kernel son net.core.somaxconn y net.ipv4.tcp_max_syn_backlog. tcp_syncookies protege contra SYN-Floods, pero no sustituye una capacidad adecuada.

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

Puertos efímeros y rango de puertos

Con muchas conexiones salientes hacia los mismos destinos el rango de puertos puede agotarse. El kernel utiliza net.ipv4.ip_local_port_range. Con NAT entran en juego límites adicionales de mapeo y conntrack.

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

TIME_WAIT: causa, no objetivo

Muchas conexiones en TIME_WAIT son consecuencia del churn de conexiones. Las contramedidas sostenibles suelen estar en las aplicaciones: Keep-Alive, Connection-Pooling y Health-Checks menos agresivos. El ajuste del kernel es solo la segunda opción.

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

Límites de descriptores de archivos y systemd

En sistemas modernos las unidades systemd establecen sus propios límites. Los cambios en una shell no afectan a los servicios iniciados por 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 práctico de depuración: paso a paso

Determinar el alcance

¿Se trata de tráfico entrante, saliente o ambos? Eso condiciona las comprobaciones siguientes y las posibles medidas inmediatas.

Análisis de puntos calientes: ¿quién genera los flujos?

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

Para un análisis de conntrack más preciso utilice las conntrack-tools (conntrack -L) para ver patrones de flujo y timeouts.

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

Por qué ayuda: conntrack -L muestra qué flujos y durante cuánto tiempo permanecen en la tabla. Esto aporta indicios sobre tiempos de espera altos, muchas conexiones cortas o una combinación cliente/servicio específica como causa.

Estabilización a corto plazo (con evaluación de riesgos)

Si existe riesgo de fallo, se pueden considerar medidas temporales — documentadas y con plan de reversión:

A) Aumentar temporalmente 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

Efecto: Reduce temporalmente los Insert-Fails. Riesgo: mayor consumo de RAM del kernel y solo desplazamiento del problema si el churn no disminuye.

B) Aumentar el 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

Efecto: Amortigua picos puntuales. Riesgo: la latencia aumenta si la aplicación es realmente lenta.

C) Establecer FD-Limits vía systemd

systemctl edit myservice.service

[Service]
LimitNOFILE=200000

systemctl daemon-reload
systemctl RESTart myservice.service

Efecto: Evita que el servicio agote descriptores FD. Riesgo: el límite global del sistema fs.file-max también debe ser suficiente.

Medidas sostenibles y monitorización

Comprobar y ajustar los timeouts de Conntrack (con precaución)

Conntrack mantiene parámetros de timeout específicos de TCP bajo /proc/sys/net/netfilter como nf_conntrack_tcp_timeout_established. Timeouts más cortos reducen la ocupación media de la tabla, pero pueden afectar al tráfico TCP, por ejemplo interrumpiendo conexiones de larga duración.

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

Recomendación: Modifique los timeouts solo tras análisis y pruebe con carga representativa; documente y automatice el rollback.

Tamaño de buckets (Hashsize) y NUMA

La tabla Conntrack se organiza internamente en buckets/tablas hash. Compruebe la configuración actual:

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

Con alta carga y sistemas NUMA, un diseño de hash inadecuado puede provocar contention de CPU. Un ajuste correcto de nf_conntrack_max y Hashsize puede mejorar el rendimiento de las búsquedas. Los cambios en Hashsize son parámetros de arranque del kernel/módulo y requieren reinicio o recarga del módulo.

Específicos de Kubernetes: kube-proxy y node‑Conntrack

En entornos Kubernetes, Conntrack suele ejecutarse en cada nodo y se ve afectado por kube-proxy / iptables. Los límites y los timeouts son críticos en servicios con alta rotación de pods o sondas de liveness cortas. Compruebe:

# 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

Si es necesario: kube-proxy puede configurarse en modo ipvs, lo que presenta otras características de rendimiento y altera el comportamiento de conntrack. Los proveedores cloud también tienen límites de NAT-Gateway a nivel de subred o de cuenta; consulte la documentación del proveedor.

Estrategia de monitorización y alertas

Métricas que debe recopilar a largo plazo: nf_conntrack_count, nf_conntrack_max, rechazos de conntrack, distribución de los estados TCP (TIME_WAIT, SYN_RECV, ESTABLISHED), uso de FD a nivel de sistema y errores de la aplicación. La correlación es decisiva.

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

Utilice un exporter o el textfile-collector de node-exporter si no dispone de un exporter nativo.

Pruebas y despliegue

Cambios canary y pruebas de carga

Realice los cambios de configuración primero en un nodo canario. Las pruebas de carga pueden simularse con tráfico realista (p. ej., con wrk, hey o tcpreplay). Mida el conteo de conntrack, la carga de CPU y las latencias durante la prueba.

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

Reversión

Cada cambio de sysctl y cada override de systemd debe documentarse en un ticket con los valores iniciales. La reversión normalmente consiste en eliminar el archivo de configuración temporal y ejecutar sysctl --system o revertir el override de 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

Trampas comunes en la práctica

• Hacer cambios solo en una shell en lugar de en un archivo persistente: no surte efecto tras un reinicio ni para los servicios.
• Pasar por alto las unidades systemd: el ulimit de la shell no sirve para los servicios.
• Aumentar conntrack sin reducir las causas: el problema se desplaza y consume RAM.
• Incrementar el backlog sin escalar la aplicación: las latencias aumentan, el rendimiento no.
• Pasar por alto los límites NAT específicos del cloud: aumentar la tabla conntrack local no ayuda si el gateway del proveedor está limitado.

Conclusión

Los cuellos de botella por conntrack y los límites de sockets son a menudo consecuencia de una combinación de arquitectura (NAT/firewall como cuello de botella compartido), estrategia de conexión (demasiadas sesiones cortas) y valores por defecto conservadores del sistema. El enfoque correcto es: medir sistemáticamente, estabilizar a corto plazo con medidas documentadas y reversibles, y trabajar a largo plazo sobre el comportamiento origen de las conexiones (Keep-Alive, pooling, segmentación). Así se convierte un problema agudo en producción en un caso operativo controlable.

Consejos adicionales de monitorización y alertas

Registre de forma permanente: nf_conntrack_count, descargas de conntrack a partir de los logs del kernel, distribución de los estados TCP (TIME_WAIT, SYN_RECV, ESTABLISHED), uso de FD (/proc/sys/fs/file-nr) y acoplamiento de métricas de la aplicación (tasa de errores, latencia). La correlación es crucial: solo así distinguirá las verdaderas pérdidas por conntrack de pérdidas de paquetes debidas a NIC/CPU o I/O.

Cuellos de botella de conntrack: aspectos de arquitectura y operación

Más allá de las mediciones puntuales, la arquitectura y la organización operativa determinan si los límites de conntrack o de sockets son un evento aislado o una carga sostenida. Tres perspectivas prácticas ayudan a abordar el problema de forma estructurada:

1) Cálculo de capacidad y márgenes de seguridad

Las entradas de conntrack ocupan memoria del kernel (típicamente unos cientos de bytes por entrada). Dimensione nf_conntrack_max siguiendo un cálculo simple: flujos simultáneos esperados × tamaño de entrada + margen (mín. 25–50 %). Use métricas de slab/memoria en el sistema de prueba para medir tamaños reales de entrada. Los cambios en el esquema de hash (hashsize) suelen requerir reinicio o recarga del módulo y deben realizarse en ventanas de mantenimiento.

2) Patrones de arquitectura para aliviar la carga

Distribuir en lugar de aumentar: SNAT/Conntrack se puede escalar horizontalmente implantando múltiples IPs SNAT o gateways NAT dedicados. Alternativamente, un balanceador L4 con Direct Server Return o un proxy con conexiones Keep‑Alive persistentes reduce el número de flujos cortos. En despliegues en la nube, verifique los límites de NAT del proveedor: las medidas de ajuste locales no tienen efecto allí.

3) Control operativo y observabilidad

Configure alertas con umbrales proporcionales (p. ej. 70/85/95 % de uso) y correlacione las métricas de conntrack con la latencia de la aplicación y el uso de FD. Para un entendimiento más profundo, merece la pena realizar trazado eBPF a corto plazo: mide la rotación de conexiones sin cargar la propia tabla de conntrack. Todo cambio de configuración debe registrarse en un ticket de cambio, con despliegue canario, puertas de métricas y rollback documentado, ya que el tuning de rendimiento puede provocar efectos en la memoria o en las zonas NUMA.

Estas palancas operativas y arquitectónicas transforman las soluciones puntuales en soluciones sostenibles: menos cuellos de botella agudos, crecimiento controlable y responsabilidades más claras entre red, plataforma y la aplicación en explotación.

Para este tema también son importantes los Nf_Conntrack Table Full. El artículo sitúa estos aspectos de forma comprensible y muestra en qué fijarse en el día a día.