L’analisi dei problemi

Chi fa un lavoro come il mio, il consulente IT, è costantemente chiamato ad analizzare problemi, individuare le cause e trovare o proporre soluzioni.

L’informatica aumenta esponenzialmente di complessità e l’analisi di un problema alla ricerca della sua causa è un’attività tutt’altro che semplice.

Chiarisco subito una cosa: questo articolo non è un auto-incensamento di chi si crede uno Sherlock Holmes del XXI secolo; prendo tante di quelle cantonate che la metà basterebbe proprio a causa della complessità dei sistemi e della mia ignoranza. Quanto segue serve, invece, a ridurre, anche se di poco, i granchi che si prendono.

Nella vita domestica i piccoli inconvenienti hanno spesso cause semplici e isolabili: se dopo aver fatto le pulizie non si accende più la lavatrice (e solamente lei) controllo se la spina della lavatrice è inserita perché mi ricordo di aver utilizzato quella presa per l’aspirapolvere.

In informatica questa linearità è spesso un’illusione che porta lontano dal risultato.

È stato emblematico un caso di qualche giorno fa: una società con cui collaboro ha acquisito un nuovo cliente e da qualche giorno questo riceveva alcune mail con un ritardo di qualche ora nel suo mail server on premises.

Il problema succedeva a caso sia nel tempo sia nelle mail (se mandavo tre mail da un account esterno, una arrivava subito e due dopo qualche ora, a caso). Il cliente non ha altri problemi di connettività, la linea sta sempre su e non soffre di problemi. Il suo IP pubblico ha una perfetta reputazione e non è listato in alcun RBL.

Analisi del fornitore soccombente che cura ancora parte dei servizi: è colpa dei nuovi PC che sono stati aggiunti alla rete (dal nuovo fornitore, ça va sans dire).

Analisi del provider di connettività: è colpa del router, sostituiamo il router dopo aver salvato e ripristinato la configurazione.

Qui ci sono stati due tipi emblematici di analisi errate.

La prima è il tipico post hoc, ergo propter hoc (è capitato dopo questo, quindi è capitato a causa di questo) condito con un pizzico di risentimento. Si tratta di un’analisi pseudo-razionale ma in verità molto emotiva, tipo quando a scuola c’era qualcuno che quando aveva un successo, in condizioni analoghe successive si vestiva allo stesso modo nella speranza di ripetere il successo.

Post hoc, ergo propter hoc è anche un modo per fingere (o millantare) competenza senza preoccuparsi di analizzare il problema nel suo insieme o di verificare se eventuali elementi esterni (che poi tanto esterni non sono) abbiano influito nel risultato di un’operazione.

È un metodo che se ha successo, spesso ce l’ha per caso, un po’ come la storia del santone che si porta a letto le fanciulle per far piovere: prima o poi piove, ma non certamente per l’attività del santone.

Post hoc, ergo propter hoc fa presa anche perché non serve essere esperti per capire il concetto, quindi è un concetto che piace e che non richiede spiegazioni “noiose”.

Ai fan di questo metodo consiglio un bel banner con scritto «LA CONSEQUENZIALITÀ NON IMPLICA CAUSALITÀ»

Il secondo tipo di analisi è quella dello specialista di settore che aggiusta quello che conosce perché analizza solamente quello (spesso non per malafede, sia chiaro).

Questo è un caso analogo alla battuta «la tua malattia dipende dal medico specialista che scegli per curarti»

Nel caso in esempio il provider è stato molto volonteroso e si è dato da fare per risolvere il problema, ma l’ha fatto a modo suo e in maniera solitaria, senza coordinarsi con altri fornitori o con il cliente. Morale: ha fatto un gran favore escludendo l’ipotesi che il router avesse dei difetti, ma non ha risolto il problema al cliente.

Nel caso in specie, visto il caos di teorie, abbiamo deciso di fare tabula rasa e ripartire da zero nelle analisi.

Siamo partiti dall’analisi degli header delle mail arrivate in ritardo: tutte quelle analizzate evidenziavano che il ritardo era tra un server SMTP esterno e il server SMTP on premises del cliente. Nessuna correlazione evidente tra gli IP dei server mittenti.

Le mail in coda su un server controllabile risultavano tutte rifiutate con “Connection refused”, nonostante non fosse attivo alcun sistema di firewall o filtro di sorta sulla connessione destinataria. Anche le mail inviate qualche giorno prima dal medesimo server risultavano rimbalzate con il medesimo errore, prima di essere recapitate qualche ora dopo, a caso.

Una serie di comandi telnet sulla porta 25 lanciati da tre server esterni davano “Connection refused” a raffica, nel frattempo l’accesso a Internet dall’interno della LAN aziendale non dava problemi e non dava problemi nemmeno lo stesso telnet eseguito dall’interno della LAN.

Restavano: la linea Internet, il router e il firewall, che in quel momento aveva la parte di filtro disabilitata e faceva solamente da NAT.

Il log in tempo reale dei pacchetti scartati o passati del firewall non evidenziava nessun collegamento dagli IP da cui provenivano i telnet, in altre parole i pacchetti IP non raggiungevano il firewall, stando ai log del medesimo.

Ci siamo concentrati sul router: un normalissimo ZyXEL Prestige 6xx configurato per inoltrare tutte le connessioni in arrivo, indipendentemente dalla porta, sull’IP esterno del firewall. Nessun filtro o firewall attivo sul router.

L’unico campo che avesse un senso era «Max NAT/Firewall session per user» impostato a 250.

Apparentemente quel valore controlla la dimensione della tabella di NAT, non è dato sapere  il TTL di quella tabella, ovvero dopo quanto tempo una entry viene cancellata, né è possibile ispezionarla per capire cosa contiene.

A livello di test, abbiamo raddoppiato il valore e dato OK.

EUREKA!

Da quel momento ogni connessione SMTP esterna ha iniziato a funzionare come ci si aspettava.

Spiegazione (presumo) logica a posteriori: anziché aver configurato sul Prestige l’inoltro di porte specifiche è stato configurato l’inoltro via NAT di tutte le porte ad un solo indirizzo della rete interna, a cui era demandato un successivo filtro.

Questa configurazione non proprio da manuale provocava un veloce riempimento della tabella di NAT del Presige, che iniziava a rifiutare le connessioni in ingresso.

Qui bisogna essere onesti: è stato 50% culo e 50% intuito: l’intuito ha portato vicino alla soluzione, il culo ha fatto trovare la soluzione esatta.