Les auteurs de drivers de tunnels (ou encapsulation) devraient suivre deux règles simples avec les noyaux 2.4 (comme le font les drivers qui sont déjà dans le noyau comme net/ipv4/ipip.c) :
Sinon : le code de NAT va utiliser les anciennes informations de suivit de connexion pour modifier le paquet, ce qui aura de mauvaises conséquences.
Sinon : L'utilisateur ne sera pas capable de filtrer les paquets avec votre tunnel comme ils l'entendent.
La forme canonique pour mettre en place le premier conseil est d'insérer du code comme celui qui suit, avant de dérouler le paquet :
/* Dire a netfilter que ce paquet n'est plus le même
que celui d'avant! */
#ifdef CONFIG_NETFILTER
nf_conntrack_put(skb->nfct);
skb->nfct = NULL;
#ifdef CONFIG_NETFILTER_DEBUG
skb->nf_debug = 0;
#endif
#endif
D'habitude, tout ce que vous avez à faire pour le second, est de trouver où le paquet nouvellement encapsulé va avec "ip_send()", et de remplacer ça avec quelque-chose comme :
/* Envoie le "nouveau" paquet à partir de localhost */
NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, skb, NULL, rt->u.dst.dev, ip_send);
Suivre ces règles veut dire que la personne qui met en place une règles de filtrage sur la machine qui tunnelle verra la séquence suivante pour un paquet qui est tunellé :
Et pour le paquet réponse :