Linux Conntrack Kapasite Planlama ve Alarm Runbook’u

Conntrack sorunu, çoğu ekipte “bir anda her şey koptu” diye yaşanır. Gerçekte ise sinyal hep vardır: tablo doluluğu yükselir, yeni bağlantılar düşmeye başlar, uygulama retry üretir ve incident büyür.

Bu yazı, Linux conntrack için kapasite planlama + alarm + olay runbook bütününü verir. Hedef; “tablo doldu” anına gelmeden, operasyonel olarak yönetilebilir bir model kurmaktır.

Conntrack neden kritik?

Stateful firewall/NAT kullanan her yerde conntrack, görünmez bir “tekil kaynak” olur:

• L4 load balancer / reverse proxy
• NAT gateway / egress node
• Kubernetes node’ları (overlay + service NAT)
• Edge sunucular (nftables/iptables)

Tablo dolunca tipik semptomlar:

• Yeni TCP bağlantıları kurulamıyor
• UDP “sessizce” kayboluyor
• Uygulama “hizmet var ama çalışmıyor” davranışına giriyor

Ölç: tablo doluluk ve drop sinyali

En temel iki metrik:

cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

Hızlı oran:

python - <<'PY'
import pathlib
count=int(pathlib.Path("/proc/sys/net/netfilter/nf_conntrack_count").read_text().strip())
mx=int(pathlib.Path("/proc/sys/net/netfilter/nf_conntrack_max").read_text().strip())
print(f"conntrack_utilization={(count/mx)*100:.1f}% ({count}/{mx})")
PY

Kernel log sinyali (kritik):

dmesg -T | rg -n "nf_conntrack: table full|conntrack" || true

Eğer “table full” görüyorsan, artık düşürmeye başlamışsın demektir.

Alarm tasarımı (saha eşiği)

Ben sahada üç eşik kullanıyorum:

• %70: trend alarmı (artış var mı?)
• %85: aksiyon alarmı (mitigation hazırlığı)
• %95: kritik (incident komutası + trafik azaltma)

Kapasite planlama: “kaç bağlantı normal?”

Conntrack kapasitesi, sadece “RAM var mı?” değil; bağlantı profili ile ilgilidir:

• Ortalama bağlantı ömrü (keep-alive, long polling)
• UDP timeouts (DNS, syslog, VoIP)
• NAT arkasında client sayısı (burst)
• DDoS / scan davranışı (kötü niyet)

Pratik ölçüm (top 20 konuşan):

sudo conntrack -S 2>/dev/null || true
sudo conntrack -L 2>/dev/null | head -n 5 || true

Conntrack aracı yoksa:

ss -s
ss -ant state established | wc -l

Güvenli ayar: nf_conntrack_max ve timeouts

İlk kural: sadece max’i yükseltmek çoğu zaman sorunu gizler. Yine de doğru yaparsan rahatlatır.

Örnek (geçici):

sudo sysctl -w net.netfilter.nf_conntrack_max=524288

Kalıcı yapmak için:

• /etc/sysctl.d/99-conntrack.conf içine yaz
• değişikliği change kaydıyla yönet

Timeout tarafı daha etkilidir (özellikle UDP):

sudo sysctl -a | rg "nf_conntrack_(tcp|udp)_" | head

Olay Runbook’u: tablo dolmaya gidiyorsa

1) Triage (5 dk)

date
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max
dmesg -T | tail -n 120
ss -s

Sor:

• Bu node NAT mı yapıyor? (egress / LB / gateway)
• Trafik “meşru mu, anomali mi”?
• Bir deploy/feature yeni connection davranışı üretti mi?

2) Containment: ilk güvenli hamleler

• Kötü niyet/scan şüphesi: edge’de rate-limit / synproxy / upstream filtreleme
• Meşru trafik: yeni connection üreten bileşenleri azalt (ör. worker sayısı), keep-alive ayarlarını gözden geçir
• Node bazlı: trafik yönlendirmeyi kaydır (LB weight düşür / drain)

3) Geçici rahatlatma (kontrollü)

• nf_conntrack_max yükseltmek (RAM ölçerek)
• UDP timeout’ları küçük adımlarla ayarlamak

Değişiklikten sonra doğrulama:

watch -n 2 'echo -n "count="; cat /proc/sys/net/netfilter/nf_conntrack_count; echo -n "max="; cat /proc/sys/net/netfilter/nf_conntrack_max'

4) Geri dönüş standardı

Conntrack incident’larında en sık yapılan hata: geçici artırımı kalıcı bırakmak.

Runbook standardı:

• 24–48 saat içinde kök neden ve kalıcı aksiyon
• Geçici sysctl’ler için “expire” notu
• Retrospektifte “bağlantı profili” grafiği

Postmortem checklist (kalıcı çözüm)

• Uygulama: keep-alive, connection pool, retry budget, timeouts
• Edge: SYN flood dayanıklılığı, rate-limit, WAF/IDS sinyali
• Platform: drain/evacuation akışı, per-node conntrack alarmları
• Güvenlik: scan/abuse tespiti, otomatik kara liste / upstream koordinasyon

Sonuç

Conntrack, ağın görünmez kapasite limitidir. Yönetilebilir model; ölçüm + alarm + kontrollü müdahale üçlüsüdür. “Table full” logunu görmek, aslında alarmı kaçırdığın anlamına gelir; hedef, o logu üretmeden önce müdahale edebilmektir.