Ripetere il test in modo che il test dica qualcosa

Rifare la prova sembra il passo banale del laboratorio ed è quello che rovina più diagnosi. Un test ripetuto serve solo se produce una connessione nuova, isolata e riconoscibile.

Nuova, perché la classificazione dell’Access Control unificato riparte dal SYN e viene poi rivalutata all’header HTTP e al body HTTP: se riusi una sessione già stabilita, il gateway non ripercorre la decisione che vuoi osservare e il debug resta muto. Chiudi il browser, usa una porta sorgente diversa, apri una connessione pulita.

Isolata, perché il buffer del kernel debug è una risorsa finita: prima del test si imposta il simple debug filter sulla tupla esatta della prova, così il file conterrà la tua connessione e non il traffico di tutta l’azienda.

fw ctl debug 0
fw ctl set int simple_debug_filter_off 1
fw ctl set str simple_debug_filter_saddr_1 "192.0.2.10"
fw ctl set str simple_debug_filter_daddr_1 "198.51.100.20"
fw ctl set str simple_debug_filter_dport_1 "443"
fw ctl debug -buf 8200

Riconoscibile, perché senza un riferimento temporale il file è illeggibile: la raccolta va sempre fatta con -T, che aggiunge timestamp al microsecondo, e conviene annotare l’ora esatta in cui hai premuto invio sul client. Su un cluster il test va preparato in modo identico su tutti i membri, altrimenti rischi di riprodurre il problema sul membro che non stai osservando.

Debuggare il modulo Unified Policy

Il modulo da accendere per un problema di Access Control è UP, la Unified Policy: è il componente che valuta la rule base unificata, non la singola blade. Il modulo fratello UPIS, la Unified Policy Infrastructure, guarda il livello sotto — database, tabelle, topologia, aggiornamenti — e si accende quando il sospetto è che la policy sia arrivata male al gateway, non che abbia deciso male.

La sequenza è quella di ogni kernel debug, con i flag scelti sul problema e non presi in blocco:

fw ctl debug -m UP + match rulebase connection error log
fw ctl debug -m UP
fw ctl kdebug -T -f -o /var/log/up_debug.txt

match è l’osservatore della classificazione, rulebase segue le operazioni sulla rule base, connection traccia connessioni e transazioni, error e log tengono le righe che spiegano i fallimenti. Se serve seguire il percorso del rule matching riga per riga si aggiunge probtrc, e per capire se a decidere è stata una implied rule c’è prob_impl. La seconda riga della sequenza non è decorativa: rilegge i flag attivi ed è l’unica prova che la configurazione sia andata a buon fine.

Quando la domanda è «dove è sparito il pacchetto» più che «quale regola ha deciso», si affianca il modulo fw con i flag di connessione e drop:

fw ctl debug -m fw + conn drop

A prova conclusa si chiude, sempre, con fw ctl debug 0, fwaccel dbg resetall e la verifica con fw ctl debug e fwaccel dbg list. Il carico di CPU durante la raccolta è significativo e la guida chiede di pianificare una finestra di manutenzione: un debug dimenticato acceso su un gateway di produzione è un incidente, non una dimenticanza.

Leggere l’esito senza forzarlo

Il file di debug e il log di SmartConsole vanno letti insieme, e la domanda che si pone loro è una sola: quale regola ha deciso. Se compare un match su una regola con azione di blocco, il traffico è stato fermato apposta e il problema è di policy, non di troubleshooting. Se invece il traffico finisce su una regola diversa da quella attesa — tipicamente il cleanup — non c’è nessun drop deliberato: c’è una regola che non ha fatto match, e la causa sta negli oggetti, negli access role o in una classificazione che non si è mai risolta in certain match. Il modulo UP con il flag match mostra esattamente questo passaggio, ed è la ragione per cui si accende.

Trappole tipiche d’esame

Il modulo sbagliato. Davanti a un problema su una regola con applicazioni, siti o identità, la distrattrice classica propone il modulo della blade coinvolta. La rule base unificata si debugga con UP, e con UPIS quando il sospetto riguarda la policy installata e non la decisione. Sbagliare modulo produce zero righe, che all’esame viene poi raccontato come «il debug non ha mostrato nulla».

Ripetere il test a dettaglio invariato. Un secondo test con la stessa colonna Track e la stessa policy non genera informazione nuova. Alza il dettaglio, pubblica e installa, poi riproduci: se la sequenza proposta in una risposta ripete il test prima di alzare il dettaglio, è la risposta sbagliata anche quando i comandi sono corretti.

Match mancato contro drop deliberato. Sono esiti diversi con rimedi opposti. Il drop deliberato ha una regola identificata e un’azione di blocco; il match mancato ha la connessione altrove e nessuna azione esplicita contro di essa. Leggi sempre il numero di regola nel log prima di concludere che «il firewall blocca».