Qual è la differenza tra -m conntrack --ctstate e -m state --state

Sto leggendo questo howto e c'è qualcosa del genere:

Possiamo consentire alle sessioni stabilite di ricevere traffico:

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

La regola sopra non ha spazi ai lati della virgola in STABILITO, CORRELATO

Se la riga sopra non funziona, potresti trovarti su un VPS castrato il cui provider non ha reso disponibile l'estensione, nel qual caso una versione inferiore può essere utilizzata come ultima risorsa:

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

C'è una differenza significativa nel lavorare tra -m conntrack --ctstatee -m state --state? Dicono che uno potrebbe non funzionare, ma non dicono il perché. Perché dovrei preferire l'uno all'altro?

Non pretendo di essere un esperto di iptablesregole, ma il primo comando utilizza l'estensione di tracciamento della connessione ( conntrack) mentre il secondo utilizza l' stateestensione.

Punto dati n. 1

Secondo questo documento l' conntrackestensione ha sostituito state.

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

Punto dati n. 2

Anche così ho trovato questa domanda e risposta sul titolo SF: Domande sul firewall relative a stato e politica? dove l'OP ha affermato di aver posto questa domanda su IRC in # iptables @ freenode. Dopo averne discusso, arrivò alla conclusione che:

Tecnicamente la partita conntrack sostituisce - e quindi gli obsoletes - la partita statale. Ma praticamente la partita di stato non è in alcun modo obsoleta.

Punto dati n. 3

Alla fine ho trovato questa domanda e risposta SF intitolata: Iptables, qual è la differenza tra -m state e -m conntrack? . La risposta a questa domanda è probabilmente la migliore prova e consiglio su come visualizzare l'uso di conntracke state.

estratto

Entrambi usano gli stessi kernel interni (sottosistema di tracciamento delle connessioni).

Intestazione di xt_conntrack.c:

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

Quindi direi: il modulo di stato è più semplice (e forse meno soggetto a errori). È anche più lungo nel kernel. Conntrack dall'altra parte ha più opzioni e funzionalità _[1] .

La mia chiamata è quella di utilizzare Conntrack se hai bisogno delle sue funzionalità, altrimenti mantieni il modulo di stato.

• Domanda simile sul maillist di netfilter.

[1] Abbastanza utile come "-m conntrack --ctstate DNAT -j MASQUERADE" routing / DNAT fixup ;-)

Punto dati n. 4

Ho trovato questo thread dalle discussioni netfilte@vger.kernel.org netfilte / iptables, intitolato: state match è obsoleto 1.4.17 , che praticamente dice che stateè solo un alias per conntrackcui non importa davvero quale usi, in entrambe le circostanze che stai utilizzando conntrack.

estratto

In realtà, devo essere d'accordo. Perché non manteniamo "state" come alias e accettiamo la vecchia sintassi in "conntrack"?

state è attualmente aliasato e tradotto in conntrack in iptables se il kernel lo possiede. Nessuno script è rotto.

Se l'aliasing viene eseguito nello spazio utente, la parte del kernel può essere rimossa - un giorno forse.

L'aliasing è già stato eseguito in userspace. Si digita in "stato" e viene convertito in "conntrack" e che viene quindi inviato al kernel. (Per quanto vedo se gli alias del modulo ipt_state, ecc. Sono stati aggiunti al modulo conntrack, anche il modulo del kernel di stato potrebbe essere rimosso.)

Riferimenti

• Domande sul firewall relative a stato e politica?
• iptables: differenze usando conntrack o modulo di stato

Non sono un esperto di netfilter, ma ho guardato nella man-page e nella sorpresa dell'estensione iptables, eccolo

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

Quindi lo stato fa parte di Conntrack e solo una versione più semplice di esso se proprio hai davvero bisogno - stato e non delle funzionalità più fantasiose di Conntrack