ip_conntrack Probleme

Technik Infrastruktur / Backbone
1

Fortsetzung der Diskussion von Admintagebuch - Dokumentation der Admintätigkeiten:

Habe gerade was in dem Freifunk-Franken-Wiki gefunden:

zusätzlich kann das unnötig lange Timeout verringert werden um den conntrack count schon von Grund auf kleiner zu halten:

vi /etc/sysctl.conf // Am Ende einfügen
net.ipv4.netfilter.ip_conntrack_generic_timeout = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 54000

bzw. die Werte sofort setzen:

sysctl -w net.ipv4.netfilter.ip_conntrack_generic_timeout=120
sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=54000

Quelle

2 „Gefällt mir“
2

Conntrack Timeout (drastisch) runterzusetzen ist keine gute Idee da dann TCP Session kaputtgehen.
Die absolute Zahl sollte ruhig mal 0.5 Mio sein, da wäre die Tabelle (je nachdem wo man schaut) rund 300Mb groß was IMHO problemlos ist und uns dies Problem (das wir spät die Nutzer aber früh merken) wohl vom Hals.

Ich glaube man kann den conntrack count irgendwo auch ganz abschalten, sollten >wir uns mal überlegen.

Ja, dann gibts aber kein NAT mehr.

3

Falsch ausgedrückt, ich meinte das maximale limit. Man kann irgendwo sagen, nimm so viele Verbindungen an, bis du tot umfällst. :stuck_out_tongue: (wohl doch nicht)

Sehe ich auch so. Wir können schauen, was das derzeitige Timeout ist, wenn es mehrere Tage beträgt, können wir es ja ein bisschen runter drehen.

4

Defaulteinstellungen findet man u. a. hier.

https://www.kernel.org/doc/Documentation/networking/nf_conntrack-sysctl.txt

5

Ich sehe keinen Grund am Timeout zu drehen da ich davon ausgehe das wir ohne Probleme 300MB dafür spendieren können.

6

Default ist 5 Tage.
Da kann sich bei einem Abriss der PHY durchaus was zusammensammeln.
Ich würde das keinesfalls kürzer als 24h machen, alles andere würde ich für “kaputt” halten :wink:

7

Testweise mal auf 3 Tage und schauen ob es ne Erleichterung bringt. Weiter runter kann man ja noch immer; unter 24 Stunden sollte man aber wirklich nicht gehen.

3 „Gefällt mir“
8

Ich habe heute mal auf den bb-servern geschaut, welche Clients am häufigsten in der ip_conntrack Liste stehen: Einige wenige Clients haben über 1000 Einträge. Diese befinden sich in Domäne-09 und routen über c1024 (interessant: auf c1024 wächst kontinuierlich die größe der conntrack liste, auf des1 ist sie stabil). Ich “forsche” noch ein bisschen…

Wir sollten dennoch die ansible Rolle für die Erhöhung der Limits auch auf den gateways ausrollen. Da wir nun die Daten in graphite erfassen, können wir hier auch ein Auge auf ungute Entwicklungen haben (diese option sollte auf den GWs ebenfalls aktiviert werden).

Auszug aus ip_conntrack auf greyworm-06 (Muster: Count Value):

Einträge TCP:

root@greyworm-06 ~ # cat /proc/net/ip_conntrack | grep tcp | sed -r "s/.*src=(10[[:digit:]\.]+).*src.*/\1/g" | sort | uniq -c | sort -n | tail
    129 10.43.xx.xx
    129 10.43.xx.xx
    132 10.43.xx.xx
    136 10.43.xx.xx
    137 10.43.xx.xx
    146 10.43.xx.xx
    156 10.43.xx.xx
    158 10.43.xx.xx
    194 10.43.xx.xx
    311 10.43.xx.xx

Einträge UDP:

root@greyworm-06 ~ # cat /proc/net/ip_conntrack | grep udp | sed -r "s/.*src=(10[[:digit:]\.]+).*src.*/\1/g" | sort | uniq -c | sort -n | tail
      6 10.43.xx.xx
      6 10.43.xx.xx
      7 10.43.xx.xx
      7 10.43.xx.xx
      8 10.43.xx.xx
      9 10.43.xx.xx
     11 10.43.xx.xx
     30 10.43.xx.xx
    501 10.43.xx.xx
    930 10.43.xx.xx

dest-Ports des Hosts mit den meisten Einträgen:

