Qual é a diferença entre o iptables “state” e o “ctstate”?

Question

Eu vi este snippet do iptables em outra resposta de superusuário:

iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

O ponto é sempre permitir pacotes que são enviados como parte de uma conexão estabelecida. A parte que eu estou querendo saber é sobre as duas principais linhas.

Para a cadeia INPUT , qual é o sentido de escrever -m conntrack --ctstate RELATED,ESTABLISHED e -m state --state RELATED,ESTABLISHED . Parece que ambos deveriam fazer a mesma coisa?

Uma explicação da diferença entre esses dois seria ótima.

    

Answer 1

Resposta principal:

Conntrack substitui state , mas nos grãos modernos não há diferença entre os dois. State está atualmente com alias e traduzido para conntrack no iptables se o kernel o tiver, então a sintaxe -m state --state é realmente traduzido em -m conntrack --ctstate e manipulados pelo mesmo módulo.

Em alguns kernels antigos, no entanto, o contrack tem que ser especificamente ativado.

Possível explicação:

Parece-me que as regras que você citou incluíam duplicatas, catering para kernels mais velhos e mais recentes.

Ou talvez seja apenas um caso de programação de culto de carga .

    

Answer 2

Há esta pergunta no ServerFault do ano de 2012:

What's the practical difference between:

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

and

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

Which one is best to use?

A resposta aceita é:

Both use same kernel internals underneath (connection tracking subsystem).

Header of xt_conntrack.c:

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

So I would say -- state module is simpler (and maybe less error prone). It's also longer in kernel. Conntrack on the other side has more options and features[1].

My call is to use conntrack if you need it's features, otherwise stick with state module.

Similar question on netfilter maillist.

[1] Quite useful like -m conntrack --ctstate DNAT -j MASQUERADE" routing/DNAT fixup ;-)

Uma das outras respostas leva a este documento sobre iptables . Diz:

The conntrack match is an extended version of the state match, which makes it possible to match packets in a much more granular way. It let's you look at information directly available in the connection tracking system, without any "frontend" systems, such as in the state match.

Então, acho que isso é verdade (a partir de outra outra resposta):

There is no difference in the outcome of those two rules.

Note que há também um comentário interessante sob a pergunta:

state is deprecated in favor of conntrack, and may or may not be compiled in depending on how your kernel was built.