Persistindo nf_conntrack_max entre reinicializações

10

Em /proceu tenho duas entradas para nf_conntrack_max:

/ proc / sys / net / netfilter / nf_conntrack_max
/ proc / sys / net / nf_conntrack_max

O parece apontar para o mesmo valor que alterar um também muda o outro. Com ambos configurados em /etc/sysctl.conf:

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

O valor permanece 32764 após uma reinicialização para que as alterações não estejam funcionando. Alguém já se deparou com isso antes? Meu palpite seria que esses valores sejam aplicados antes que os módulos relevantes sejam carregados, mas espero que talvez alguém já conheça a solução.

— Kyle Brandt
fonte

Você já encontrou uma solução para isso?

— Stu Thompson

@Stu: Não, eu só tenho preguiça e escreveu um trabalho cron para definir estes :-P

— Kyle Brandt

11

é porque /proc/sys/net/nf_conntrack_maxdepende do módulo nf_conntrack. mas este módulo não será carregado por padrão quando o sistema for iniciado.

mas se você correr

iptables -t nat -L

ou

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

este módulo será carregado automaticamente e definido como o número máximo que o seu sistema suporta (o número máximo é 65536 se você ram for> 4G, mas varia em diferentes sistemas.) você pode configurá-lo para um número maior (como 6553600) em /etc/sysctl.conf) .

Solução :

adicione uma linha no final do arquivo /etc/modules:

nf_conntrack

esses módulos seriam carregados na inicialização do sistema antes de serem sysctlexecutados.

— Ethan Xu
fonte

obrigado :) - embora eu também tivesse uma configuração ruim, o que o impediu de carregar #

— Christian

3

Porque deveria ser:

net.netfilter.nf_conntrack_max = 65535

E agora você pode definir isso sem reiniciar com: sysctl -p /etc/sysctl.conf

— Maciej Lasyk
fonte

2

Não uso o Ubuntu, mas, pensando nisso no meu estado de espírito do CentOS, cheguei à mesma hipótese que você - os sysctls estão sendo aplicados muito cedo. Algumas pesquisas revelaram que esse é um erro registrado desde 2006 .

Parece que colocar outro link simbólico na prioridade> S40 para executar o script init procps novamente provavelmente faria o que você precisa. De acordo com o resumo do bug, parece que alguma re-arquitetura da metodologia sysctl do Ubuntu está em ordem (e, divertidamente, o bug foi atribuído a alguém que não sabia que estava atribuído e não pode ajudá-lo).

— Evan Anderson
fonte