Jaka jest różnica między -m conntrack --ctstate i -m state --state

Czytam to howto i jest coś takiego:

Możemy zezwolić ustanowionym sesjom na odbieranie ruchu:

$ sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Powyższa reguła nie ma spacji po obu stronach przecinka w USTANOWIONYM, POWIĄZANYM

Jeśli powyższa linia nie działa, możesz być na kastrowanym VPS, którego dostawca nie udostępnił rozszerzenia, w którym to przypadku można użyć gorszej wersji:

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

Czy istnieje znacząca różnica w pracy między -m conntrack --ctstatei -m state --state? Mówią, że nie można pracować, ale nie mówią dlaczego. Dlaczego powinienem preferować jeden od drugiego?

Nie twierdzę, że jestem ekspertem w zakresie iptablesreguł, ale pierwsze polecenie korzysta z rozszerzenia śledzenia połączeń ( conntrack), a drugie korzysta z staterozszerzenia.

Punkt danych nr 1

Według tego dokumentuconntrack przedłużenie wyparte state.

 Obsolete extensions:
  • -m state: replaced by -m conntrack

Punkt danych nr 2

Mimo to znalazłem to pytanie i odpowiedź SF: Pytania dotyczące zapory ogniowej na temat stanu i zasad? gdzie OP twierdził, że zadał to pytanie na IRC w # iptables @ freenode. Po omówieniu tego doszedł do wniosku, że:

Z technicznego punktu widzenia dopasowanie do konfrontacji zastępuje - i tak przestarzałe - dopasowanie do stanu. Ale praktycznie dopasowanie stanu nie jest w żaden sposób przestarzałe.

Punkt danych nr 3

Wreszcie znalazłem to pytanie i odpowiedź SF: Iptables, jaka jest różnica między -m stanem i -m conntrack? . Odpowiedź na to pytanie jest prawdopodobnie najlepszym dowodem i poradą na temat sposobu korzystania z conntracki state.

fragment

Oba używają tych samych elementów wewnętrznych jądra (podsystem śledzenia połączeń).

Nagłówek xt_conntrack.c:

xt_conntrack - Netfilter module to match connection tracking
information. (Superset of Rusty's minimalistic state match.)

Powiedziałbym więc, że moduł stanu jest prostszy (i może mniej podatny na błędy). Jest także dłuższy w jądrze. Conntrack po drugiej stronie ma więcej opcji i funkcji _[1] .

Moim wezwaniem jest użycie conntrack, jeśli potrzebujesz jego funkcji, w przeciwnym razie trzymaj się modułu stanu.

• Podobne pytanie dotyczące maillisty netfilter.

[1] Całkiem przydatne, takie jak "-m conntrack --ctstate DNAT -j MASQUERADE" routing / naprawa DNAT ;-)

Punkt danych nr 4

Znalazłem ten wątek z dyskusji netfilter@vger.kernel.org netfilte / iptables, zatytułowany: dopasowanie stanu jest przestarzałe 1.4.17 , co w zasadzie mówi, że stateto tylko alias, conntrackwięc nie ma znaczenia, którego używasz w obie okoliczności, których używasz conntrack.

fragment

Właściwie muszę się zgodzić. Dlaczego nie zachowujemy „state” jako aliasu i nie akceptujemy starej składni w „conntrack”?

stan jest obecnie aliasowany i tłumaczony na conntrack w iptables, jeśli jądro go posiada. Żadne skrypty nie są zepsute.

Jeśli aliasing jest wykonywany w przestrzeni użytkownika, część jądra można usunąć - może kiedyś.

Aliasowanie zostało już wykonane w przestrzeni użytkownika. Jeden wpisuje „stan” i jest konwertowany na „conntrack”, a następnie przesyłany do jądra. (O ile widzę, czy do modułu conntrack dodano aliasy modułu ipt_state itp., Nawet moduł jądra stanu można usunąć).

Bibliografia

• Pytania zapory na temat stanu i zasad?
• iptables: różnice przy użyciu conntrack lub modułu stanu

Nie jestem ekspertem od filtrów sieciowych, ale zajrzałem do strony podręcznika iptables-extension i niespodzianka, oto ona

The "state" extension is a subset of the "conntrack" module.

Więc stan jest częścią conntrack i tylko jego prostszą wersją, jeśli naprawdę potrzebujesz - stan i nie z bardziej fantazyjnych funkcji conntrack