Qual é a diferença entre -m conntrack --ctstate e -m state --state

Estou lendo este howto, e há algo como isto:

Podemos permitir que sessões estabelecidas recebam tráfego:

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

A regra acima não possui espaços de ambos os lados da vírgula em ESTABELECIDO, RELACIONADO

Se a linha acima não funcionar, você pode estar em um VPS castrado, cujo provedor não disponibilizou a extensão. Nesse caso, uma versão inferior pode ser usada como último recurso:

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

Existe uma diferença significativa no trabalho entre -m conntrack --ctstatee -m state --state? Dizem que alguém pode não funcionar, mas não dizem o porquê. Por que devo preferir um ao outro?

Não pretendo ser um especialista em iptablesregras, mas o primeiro comando está usando a extensão de rastreamento de conexão ( conntrack) enquanto o segundo está usando a stateextensão.

Ponto de dados # 1

De acordo com este documento, a conntrackextensão foi substituída state.

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

Ponto de dados # 2

Mesmo assim, achei as perguntas e respostas do SF intituladas: Perguntas sobre firewall e estado e política? onde o OP alegou ter feito essa pergunta no IRC em # iptables @ freenode. Depois de discuti-lo lá, ele chegou à conclusão de que:

Tecnicamente, a partida do conntrack substitui - e, portanto, obsoleta - a partida do estado. Mas praticamente a correspondência entre estados não é obsoleta de forma alguma.

Ponto de dados # 3

Por fim, encontrei as perguntas e respostas do SF intituladas: Iptables, qual é a diferença entre -m state e -m conntrack? . A resposta desta pergunta é provavelmente a melhor evidência e conselho sobre como visualizar o uso de conntracke state.

excerto

Ambos usam os mesmos componentes internos do kernel abaixo (subsistema de rastreamento de conexão).

Cabeçalho do xt_conntrack.c:

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

Então, eu diria - o módulo state é mais simples (e talvez menos propenso a erros). Também é mais longo no kernel. O Conntrack do outro lado tem mais opções e recursos _[1] .

Minha chamada é usar o conntrack se você precisar de recursos, caso contrário, atenha-se ao módulo de estado.

• Pergunta semelhante no maillist do netfilter.

[1] Bastante útil, como "-m conntrack --ctstate DNAT -j MASQUERADE" roteamento / correção DNAT ;-)

Ponto de dados # 4

Encontrei esse tópico nas discussões netfilter@vger.kernel.org netfilte / iptables, intitulado: state match is obsolete 1.4.17 , que praticamente diz que stateé apenas um alias para conntrackque, na verdade, não importa o que você use, em ambas as circunstâncias que você está usando conntrack.

excerto

Na verdade, eu tenho que concordar. Por que não mantemos "state" como um alias e aceitamos a sintaxe antiga em "conntrack"?

O estado está atualmente com alias e traduzido para o conntrack no iptables se o kernel o possuir. Nenhum script está quebrado.

Se o alias for feito no espaço do usuário, a parte do kernel poderá ser removida - um dia, talvez.

O alias já está feito no espaço do usuário. Digita-se "state" e é convertido em "conntrack" e depois é enviado para o kernel. (Até onde eu sei se os aliases do módulo ipt_state, etc foram adicionados ao módulo conntrack, até o módulo do kernel do estado pode ser removido.)

Referências

• Perguntas sobre firewall sobre estado e política?
• iptables: diferenças usando conntrack ou módulo de estado

Eu não sou um especialista em filtro de rede, mas eu olhei para a página de manual do iptables-extension e surpresa, aí está

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

Portanto, state é uma parte do conntrack e apenas uma versão mais simples, se você realmente precisa - do estado e não dos recursos mais sofisticados do conntrack