6. Gli hook di Netfilter per realizzare un tunnel

Gli autori dei driver per il tunneling (o incapsulamento) dovrebbero seguire due semplici regole per il kernel 2.4 (come fanno i driver nel kernel, ad esempio net/ipv4/ipip.c):

• Rilasciare skb->nfct se si sta per rendere il pacchetto irriconoscibile (es. decapsulare/incapsulare). Non c'è bisogno di fare questo se lo si sta mettendo in un *nuovo* skb.

  Altrimenti il NAT userà le vecchie informazioni del connection tracking per modificare il pacchetto, con pericolose conseguenze.

• Bisogna essere sicuri che i pacchetti incapsulati passino attraverso l'hook LOCAL_OUT, e quelli decapsulati attraverso PRE_ROUTING (la maggior parte dei tunnel usano ip_rcv(), che fa proprio questo).

  Altrimenti l'utente non sarà in grado di filtrare come si aspetta da un tunnel.

Il modo tradizionale per fare la prima cosa consiste nell'inserire le seguenti linee di codice prima di "wrappare" o "unwrappare" il pacchetto:

        /* Dice al framework netfilter che questo pacchetto non è lo
           stesso di prima!*/
#ifdef CONFIG_NETFILTER
        nf_conntrack_put(skb->nfct);
        skb->nfct = NULL;
#ifdef CONFIG_NETFILTER_DEBUG
        skb->nf_debug = 0;
#endif
#endif

Solitamente, tutto quello che bisogna fare per il secondo accorgimento, è trovare dove il pacchetto appena incapsulato va dentro "ip_send()", e sostiruirlo con qualcosa tipo:

        /* Invia il "nuovo" pacchetto dall'host locale */
        NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, skb, NULL, rt->u.dst.dev, ip_send);

Seguendo queste regole la persona che imposta imposta le regole per il packet filtering sulla tunnel-box vedrà qualcosa del genere per un pacchetto sottoposto a tunneling:

1. FORWARD hook: pacchetto normale (da eth0 -> tunl0)
2. LOCAL_OUT hook: pacchetto incapsulato (verso eth1).

E per il pacchetto di risposta:

1. LOCAL_IN hook: pacchetto di risposta incapsulato (da eth1)
2. FORWARD hook: pacchetto di risposta (da eth1 -> eth0).