Utrwalanie nf_conntrack_max Across Reboots

10

W /procMam dwa wpisy dla nf_conntrack_max:

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

Wydaje się wskazywać na tę samą wartość, co zmiana jednej zmienia również drugą. Z obydwoma ustawionymi w /etc/sysctl.conf:

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

Wartość ta wynosi 32764 po ponownym uruchomieniu, więc zmiany nie działają. Czy ktoś już na to wpadł? Domyślam się, że te wartości są stosowane przed załadowaniem odpowiednich modułów, ale miałem nadzieję, że może ktoś już zna rozwiązanie.

— Kyle Brandt
źródło

Czy kiedykolwiek znalazłeś rozwiązanie tego problemu?

— Stu Thompson,

@Stu: Nie, ja po prostu mam leniwy i napisał crona aby ustawić te :-P

— Kyle Brandt

11

to dlatego, że /proc/sys/net/nf_conntrack_maxpolega na module nf_conntrack. ale ten moduł nie zostanie załadowany domyślnie po uruchomieniu systemu.

ale jeśli uciekniesz

iptables -t nat -L

lub

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

ten moduł ładuje się automatycznie i ustawia maksymalną liczbę obsługiwaną przez system (maksymalna liczba to 65536, jeśli ram jest większy niż 4G, ale różni się w zależności od systemu). można ustawić większą liczbę (np. 6553600) w /etc/sysctl.conf) .

Rozwiązanie :

dodaj jedną linię na końcu pliku /etc/modules:

nf_conntrack

moduły te zostaną załadowane przy uruchomieniu systemu przed uruchomieniem sysctl.

— Ethan Xu
źródło

dziękuję :) - chociaż miałem też złą konfigurację, która przestała się ładować

— Christian

3

Ponieważ powinno to być:

net.netfilter.nf_conntrack_max = 65535

A teraz możesz to ustawić bez ponownego uruchamiania za pomocą: sysctl -p /etc/sysctl.conf

— Maciej Łasyk
źródło

2

Nie używam Ubuntu, ale myśląc o tym w moim umyśle CentOS, wpadłem na tę samą hipotezę, co ty - sysctl są stosowane zbyt wcześnie. Niektóre wyszukiwania wykazały, że jest to zgłoszony błąd od 2006 roku .

Wygląda na to, że umieszczenie kolejnego dowiązania symbolicznego z priorytetem> S40 w celu ponownego uruchomienia skryptu inicjującego procps prawdopodobnie zrobiłby to, czego potrzebujesz. Zgodnie z podsumowaniem błędu wygląda na to, że należy ponownie przebudować metodologię systemu Ubuntu sysctl (i, co zabawne, błąd został przypisany do kogoś, kto nie wiedział, że został przypisany i nie może mu pomóc).

— Evan Anderson
źródło