Eu não reivindico ser um especialista com regras iptables
, mas o primeiro comando está fazendo uso da extensão de rastreamento de conexão ( conntrack
) enquanto o segundo está fazendo uso da extensão state
.
Ponto de dados # 1
De acordo com este documento , a extensão conntrack
substituiu state
.
Obsolete extensions:
• -m state: replaced by -m conntrack
Ponto de dados # 2
Mesmo assim, encontrei este SF Q & A intitulado: Perguntas de firewall sobre estado e política ? onde o OP alegou ter feito esta pergunta no IRC em # iptables @ freenode. Depois de discutir lá, ele chegou à conclusão de que:
Technically the conntrack match supersedes - and so obsoletes - the state match. But practically the state match is not obsoleted in any way.
Data point # 3
Por fim, encontrei este SF Q & A intitulado: Iptables, qual a diferença entre -m state e -m conntrack? . A resposta desta pergunta é provavelmente a melhor evidência e conselhos sobre como visualizar o uso de conntrack
e state
.
trecho
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.
[1] Quite useful like
"-m conntrack --ctstate DNAT -j MASQUERADE"
routing/DNAT fixup ;-)
Ponto de dados # 4
Eu encontrei este tópico a partir das discussões [email protected] netfilte / iptables, intitulado: state match está obsoleta 1.4.17 , o que praticamente diz que state
é apenas um apelido para conntrack
, então não importa qual você usa, em ambas as circunstâncias você está usando conntrack
.
trecho
Actually, I have to agree. Why don't we keep "state" as an alias and accept the old syntax in "conntrack"?
o estado está atualmente com alias e traduzido para conntrack em iptables se o kernel tiver isso. Nenhum script está quebrado.
Se o aliasing é feito no espaço do usuário, a parte do kernel pode ser removida - algum dia talvez.
O aliasing já é feito no espaço do usuário. Um digita em "estado" e é convertido em "conntrack" e é então enviado para o kernel. (Então, até onde eu vejo se os aliases do módulo ipt_state, etc foram adicionados para o módulo conntrack, até mesmo o módulo do kernel de estado pode ser removido.)