Als ich ipchains entwickelte, merkte ich (in einem dieser Flash-Momente- waehrend-man-auf-Einlass-wartet in einem chinesischen Restaurant), dass Paketfiltern an der falschen Stelle ansetzte. Ich kann es jetzt nicht mehr finden, aber ich erinnere mich daran, dass ich eine Mail an Alan Cox schrieb, der mir antwortete 'Warum beendest Du nicht erst das, was Du im Moment tust, obwohl Du wahrscheinlich recht hast'. Um es kurz zu sagen, sollte Pragmatismus ueber die Richtige Sache siegen.
Als ich ipchains, was urspruengliche eine kleine Modifikation des Kernelteils von ipfwadm war, und dann doch eine groessere Neu-Ueberarbei- tung wurde, beendete und das HOWTO schrieb, bemerkte ich die Verwirrung, die in der grossen Linux-Community ueber Dinge wie Paketfiltern, Masque- rading, Portforwarding und aehnliches herrscht.
Das ist das Gute daran, wenn Du Dein eigener Support bist: Du bekommst ein besseres Gefuehl dafuer, was die User versuchen zu tun, und womit sie noch straucheln. Es ist die groesste Auszeichnung fuer Freie Software, wenn sie von vielen Usern eingesetzt wird (darum geht es, richtig?), und das bedeutet, dass man es leicht machen muss. Die Architektur, und nicht die Dokumenation, ist der Schluessel hierzu.
Ich hatte also die Erfahrung, sowohl mit dem ipchains-Code, als auch mit einer guten Vorstellung davon, was die Leute dort draussen taten. Es gab nur zwei Probleme:
Zuerst wollte ich nicht in den Security-Bereich zurueckgehen. Ein Security-Consultant zu sein ist ein konstantes moralischen Tauziehen zwischen Deinem Gewissen und Deinem Konto. Auf einem fundamentalen Level verkaufst Du das Gefuehl von Sicherheit, was alles andere ist als wirkliche Sicherheit. Vielleicht waere es anders, in einer Militaereinrichtung zu arbeiten, wo man Sicherheit versteht.
Das zweite Problem ist, dass es nicht nur um Newbies geht; eine wachsende Anzahl von grossen Unternehmen und ISPs benutzen dieses Zeug. Ich brauchte zuverlaessige Informationen von dieser Klasse von Benutzern, wenn es sich auf die Home-User von Morgen ausbreiten sollte.
Diese Probleme wurden geloest, als ich auf der Usenix 1998 auf David Bonn von Watchguard traf. Sie suchten einen Linux-Kernel Programmierer; Im Ende einigten wir uns darauf, dass ich fuer einen Monat zu ihrer Niederlassung in Seattle kommen wuerde, wo wir sehen wuerde, ob wir eine Vereinbarung rausschlagen koennten, in der sie meinen neuen Code und meine jetzige Support-Arbeit sponsorn wuerden. Das Gehalt, das sie mir anboten, war mehr als das, nachdem ich gefragt hatte, ich hatte also keine Einnahmeverluste. Das bedeutet, dass ich mir fuer eine Weile keine Sorgen um Geld zu machen brauche.
Die Naehe zu Watchguard gab mir die Naehe zu den grossen Clients, die ich brauchte, und dass ich unabhaenging von ihnen war, erlaubte mir, alle User (z.b. Watchguard Competitors) gleich zu supporten.
Ich haette also einfach Netfilter schreiben und ipchains portieren koennen und waere fertig damit gewesen. Leider haette das den ganzen Masquerading- Code im Kernel gelassen: Die Unabhaengigkeit zwischen Paketfiltern und Masquerading ist ein wichtiger Punkt beim Paketfiltern, aber Masquerading muss auch auf das Netfilter-Rahmenwerk uebertragen werden.
Meine Erfahrung mit dem ipfwadm 'Schnittstellen-Adressierungs' Feature hat mich auch gelehrt, dass es keine Hoffnung dafuer gab, den Masquerading Code einfach auszulassen und zu erwarten, dass ihn jemand brauchte und somit selbst die Arbeit einer Portierung zu Netfilter uebernehmen wuerde.
Ich brauchte also mindestens soviele Features wie im damaligen Code; vorzugsweise ein paar mehr, um mutige und kreative User zu ermutigen, es mir nachzumachen. Dies bedeutete, transparente Proxies (zum Glueck!), Masquerading und Port-Forwarding zu ersetzen. Mit anderen Worten, ein komplettes NAT-Layer.
Sogar, wenn ich mich dazu entschieden haette, das existierenden Masquerading Layer zu Portieren, anstatt ein generisches NAT-System zu schreiben, zeigte der Masquerading Code doch sein Alter und den Mangel an Wartung. Es gab keinen Masquerading Maintainer, und das zeigte sich jetzt. Es scheint, dass ernsthafte User Masquerading generell nicht verwenden und dass es nicht viele Home-User gibt, die die Arbeit der Wartung uebernehmen wuerden. Tapfere Leute wie Juan Ciarlante schrieben Fixes, aber der Punkt (der immer weiter nach hinten verschoben wurde) war erreicht, an dem eine komplette Ueberarbeitung noetig war.
Beachte bitte, das nicht ich die Person war, die NAT ueberarbeitet hat: Ich verwendete Masquerading nicht mehr und hatte den existierenden Code zu der Zeit nicht studiert. Das ist wahrscheinlich der Grund, warum es laenger dauerte, als es dauern sollte. Aber das Resultat ist ziemlich gut, meiner Meinung nach, und ich habe sicher verdammt viel gelernt. Ohne Zweifel wird die zweite Version noch besser werden, wenn wir sehen, wie die Leute es einsetzen.