リブート後のnf_conntrack_maxの永続化

で/proc、私はnf_conntrack_maxのための2つのエントリがあります。

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

一方を変更するともう一方も変更されるのと同じ値を指しているようです。これらの両方で設定/etc/sysctl.conf：

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

再起動後も値は32764のままなので、変更は機能しません。これまでに誰かに遭遇したことがありますか？私の推測では、これらの値は関連するモジュールがロードされる前に適用されますが、誰かがすでにソリューションを知っていることを望んでいました。

これ/proc/sys/net/nf_conntrack_maxは、モジュールに依存しているためですnf_conntrack。ただし、このモジュールはシステムの起動時にデフォルトではロードされません。

でも走れば

iptables -t nat -L

または

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

このモジュールは自動的に読み込まれ、システムがサポートする最大数に設定されます（RAMが4Gより大きい場合、最大数は65536ですが、システムによって異なります）。 /etc/sysctl.conf） 。

解決：

ファイルの最後に1行追加します/etc/modules。

nf_conntrack

このモジュールは、sysctl実行前にシステムの起動時にロードされます。

それがあるはずですので：

net.netfilter.nf_conntrack_max = 65535

そして今、あなたは再起動せずにこれを設定することができます：sysctl -p /etc/sysctl.conf

私はUbuntuを使用していませんが、これについてCentOSの考え方で考えたところ、あなたがしたのと同じ仮説が思いつきました。sysctlの適用が早すぎます。一部の検索では、これが2006年以降報告されているバグであることが判明しました。

優先順位> S40で別のシンボリックリンクを配置してprocps initスクリプトを再度実行すると、おそらく必要なことが実行されるようです。バグの概要によると、Ubuntu sysctl方法論の再設計が適切であるように見えます（そして、面白いことに、バグは割り当てられていることを知らず、手助けできない誰かに割り当てられていました）。