Persistente nf_conntrack_max durante il riavvio

10

In /procho due voci per nf_conntrack_max:

/ Proc / sys / net / netfilter / nf_conntrack_max
/ Proc / sys / net / nf_conntrack_max

Sembra che puntare allo stesso valore del cambiare l'uno cambia anche l'altro. Con entrambi questi set in /etc/sysctl.conf:

net.netfilter.nf_conntrack_max = 65528
net.ipv4.netfilter.ip_conntrack_max = 65535

Il valore rimane 32764 dopo il riavvio, quindi le modifiche non funzionano. È già successo a qualcuno? La mia ipotesi sarebbe che questi valori vengano applicati prima che vengano caricati i moduli rilevanti, ma speravo che qualcuno conoscesse già la soluzione.

— Kyle Brandt
fonte

Hai mai trovato una soluzione a questo?

— Stu Thompson,

@Stu: No, sono appena diventato pigro e ho scritto un lavoro cron per impostare questi :-P

— Kyle Brandt

11

è perché /proc/sys/net/nf_conntrack_maxsi basa sul modulo nf_conntrack. ma questo modulo non verrà caricato di default all'avvio del sistema.

ma se corri

iptables -t nat -L

o

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

questo modulo verrà caricato automaticamente e impostato sul numero massimo supportato dal sistema (il numero massimo è 65536 se il ram è> 4G, ma varia a seconda del sistema.) è possibile impostarlo su un numero più grande (come 6553600) in /etc/sysctl.conf) .

Soluzione :

aggiungi una riga alla fine del file /etc/modules:

nf_conntrack

questi moduli verrebbero caricati all'avvio del sistema prima di essere sysctleseguiti.

— Ethan Xu
fonte

grazie :) - anche se ho avuto anche una cattiva configurazione che ha impedito il caricamento

— Christian

3

Perché dovrebbe essere:

net.netfilter.nf_conntrack_max = 65535

E ora puoi impostarlo senza riavviare con: sysctl -p /etc/sysctl.conf

— Maciej Lasyk
fonte

2

Non uso Ubuntu, ma pensando a questo nel mio stato d'animo CentOS, ho avuto la stessa ipotesi che hai fatto tu: i sistemi sono stati applicati troppo presto. Alcune ricerche hanno rivelato che questo è stato un bug archiviato dal 2006 .

Sembra che inserire un altro link simbolico in priorità> S40 per eseguire nuovamente lo script procps init farebbe probabilmente quello di cui hai bisogno. In base al riassunto dei bug, sembra che sia in corso una riprogettazione della metodologia sysctl di Ubuntu (e, in modo divertente, il bug è stato assegnato a qualcuno che non sapeva che era stato assegnato e non può farci nulla).

— Evan Anderson
fonte