Dzięki ale nie widzę tu zmiennych odpowiedzialnych za czas pamiętania połączeń
nie wiem jakie masz jadro 2.4.x . Ja w 2.4.27 mam : net.ipv4.netfilter.ip_conntrack_generic_timeout = 600 net.ipv4.netfilter.ip_conntrack_icmp_timeout = 30 net.ipv4.netfilter.ip_conntrack_udp_timeout_stream = 180 net.ipv4.netfilter.ip_conntrack_udp_timeout = 30 net.ipv4.netfilter.ip_conntrack_tcp_timeout_close = 10 net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120 net.ipv4.netfilter.ip_conntrack_tcp_timeout_last_ack = 30 net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60 net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120 net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 172800 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_buckets = 1023 net.ipv4.netfilter.ip_conntrack_max = 65535
może tak ale na stronie netfilter zalecaną ilością połączeń jest 8192 dla 128Mpamięci serwera zresztą wyczytałem że jedno połączenie to 350 bajtów z prostej kalkulacji wynika że przy zalecanej przez ciebie ilości wielkość bufora wyniesie 10 MB a mój serwer oprócz natu dla ok 30 klientów chodzi jeszcze apache z php poczta baza danych mysql squid i ftp, samba pełniącarolę kontrolera domeny i kilka kont shelowych więc trochę pamięci powinno mipozostać Dostęp do serwera mam zdalny więc wolałbym uniknąć kompilacji kernela a jak na razie to nie widzę sposobu aby tego uniknąć. Pamiętanie połączeń przez 5 dni jest dosyć na wyrost bo żaden z klientów nie chodzi dłużej niż kilka godzin więc te 7168 to wcale nie było by za mało gdyby wszystkie połączenia były zamykane lecz nie zawsze tak jest (myślę że winę ponosi tu kazza i ine programy tego typu).
Mysle ze jak ustawisz conntrack na 16k to nic sie nie stanie Twojemu systemowi.
Zawsze mozesz poprobowac i ew. wrocic do pierwotnyh ustawien . jezeli nie .... pozostaje Ci connlimit ewentualnie calkowite "wycięcie" p2p. pozdrawiam c.s