8. Motivation

Comme j'ai développé ipchains, j'ai réalisé (pendant l'un de ces moments flash-tout-blanc-pendant-que-j-attend dans un restaurant chinois à Sydney) que le filtrage de paquets était fait au mauvais endroit. Je n'arrive plus à le retrouvé maintenant, mais j'ai envoyé un émail à Alan Cox, qui a en quelque sorte répondu `pourquoi tu ne finis pas ce que tu as commencé d'abord, même si tu as probablement raison'. Version courte : le pragmatisme allait gagner devant `The Right Thing' (`La Bonne Methode').

Après avoir fini ipchains, qui devait être initialement une modification mineure des parties kernel de ipfwadm, et qui a fini par être une ré-écriture quasi-totale de la chose, et après avoir écrit le HOWTO, je me suis rendu compte à quel point toute la communauté Linux était confuse avec des choses comme le filtrage de paquets, NAT et port forwarding, et les choses du même genre.

C'est la joie de fournir votre propre support : vous avez une idée plus précise de ce que les utilisateurs cherchent à faire, et ce avec quoi ils ont des difficultés. Le Free Software est le plus gratifiant quand il est dans les mains de la plupart des utilisateurs (c'est le but hein ?), et ça veut dire le simplifier. L'architecture, et pas la documentation, était le problème principal.

Donc j'avais l'expérience avec le code d'ipchains, et une bonne idée de ce que les gens cherchaient à faire. Mais il y avait deux problèmes :

D'abord, je n'avais pas envie de me remettre à la sécurité. Être un consultant en sécurité est toujours une bataille dans votre cerveau entre votre conscience et votre porte-monnaie. A un niveau de base, vous vendez le sentiment de sécurité, qui est à l'opposé de la vrai sécurité. Peut être travailler dans un corps militaire, où ils comprennent la sécurité, ça aurait été diffèrent.

Le deuxième problème est que les nouveaux utilisateurs ne sont plus les seuls à poser problème, un nombre grandissant de gros ISPs utilisent ce truc. J'avais besoin d'informations exactes en provenance de ces gens, si c'était pour aménager la chose pour les utilisateurs de demain.

Ces problèmes ont été résolus quand j'ai rencontré David Bonn, de chez WatchGuard, à Usenix en 1998. Ils cherchaient un codeur pour le kernel Linux, à la fin on s'est mis d'accord que j'allais passer un mois dans leurs bureaux à Seattle, et on verra si on pourra s'arranger sur un accord ou ils sponsoriseraient mon travail. Le prix a été plus que ce que j'avais demandé, et donc je n'ai pas souffert de perte de salaire. Ce qui veut dire que je n'avais pas à me soucier à faire du consulting en externe pour un bon moment.

Travailler avec WatchGuard m'a donné une exposition avec de large clients, ce qui était ce de quoi j'avais besoin. Et étant indépendant d'eux, ça me permettait d'aider les autres (ex: les compétiteurs de WatchGuard) de manière égale.

Donc j'aurais pu avoir écrit netfilter, et porté ipchains par dessus, et avoir fini mon boulot. Malheureusement, ça aurait laissé tout le code de masquerading dans le kernel : et faire en sorte que le masquerading soit indépendant du filtrage était un but très important.

Aussi, mon expérience avec la fonction `interface-address' d'ipfwadm (celle que j'ai retiré d'ipchains), m'a enseigné qu'il n'y avait aucun espoir d'enlever simplement le code de masquerading du kernel et d'attendre que quelqu'un le porte sous netfilter pour moi.

Donc j'avais besoin d'avoir au moins autant de fonctionnalité que le code présent, et de préférence plus, pour encourager des utilisateurs marginaux à être les premiers testeurs. Cela veut dire remplacer les fonctions de proxy transparent (enfin !), de masquerading et de port-forwarding. En d'autres mots, avoir une couche de NAT.

Même si j'avais décidé de porter la couche de masquerading existante, à la place d'écrire une couche de NAT générique, le code de masquerading montrait son âge, et son manque de maintenance. Vous voyez, il n'y avait pas de mainteneur du code de masquerading et ça se voit ! Il semblerait que les utilisateurs sérieux n'utilisent pas généralement la masquerade, et il y a peu d'utilisateur à la maison qui serait prêt à maintenir le code de masquerading. Des gens courageux et braves comme Juan Ciarlante envoyaient des patchs pour corriger des bugs de temps en temps, mais ça avait atteint le stage ou (après avoir été étendu-patché-et-ré-étendu) ou une ré-écriture était nécessaire.

Notez s'il vous plaît que je n'étais pas celui qui avait écrit le système de NAT : je n'utilisait pas la masquerading du tout, et je n'avais pas étudié le code existant à cette époque. C'est pourquoi ça m'a pris plus longtemps que ça n'aurait du en prendre. Mais le résultat est assez bien, à mon avis, et j'ai vraiment appris énormément. Sans aucun doutes la seconde version sera encore meilleure, une fois que l'on verra comment les gens l'utilisent.