Ahogy az ipchains-t fejlesztettem, rájöttem, hogy a csomagszûrést rossz helyen valósítottuk meg. Most nem találom, de írtam egy levelet Alan Cox-nak, aki csak annyit mondott, hogy 'miért nem fejezed be elõször amit csinálsz, annak ellenére, hogy talán igazad van'. Röviden a gyakorlatiasság gyõzött a helyes út felett.
Amiután befejeztem az ipchainst - ami egy kis módosításnak indult az ipfwadm kernel részein - s egy nagyobb újraírás felé fordultam, megírtam a HOWTO-t, kifinomult képet kaptam arról, hogy a Linux társadalomnak milyen problémái vannak a csomagszûréssel, maszkolással, port-átirányítással és hasonlókkal.
Ez az öröme a saját támogatás nyújtásának: közelrõl érezheted, hogy a felhasználók mit szeretnének megvalósítani, mivel szenvednek. A szabad program a legnagyobb jutalom a legtöbb felhasználó kezében, s ez azt jelenti, hogy egyszerûnek kell lennie. Az architektúra, s nem a dokumentáció volt a legnagyobb hiba.
Nos, megvolt a tapasztalat az ipchains kódjából, s az ötlet az emberek próbálkozásaiból. Csak két problémám volt:
Nem szeretnék visszatérni a biztonsági rendszerekbe. Biztonsági konzulensnek lenni egy állandó huzavona a lelkiismereted és a pénztárcád között. Alapszinten: te a biztonság érzését árulod, hadilábon áll az aktuális biztonsággal. Talán katonai területen, ahol értik a biztonságot, más lennék.
A második problémám az, hogy nemcsak a kezdõ felhasználó okozhat gondot, hanem növekvõ számú vállalat és ISP használja ezt a terméket. Ezektõl a felhasználóktól megbízható információkra van szükség, ha a jövõ otthoni felhasználóira tervezek.
Ezek a problémák megoldódtak amikor belefutottam David Bonn-ba, a WatchGuard-tól az Usenix-en 1998 júliusában. Egy Linux kernel programozót kerestek - a végén megegyeztünk, hogy egy hónapra elmegyek a seattle-i irodájukba, hogy hátha sikerül összehozni egy megállapodást, miszerint õk támogatják az új kódot cserébe a támogatásomért. A megállapodás többrõl szólt, mint szerettem volna. Nem szeretnék külsõ konzulensként szerepelni - legalábbis mostanában.
A WatchGuard-hoz való kötõdés lehetõvé tette egy nagy ügyfélkör elérését, s mindemellett független maradhattam tõlük, ami lehetõvé tette, hogy mindenkit egyformán támogassak.
Egyszerûen megírtam a netfiltert, az ipchains-t portoltam a tetjére, s elkészültem vele. Sajnos ez meghagyta a masquerading kódot a kernelben: de a masquerading kód függetlenítése a csomagszûréstõl egyike a legnagyobb nyereségeknek, de az megmaradt, hogy a masquerading-ot ki kell emelni a kernelbõl, s át kell helyezni a netfilter rendszerbe.
Az ipfwadm `interface-address' szolgáltatásával (amit kivettem az ipchains-bõl) kapcsolatos tapasztalataim megmutatták, hogy nem lesz egyszerû munka a masquerading kód kivágása a kernelbõl, s nem lehet másra bízni a netfilter-be való portolását.
A meglevõ kódból a lehetõ legkevesebbet kellett megtartanom, s inkább új lehetõségekkel kibõvíteni azt, felbátorítandó a felhasználókat, hogy használják azokat. Ez a transzparens proxy, masquerading és port forwarding lecserélését jelentette. Más szavakkal: egy teljes NAT layer-t.
Bár elhatároztam, hogy portolom a meglevõ masquerading réteget a teljesen új NAT rendszer implementálása helyett, de a kódon meglátszott a kora, valamint a karbantartás hiánya. Nem volt felelõse a karbantartásának. Úgy látszik, hogy a komoly felhasználó nem használta a modult, s az otthoni felhasználók közül pedig senki sem vette a fáradságot a követésre. Bátor emberek, mint pl. Juan Ciarlante készítettek javítgatásokat hozzá, de elérte azt az állapotot, hogy szükségessé vált az újraírása.
Fel szeretném hívni a figyelmedet, hogy nem én voltam az alkalmas ember a NAT újraírására: soha többé nem használtam a masquerading-et, s nem tanulmányoztam a meglevõ kódot. Talán ezért tartott tovább, mint szerettem volna. De az eredmény egészen jó - legalábbis a saját véleményem szerint - s biztos vagyok benne, hogy sokat tanultam belõle. Nincs kétségem afelõl, hogy a második verzió sokkal jobb lesz, miután megláttuk, hogy miként használják az emberek.