Question Persistance de nf_conntrack_max lors des redémarrages


Dans /proc J'ai deux entrées pour nf_conntrack_max:

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

Cela semble indiquer la même valeur que de changer l’un change l’autre. Avec ces deux mis en /etc/sysctl.conf:

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

La valeur reste 32 764 après un redémarrage afin que les modifications ne fonctionnent pas. Quelqu'un a-t-il déjà couru ça? Je suppose que ces valeurs sont appliquées avant le chargement des modules pertinents, mais j'espérais que quelqu'un connaît peut-être déjà la solution.


8
2017-07-18 12:32


origine


Avez-vous déjà trouvé une solution à cela? - Stu Thompson
@Stu: Nope, je viens d'être paresseux et j'ai écrit un travail cron pour définir ceci :-P - Kyle Brandt♦


Réponses:


c'est parce que /proc/sys/net/nf_conntrack_max est s'appuyer sur le module nf_conntrack. mais ce module ne sera pas chargé par défaut au démarrage du système.

mais si tu cours

iptables -t nat -L

ou

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

ce module se chargera automatiquement et définira le nombre maximal pris en charge par votre système (le nombre maximal est 65536 si votre RAM est> 4G, mais cela varie selon les systèmes.) Vous pouvez le définir sur un nombre plus important (comme 6553600) dans /etc/sysctl.conf).

Solution:

ajouter une ligne à la fin du fichier /etc/modules:

nf_conntrack

ces modules seraient chargés au démarrage du système avant sysctl réalisé.


9
2018-03-19 14:07



merci :) - bien que j'ai aussi eu une mauvaise configuration qui a arrêté le chargement - Christian


Parce que ça devrait être:

net.netfilter.nf_conntrack_max = 65535

Et maintenant, vous pouvez régler ceci sans redémarrer avec: sysctl -p /etc/sysctl.conf


2
2017-07-20 10:57





Je n'utilise pas Ubuntu, mais en pensant à cela dans mon état d'esprit CentOS, j'ai émis la même hypothèse que celle que vous avez utilisée: les systèmes sont appliqués trop tôt. Certaines recherches ont révélé qu'il s'agissait d'une bug déposé depuis 2006.

Il semble que placer un autre lien symbolique avec une priorité supérieure à> S40 afin de réexécuter le script init de procps ferait probablement ce dont vous avez besoin. D'après le résumé du bogue, il semble qu'une nouvelle architecture de la méthodologie sysctl d'Ubuntu soit en ordre (et, curieusement, le bogue a été attribué à quelqu'un qui ne savait pas qu'il avait été attribué et ne pouvait pas l'aider).


2
2017-07-18 20:55