Kernel panic é ormai un tormentone che mi porto dentro da un po. Ma siccome io sono come san tommaso e se nn vedo nn credo, ho voluto imbattermi nel crash live! A quanto pare il modulino caricato nel kernel che lo manda in crisi é proprio nf_conntrack.

Un modulo che su un ambiente server generico importa quanto ad un bambino della politica. Ma qui nn stiamo parlando di un serever generico. Qui si parla di UTM, un appliance dedicato alla sicurezza che come scopo fondamentale e primario ha quello di fare FIREWALLing. E cari miei, se siete firewall e siete al perimetro tra il dentro e il fuori, tra il  bene e il male, dovete fare NAT!

Ma guarda un po, chi é che tiene traccia delle porte aperte e allocate? Chi é che legge i pachetti per capire se dovrá aprire o meno altre porte? Ma é proprio lui! Il mitico nf_conntrack!

Il bello é che questo modulo funziona egregiamente finché non si combinano insieme i due magici servizi: cluster HA di tipo A-P e tunnel IPSec. 

Ma facciamo un passo alla volta. Cosa accade realmente? L’appliance primario é li che lavora, con la sua IPSec, il suo NAT e e le sue belle regoline di firewall. Ad un certo punto gli attiviamo l’HA. Allora lui parla con il secondario e gli chiede di sottomettersi al suo volere. Il secondario ascolta, si scarica le configurazioni dal primario e si riavvia.

Nel frattempo il primario aspetta che il secondario sia pronto, e continua imperterrito il suo sporco lavoro di “guardiano di porta”, con nat, firewall web filtering e compagnia bella.

Quando il secondario arriva al suo completamento avviene la magia: avvisa il primario che il processo di attivazione HA é completato.

Il primario di tutta risposta si emoziona e va in kernel panic!

A questo punto il secondario che era in attesa di un futuro cedimento del primario, prende subito la palla al balzo e parte ad erogare i servizi al suo posto, attendendo prima o poi che il primario torni in vita.

Il primario dopo 3 secondi di panico si riavvia e si rende conto che ormai non potrá fare altro che il secondario. Quindi pian pianino comincia a riconfurarsi come secondario. Quando ha finito comunica al secodario (che ora lavora come primario) che ora è tornato. Che ora potrá fare affdamento su di lui.

E che succede ora? Semplicemente ricomincia il  balletto! Il secondario che lavorava come primario va in crash e il primario riprende la palla.

Così comincia un passaggio continuo tra il primario e secondario che nn stanno su piu di 5 minuti l’uno. Che a dirla cosí fa poco effetto ma vi assicuro che vederlo dal vivo fa impressione, quasi quanto vedere una IA forte decidere di salvare un uomo piuttosto che un altro.

In tutto questo gli utenti nn percepiscono nulla se nn un packet loss di qualche millisecondo ogni 5 minuti.

Il supporto ha gia patchato il modulo ma purtroppo lo deve ricompilare su tutti i tipi di hardware delle varie appliance e se il problema si verifica su una per cui nn hanno giá buildato, c’é l’attesa.

Speriamo che quest’anno la befana mi porti la patch per un 15iNG AM02!

XD