root@greyworm-06 ~ # cat /proc/net/nf_conntrack | grep 10.43.xx.xx | sed -r "s/.*dport=([[:digit:]]+).*dport.*/\1/g" | sort | uniq -c | sort -n | tail
      6 8999
      7 40500
      8 49001
      8 53903
     10 11101
     19 50321
     24 6889
     53 51413
    100 53
    112 6881
1 „Gefällt mir“
9

Oft führen Clients mit Schadsoftware IP-Scanns durch um den Schaden weiter zu verbreiten. Diese fallen eben in der conntrack Tabelle auf. Solche Clients müssen isoliert und informiert werden.

Wenn man Pech hat fühlen sich Angegriffene zu DDOS Attacken genötigt.

1 „Gefällt mir“
10

Ich habe mir gerade mal die TCP Einträge der ip_conntrack Tabelle angeschaut (UDP hat einen zu vernachlässigenden Anteil) und nach Zuständen der TCP (finite) state machine sortiert und gezählt:

Auffallend sind die doch recht vielen Verbindungen im TIME_WAIT state auf c1024.

c1024:

root@c1024 ~ # cat /proc/net/ip_conntrack | grep "^tcp" | sed -r "s/.* ([[:alpha:]_]+) src=.*/\1/g" | sort | uniq -c | sort -n
     67 FIN_WAIT
    216 SYN_RECV
    321 LAST_ACK
    425 CLOSE
    478 SYN_SENT
    737 CLOSE_WAIT
   7536 TIME_WAIT
  14158 ESTABLISHED

des1:

root@des1 ~ # cat /proc/net/ip_conntrack | grep "^tcp" | sed -r "s/.* ([[:alpha:]_]+) src=.*/\1/g" | sort | uniq -c | sort -n
      4 FIN_WAIT
      8 SYN_RECV
     29 SYN_SENT
     32 CLOSE
     32 LAST_ACK
     55 CLOSE_WAIT
    399 TIME_WAIT
  21938 ESTABLISHED

Dazu die Konfiguration der TCP Timeouts:

c1024:

root@c1024 ~ # sysctl -a | grep "^net\.ipv4\.netfilter\.ip_conntrack_tcp_"
net.ipv4.netfilter.ip_conntrack_tcp_be_liberal = 0
net.ipv4.netfilter.ip_conntrack_tcp_loose = 1
net.ipv4.netfilter.ip_conntrack_tcp_max_retrans = 3
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close = 10
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 432000
net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_last_ack = 30
net.ipv4.netfilter.ip_conntrack_tcp_timeout_max_retrans = 300
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent2 = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120

des1:

root@des1 ~ # sysctl -a | grep "^net\.ipv4\.netfilter\.ip_conntrack_tcp_"
net.ipv4.netfilter.ip_conntrack_tcp_be_liberal = 0
net.ipv4.netfilter.ip_conntrack_tcp_loose = 1
net.ipv4.netfilter.ip_conntrack_tcp_max_retrans = 3
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close = 10
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 432000
net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_last_ack = 30
net.ipv4.netfilter.ip_conntrack_tcp_timeout_max_retrans = 300
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent2 = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120

Diese sind identisch. Ich gehe also nun der Vermutung nach, dass es einen Störer (innerhalb oder außerhalb des Freifunknetzes) gibt. Natürlich ist ein Konfigurationsfehler weiterhin nicht ausgeschlossen.

11

Also ein moderner Desktop mit Foo kann 100+ Connections offen haben.
Mit nem aktiven Torrent Client auch locker über 1k . Das ist erstmal keine Störung.

Können wir die Conntrack Einträge nicht einfach mal ordentlich hcohsetzen, so auf 500k? Memory dafür sind glaube ich ~300Mb.

12

Wir sind derzeit bei 256k, kann das gerne noch mal verdoppeln. Jedoch zeigt sich eine kontinuierliche Zunahme der Einträge auf c1024. In Kombination mit doch recht vielen Einträgen im Zustand TIME_WAIT (darauf war die Vermutung einer Störung bezogen) sollten wir uns das dennoch anschauen.

(Anders als von @paulinsche angenommen, lassen die Daten aus meinem Posting von gestern Abend in der Tat eher auf Torrent schließen, als auf einen Störer.)

13

Wäre dann dafür das einerseits zu verdoppeln und
das Timeout zu reduzieren.
nf_conntrack_tcp_timeout_time_wait = 60
nf_conntrack_tcp_timeout_established = 86400

1 „Gefällt mir“
14

Werte wie gewünscht umgesetzt und auf den BB-Servern ausgerollt.

Grafana Stats.

2 „Gefällt mir“
15

+1 für weiter erhöhen, RAM haben wir.