Mientras desarrollaba ipchains, me di cuenta (en uno de esos momentos de destello-cegador-mientras-esperas-los-entrantes en un restaurante chino de Sydney) de que el filtrado de paquetes estaba haciéndose de la manera equivocada. No puedo encontrarlo, pero recuerdo haberle enviado un correo a Alan Cox, que respondió algo como `aunque problemente tengas razón, por qué no acabas primero lo que estás haciendo'. En pocas palabras, el pragmatismo ganaba sobre El Modo Correcto.
Cuando acabé ipchains, que inicialmente iba a ser una pequeña modificación de la parte del kernel de ipfwadm, y luego se convirtió en una reescritura mucho mayor, y escribí el HOWTO. Me di cuenta de cuánta confusión existe en la mayoría de la comunidad Linux acerca de cuestiones como el filtrado de paquetes, enmascaramiento, redireccionamiento de puertos y cosas así.
Ésta es la satisfacción de hacer tu propio soporte: tienes una mejor percepción de lo que tratan de hacer los usuarios, y con qué cosas se están peleando. El software libre es más gratificante cuando está en manos de la mayoría de los usuarios (de eso se trata, żno?), y eso significa hacerlo más fácil. La arquitectura, no la documentación, era el defecto clave.
Por tanto, tenía la experiencia, con el código de ipchains, y una buena idea de lo que la gente de fuera estaba haciendo. Sólo había dos problemas.
Primero, no quería volver al tema de la seguridad. Ser un experto en seguridad es un juego moral de la cuerda entre tu conciencia y tu cartera. A un nivel fundamental, estás vendiendo la sensación de seguridad, que está reñida con la verdadera seguridad. Quizá trabajando en un cuartel militar, donde entienden la seguridad, sería distinto.
El segundo problema es que los usuarios novatos no son los únicos interesados; hay un número en aumento de grandes empresas y PSIs que están utilizando esto. Necesitaba The second problem is that newbie users aren't the only concern; an increasing number of large companies and ISPs are using this stuff. I needed reliable input from that class of users if it was to scale to tomorrow's home users.
Estos problemas se resolvieron cuando me topé con David Bonn, de WatchGuard, en el Usenix de julio de 1998. Estaban buscando un programador del kernel de Linux; al final acordamos que iría a sus oficinas de Seattle durante un mes, y veríamos si podíamos sacar un acuerdo por el cual ellos patrocinarían mi código nuevo y mis esfuerzos por realizar este soporte. El precio que acordamos era más de lo que yo pedía, These problems were resolved, when I ran into David Bonn, of WatchGuard fame, at Usenix in July 1998. They were looking for a Linux kernel coder; in the end we agreed that I'd head across to their Seattle offices for a month and we'd see if we could hammer out an agreement whereby they'd sponsor my new code, and my current support efforts. The rate we agreed on was more than I asked, so I didn't take a pay cut. This means I don't have to even think about external conslutting for a while.
El acceso a WatchGuard me dio acceso a los grandes clientes que necesitaba, y ser independiente de ellos me permitió dar soporte a todos los usuarios (por ejemplo, a la compentencia de WatchGuard) por igual.
Podría simplemente haber escrito netfilter y portado ipchains, y habría acabado con eso. Desafortunadamente, eso habría dejado todo el código de enmascaramiento dentro del kernel: hacer el enmascaramiento independiente del filtrado es uno de los principales puntos a favor de mover los puntos de filtrado de paquetes, pero para hacer eso, el enmascaramiento también necesitaba moverse al sistema netfilter. So I could have simply written netfilter, ported ipchains over the top, and been done with it. Unfortunately, that would leave all the masquerading code in the kernel: making masquerading independent from filtering is the one of the major wins point of moving the packet filtering points, but to do that masquerading also needed to be moved over to the netfilter framework as well.
Además, mi experiencia con la característica `interface-address' de ipfwadm (la que eliminé en ipchains) me había enseñado que no era factible quitar el código de enmascaramiento y esperar que alguien que lo necesitase hiciese por mí el trabajo de portarlo a netfilter.
Por tanto, necesitaba tener al menos tantas características como en el código de entonces; preferiblemente unas cuantas más, para animar a los usuarios de nicho (??) a hacerse los primeros en adoptarlo. Esto significa reemplazar el proxy transparente (ˇfelizmente!), el enmascaramiento y el redireccionamiento de puertos. En otras palabras, una capa NAT completa. So I needed to have at least as many features as the current code; preferably a few more, to encourage niche users to become early adopters. This means replacing transparent proxying (gladly!), masquerading and port forwarding. In other words, a complete NAT layer.
Aunque hubiese decidido portar la capa de enmascaramiento existente, en vez de escribir un sistema NAT genérico, el código de enmascaramiento mostraba ya una edad y una falta de mantenimiento. No había nadie manteniendo el enmascaramiento, y se notaba. Parece que los usuarios serios generalmente no usan enmascaramiento, y no hay muchos usuarios domésticos que se dediquen a la tarea de llevar el mantenimiento. Gente animosa como Juan Ciarlante hacía correcciones, pero se había llegado a un punto (que se alargaba más y más) en el que era necesario una reescritura.
Por favor, tenga en cuenta que yo no era la persona para hacer una reescritura del NAT: no utilicé más el enmascaramiento, y no había estudiado el código existente entonces. Probablemente por eso me llevó más tiempo del que hubiese debido. Pero el resultado es bastante bueno, en mi opinión, y está claro que he aprendido mucho. Sin duda la segunda versión será incluso mejor, una vez que veamos cómo lo utiliza la gente.