Prima di premere invio: flusso, reset, filtro, buffer

Un kernel debug non è un interruttore, è una catena di preparazione: se salti un anello il file che raccogli non contiene la risposta. Il primo anello non è nemmeno un comando, è sapere dove passa il traffico. fw ctl chain elenca i Chain Module attraversati dai pacchetti, e nell’esempio della guida R82 sono 23 sulla catena inbound e 19 su quella outbound — l’elenco reale dipende dalle blade attive — con le priorità negative che eseguono per prime in ingresso e quelle positive in uscita. Senza questa mappa i moduli da debuggare li scegli a caso. Il secondo anello è fw monitor, che cattura a ogni Chain Module nei due sensi: i quattro punti di ispezione sono pre-inbound (i), post-inbound (I), pre-outbound (o) e post-outbound (O), riferiti al FireWall Virtual Machine. Sapere se il pacchetto arriva alla i e non alla I ti dice già in quale metà del problema sei.

In Expert mode si azzera tutto prima di configurare qualsiasi cosa:

fw ctl debug 0
fwaccel dbg resetall
fw ctl set int simple_debug_filter_off 1

Poi si mette il filtro, perché è quello che decide se il buffer conterrà la tua connessione o il rumore di tutte le altre:

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"

Lo stesso indice mette i criteri in AND, indici diversi li mettono in OR. Si configurano fino a cinque filtri per tupla di connessione, tre per singolo indirizzo (che vale sia come sorgente sia come destinazione) e due per peer VPN. Infine il buffer:

fw ctl debug -buf 8200
fw ctl debug | grep buffer

La procedura della guida usa 8200, mentre il testo dichiara 8192 kilobyte come massimo supportato: la riga di verifica serve proprio a leggere che cosa ti è stato allocato davvero invece di fidarti del numero che hai scritto. Il default è 50 kilobyte, e con 50 kilobyte un problema che si riproduce in trenta secondi ti lascia in mano gli ultimi due.

Il debug di base: un modulo, pochi flag

fw ctl debug -m elenca i moduli disponibili, una quarantina nella R82, da APPI a ZPH. Per un problema di traffico il punto di partenza è il modulo fw:

fw ctl debug -m fw + conn drop vm
fw ctl debug -m fw

La seconda riga rilegge la configurazione: è l’unica prova che i flag siano attivi davvero. Poi si raccoglie su file:

fw ctl kdebug -T -f -o /var/log/kernel_debug.txt

-T aggiunge timestamp al microsecondo, -f tiene aperta la raccolta finché non premi CTRL+C, -o scrive su file e conviene puntare alla partizione più capiente. La R82 affianca fw ctl ndebug a fw ctl kdebug; sui gateway con 72 core o più la raccolta nuova scrive file temporanei e li unisce alla fine, invece di riversare tutto a schermo. Solo a questo punto si riproduce il problema, e la chiusura è parte della procedura, non un ripensamento:

fw ctl debug 0
fwaccel dbg resetall
fw ctl debug
fwaccel dbg list

Due comandi si somigliano e non fanno la stessa cosa: 0 ripristina i soli flag di default, -x disabilita tutti i flag compresi quelli di default. Se chiudi con -x lasci il gateway più muto di come l’hai trovato.

Il debug avanzato: seguire il ciclo di vita della connessione

Quando il debug di base dice che il pacchetto entra e non esce, ma non dice dove si perde, si passa al ciclo di vita della connessione. I flag restano quelli del modulo fw, cambia la raccolta, affidata a uno script che formatta l’output:

conn_life_cycle.sh -a start -o /var/log/kernel_debug.txt -T -f
conn_life_cycle.sh -a stop -o /var/log/kernel_debug_formatted.txt

Il file formattato va letto con un editor che supporti l’evidenziazione della sintassi Ruby, perché la formattazione è pensata per quella. Su un cluster la procedura va eseguita in modo identico su tutti i membri: un debug attivo su un solo membro, mentre il traffico passa dall’altro, produce un file vuoto e una diagnosi sbagliata. E per tutta la durata del debug il carico di CPU sale, di più ancora durante la scrittura su file: la guida chiede esplicitamente di pianificare una finestra di manutenzione.

Trappole tipiche d’esame

Accendere troppi flag. all su un modulo è comodo e riempie il buffer prima che tu riproduca il problema: i messaggi più vecchi vengono sovrascritti e nel file manca proprio l’istante che cercavi. La domanda d’esame che ti mette davanti un debug «senza risultati» vuole sentirti dire filtro più stretto e flag mirati, non buffer più grande.

Scegliere i moduli prima di conoscere il flusso. Debuggare un modulo che il traffico non attraversa dà zero righe, che è indistinguibile da «nessun problema». fw ctl chain e fw monitor vengono prima di fw ctl debug -m, sempre.

Lasciare il debug acceso. Lo scenario tipico è un gateway rallentato dopo un intervento: la risposta non è aggiungere risorse, è verificare con fw ctl debug e fwaccel dbg list che i flag siano tornati ai valori di default e che il file di output non stia riempiendo la partizione.