Come sviluppatore di ipchains ho realizzato (in uno di quei momenti di flash-abbaglianti-mentre-attendi-di-entrare in un ristorante cinese a Sidney) che il filtraggio dei pacchetti era effettuato nel posto sbagliato. Non riesco a trovarla ora, ma ricordo una lettera inviata ad Alan Cox, che gentilmente rispondeva `perché prima di tutto non termini quello che stai facendo, probabilmente è la cosa giusta'. In parole povere, pragmatismo doveva prevalere su "La Cosa Giusta".
Dopo aver terminato ipchains, che inizialmente doveva essere una modifica minore della parte del kernel riguardante ipfwadm, diventata poi una consistente riscrittura, e aver scritto l'HOWTO, mi sono reso conto di quanta confusione esistesse nella vasta comunità di Linux a riguardo delle questioni quali filtraggio dei pacchetti, mascheramento, port forwarding e così via.
Questa è la soddisfazione di fornire il proprio supporto: ottieni una stretta percezione su cosa gli utenti cercano di fare, e con che cosa si trovano a lottare. Il free software per lo più è ricompensato quando è nelle mani della maggior parte degli utenti (questo è il punto, giusto?), e ciò consente poi di poterlo rendere migliore. L'architettura, non la documentazione, è la chiave per risolvere i problemi.
Quindi avevo esperienza, per quanto riguardava il codice di ipchains, e una buona idea su cosa le persone volevano fare. Esistevano solo due problemi.
Primo, non volevo tornare indietro sulla sicurezza. Essere un consulente sulla sicurezza è un tiro alla fune costante e morale tra la coscienza e il portafogli. Ad un livello di principio si vende la percezione della sicurezza, la quale è in discordia con l'attuale sicurezza. Forse lavorare nel campo militare, dove si comprende la sicurezza, potrebbe essere differente.
Il secondo problema è che i nuovi utenti non sono l'unica preoccupazione; un numero crescente di compagnie e ISP utilizzano queste funzionalità. C'era quindi la necessità di un input fidato proveniente da queste classi di utenti se si desiderava poi scalare verso gli utenti "casalinghi".
Questi problemi sono stati risolti quando mi sono imbattuto in David Bonn, di fama WatchGuard, allo Usenix nel Luglio 1998. Stavano cercando un coder del kernel Linux; alla fine concordarono di indirizzarmi per un mese ai loro uffici di Seattle per vedere se si poteva elaborare un accordo in cui loro si sarebbero impegnati a sponsorizzare il mio nuovo codice e il mio sforzo per il supporto. La cifra concordata fu maggiore di quanto aspettato, perciò non ottenni un taglio dello stipendio. Ciò significa che non ho più da pensare a consulenze esterne per un po'.
L'esposizione alla WatchGuard mi portava all'esposizione a quei grandi clienti di cui avevo bisogno, e l'indipendenza da loro mi permetteva di supportare tutti gli utenti (es. concorrenti della WatchGuard) in modo eguale.
Avrei potuto quindi sviluppare netfilter con comodità, portare ipchains al di sopra, ed essere soddisfatto. Sfortunatamente, il codice di masquerading sarebbe comunque rimasto nel kernel: rendere il masquerading indipendente dal filtraggio è uno dei punti più importanti nel momento in cui si sposta il filtro dei pacchetti, ma per fare ciò è necessario portare anche il masquerading al di sopra del framework netfilter.
La mia esperienza con la funzionalità `interface-address' di ipfwadm (rimossa con ipchains) mi aveva insegnato che non c'era alcuna speranza di togliere il codice del masquerading e di attendere che qualcuno, che ne avesse bisogno, realizzasse un porting al di sopra di netfilter al posto mio.
Perciò avevo bisogno di avere almeno tante funzionalità quante il codice corrente; preferibilmente qualcuna in più, per incoraggiare utenti di nicchia ad adottarlo. Ciò significava rimpiazzare il proxy trasparente (volentieri!), masquerading e port forwarding. In altre parole, un completo strato NAT.
Anche se avevo deciso di portare lo strato esistente del masquerading, invece di scrivere un sistema NAT generico, il codice del masquerading ormai mostrava già i segni dell'età, e mancanza di manutenzione. Non c'era un manutentore del masquerading e si vedeva. Sembra che gli utenti più "seri" non utilizzino affatto il masquerading, e inoltre non ci sono molti utenti "casalinghi" disponibili alla manutenzione. Persone ottime come Juan Ciarlante avevano apportato correzioni, ma ormai si era arrivati ad uno stadio (essendo stato esteso più e più volte) che una riscrittura era davvero necessaria.
Prego notare che non ero la persona adatta ad effettuare una riscrittura del NAT: non utilizzavo più il masquerading, e non avevo studiato il codice esistente a suo tempo. Forse è questa la ragione per cui mi ha impegnato più a lungo di quanto previsto. Il risultato è comunque abbastanza buono, secondo la mia opinione, e assicuro che ho imparato davvero molto. Non dubito comunque che una seconda versione sarà migliore, una volta constatato come le persone la utilizzano.