Quelle est la difference entre -m conntrack --ctstate et -m state --state

Je lis ce howto, et il y a quelque chose comme ça:

Nous pouvons autoriser les sessions établies à recevoir du trafic:

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

La règle ci-dessus n'a aucun espace de part et d'autre de la virgule dans ESTABLISHED, RELATED

Si la ligne ci-dessus ne fonctionne pas, vous pouvez vous trouver sur un VPS castré dont le fournisseur n'a pas mis l'extension à disposition. Dans ce cas, une version inférieure peut être utilisée en dernier recours:

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

Existe-t-il une différence significative entre -m conntrack --ctstateet -m state --state? Ils disent qu'on ne peut pas travailler, mais ils ne disent pas pourquoi. Pourquoi devrais-je préférer l'un à l'autre?

Je ne prétends pas être un expert des iptablesrègles, mais la première commande utilise l'extension de suivi de connexion ( conntrack), tandis que la seconde utilise l' stateextension.

Point de données n ° 1

Selon ce document, l' conntrackextension a été remplacée state.

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

Point de données n ° 2

Malgré tout, j’ai trouvé cette question-réponse de SF intitulée: Questions sur le pare - feu concernant l’état et la politique? où OP a affirmé avoir posé cette question sur IRC dans # iptables @ freenode. Après en avoir discuté, il est arrivé à la conclusion suivante:

Techniquement, le match conntrack remplace - et donc obsolète - le match state. Mais pratiquement le match d'état n'est en aucun cas obsolète.

Point de données n ° 3

Enfin, j'ai trouvé ce Q & A SF intitulé: Iptables, quelle est la différence entre -m state et -m conntrack? . La réponse à cette question est probablement la meilleure preuve et le meilleur conseil sur la manière de visualiser l’utilisation de conntracket state.

extrait

Les deux utilisent les mêmes éléments internes du noyau (sous-système de suivi des connexions).

En-tête de xt_conntrack.c:

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

Je dirais donc que le module d'état est plus simple (et peut-être moins sujet aux erreurs). C'est aussi plus long dans le noyau. Conntrack de l'autre côté a plus d'options et de fonctionnalités _[1] .

Mon appel est d'utiliser conntrack si vous avez besoin de ses fonctionnalités, sinon restez avec le module d'état.

• Question similaire sur mafist netfilter.

[1] Très utile comme le "-m conntrack --ctstate DNAT -j MASQUERADE" routage / correction de DNAT ;-)

Point de données n ° 4

J'ai trouvé ce fil dans les discussions de netfilter@vger.kernel.org netfilte / iptables, intitulé: state match is obsolete 1.4.17 , qui dit à peu près qu'il ne states'agit là que d'un alias conntrack. les deux circonstances que vous utilisez conntrack.

extrait

En fait, je suis d'accord. Pourquoi ne gardons-nous pas "état" comme alias et acceptons l'ancienne syntaxe de "conntrack"?

state est actuellement aliasé et traduit en conntrack dans iptables si le noyau en dispose. Aucun script n'est cassé.

Si le crénelage est effectué dans l'espace utilisateur, la partie noyau peut être supprimée - peut-être un jour.

Le crénelage est déjà fait dans l'espace utilisateur. On tape "state" et il est converti en "conntrack" et est ensuite envoyé au noyau. (Donc, autant que je sache si les alias de modules ipt_state, etc. ont été ajoutés au module conntrack, même le module du noyau d'état pourrait être supprimé.)

Références

• Questions sur le pare-feu sur l'état et la politique?
• iptables: différences en utilisant conntrack ou state module

Je ne suis pas un expert en netfilter, mais j'ai jeté un œil dans la page de manuel d'iptables-extension et j'ai été surpris.

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

Donc state fait partie de conntrack et en est une version plus simple si vous avez vraiment besoin - de state et non des fonctionnalités les plus sophistiquées de conntrack