Re: [ml] tcp-flags e IPTABLES

Luigi Iotti wrote:

> -m tcp? Non è necessario (è sufficiente -p tcp),  man iptables:
> iptables  can  use  extended  packet matching modules.  These are loaded in
> two ways: implicitly, when -p or --protocol is specified, or with the -m
> or --match options, followed by the matching module name
>
>  
Mea Culpa :)
Sinceramente io sono uno di quelli a cui piace specificare le opzioni e 
quindi ho sempre usato anche -m tcp ...

> Tornando a quello che scrivevo io, è che spesso cambiando il kernel (ed è
> quello che Alessandro ha fatto) cambia l'interfaccia iptables-kernel. Da qui
> la necessità di ricompilare iptables con gli header di quel kernel (da qui
> la riga KERNEL_DIR=).
>
> Spesso il cambiamento introdotto nel kernel è 'subdolo': io ad esempio
> quando ho ricompilato il kernel di cui parlavo ho _solo_ introdotto le patch
> di patch-o-matic nth, pptp-conntrack-nat e h323-conntrack-nat. Nessun'altra
> modifica.
> Dopo avere bootstrappato il kernel nuovo, non funzionava più una banale
> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
>
>  

E qui siamo d'accordo. POM va a patchare (quando necessario) sia il 
kernel che i sorgenti di iptables.
Dopodiche' la compilazione di iptables sara' in funzione dei match che 
sono stati abilitati nel kernel.
voglio dire che se aggiungi una patch da PoM devi necessariamente 
ricompilare i sorgenti di iptables (e il kernel ovviamente) ... ma 
questo dovrebbe essere l'unico caso per quanto ne so io.

Se parliamo invece di una libreria di match standard come libipt_tcp.so 
... dico solo che mi sembra strano che non funzioni out of the box (o 
out of the rpm).
Inoltre Alessandro afferma di avere lo stesso problema anche con il 
kernel ufficiale fedora e il pacchetto ufficiale fedora, questo mi fa 
pensare di andare a cercare il problema da un'altra parte rispetto ai 
sorgenti.

Comunque sia credo che provare a ricompilare iptables sia sicuramente 
uno step necessario per cercare l'errore.

> Quello che era cambiato è l'interfaccia netfilter (nel kernel) <-> iptables
> (in userspace).
>
>  
Questo e' quello che nel tuo discorso non capisco.
Voglio dire, iptables e netfilter sono , per natura e design, 
estremamente modulari entrambi.
Il Kernel di Alessandro e' monolitico e includendo il supporto a 
netfilter dovrebbe includere anche il supporto ai match su tcp (tcp 
flags compreso).
Iptables ricerca le sue librerie in base al nome del match (-m) , e da 
qui veniva anche il consiglio di provare ad usare l'opzione stessa, e 
infatti nell'errore riportato da Alessandro

Couldn't load target 'tcp-flags': /lib/iptables/libipt_tcp_flags.so 
cannot open shared object file: no such or directory

si nota proprio come iptables vada a prendere il "--tcp-flags" come 
match e non come opzione del match, cercando quindi una libreria col 
nome improbabile di libipt_tcp_flags.so invece che libipt_tcp.so.

Io consiglio nuovamente di provare ad aggiungere il "-m tcp" e vedere se 
funziona .... chissa' :)

Ciauz