Lab: determinare il flusso prima di scegliere i moduli

Il debug del kernel non è una rete a strascico: è un microscopio puntato su un modulo preciso. Puntarlo serve a poco se non si sa prima da dove passa il pacchetto, e il percorso non è mai scontato. Una connessione può essere gestita da SecureXL, ispezionata dalle istanze firewall CoreXL, attraversare moduli di VPN, di streaming o di QoS: il modulo su cui accendere i flag cambia di conseguenza.

Il primo comando della sequenza è quindi fw ctl chain, che elenca i moduli della catena di ispezione separati per senso inbound e outbound e ordinati per priorità, dai valori negativi in su. È la mappa dei punti in cui il pacchetto può essere toccato, e si legge prima di accendere qualsiasi flag.

Il secondo è fw monitor, che cattura ai quattro punti di ispezione: i prima che il pacchetto entri in un chain module in ingresso, I dopo che lo ha attraversato, o e O per il senso in uscita. Confrontando i quattro punti si stabilisce dove il pacchetto si ferma: se compare in i e non in I, il problema è dentro la catena inbound. Con -e si passa l’espressione INSPECT, con -o il file pcap, sempre con percorso completo sulla partizione più capiente, tipicamente /var/log. Un limite documentato: le espressioni INSPECT non si applicano al traffico accelerato.

La sequenza documentata, senza scorciatoie

Check Point raccomanda di programmare una finestra di manutenzione, perché il carico di CPU sale in modo significativo, e di collegarsi via console seriale, perché sotto carico la riga di comando può diventare inaccessibile. Su un cluster gli stessi passi vanno ripetuti in modo identico su tutti i Cluster Member.

fw ctl debug 0
fwaccel dbg resetall
fw ctl set int simple_debug_filter_off 1
fw ctl debug -buf 8200
fw ctl debug | grep buffer
fw ctl debug -m MODULO all
fw ctl kdebug -T -f -o /var/log/kernel_debug.txt

Si parte azzerando: fw ctl debug 0 reimposta tutti i flag e lascia attivi solo quelli predefiniti. Il valore 8200 chiede il buffer massimo, che la documentazione fissa a 8192 KB per istanza CoreXL, e la riga con grep buffer verifica che l’allocazione sia davvero avvenuta. In fw ctl kdebug, -T mette i timestamp al microsecondo (la risoluzione consigliata per l’analisi), -f tiene la raccolta aperta fino a CTRL+C, -o scrive su file; per raccolte lunghe esistono i file ciclici.

Sull’attivazione dei flag c’è una distinzione che vale da sola diverse domande: all accende ogni flag del modulo; il segno + aggiunge flag a quelli già attivi; scrivere i flag senza segno imposta solo quelli, spegnendo tutti gli altri; il segno - toglie i flag indicati. Chi dimentica il + spegne senza accorgersene il debug acceso al passo precedente.

Filtrare prima di riprodurre

Il buffer è finito e circolare: se i messaggi arrivano più in fretta di quanto vengano scritti su file, il momento del guasto viene sovrascritto prima che tu lo legga. L’unica difesa è restringere il traffico.

I filtri si impostano prima di avviare la raccolta. La forma a cinque tuple usa variabili come simple_debug_filter_saddr_N con l’indirizzo fra virgolette doppie: i parametri con lo stesso indice N si combinano in AND, indici diversi in OR, e se ne possono definire fino a cinque. La forma per singolo indirizzo, fino a tre, corrisponde alla sorgente oppure alla destinazione. Per il peer VPN esistono fino a due filtri dedicati, ed è l’unico caso che richiede la procedura manuale. Questi filtri valgono sia sul traffico non accelerato sia su quello accelerato.

Per seguire il ciclo di vita di una connessione si usa conn_life_cycle.sh in Expert mode, insieme ai normali flag del modulo fw come conn, drop e packet, passando un filtro a cinque tuple in cui lo zero vale come carattere jolly. Senza filtro lo strumento stampa i messaggi di tutto il traffico: carico alto e formattazione lunghissima.

Chiudere il debug, sempre

La chiusura non è un comando solo: vanno ripetuti tutti e tre, fw ctl debug 0 per i flag del kernel, fwaccel dbg resetall per il debug di SecureXL, fw ctl set int simple_debug_filter_off 1 per i filtri. Fermare la cattura con CTRL+C lascia i flag accesi.

Trappole tipiche d’esame

Troppi flag, buffer pieno prima della riproduzione. Accendere all su più moduli sembra prudente e invece garantisce di perdere l’evento: il buffer si riempie e riscrive. Nelle domande a scenario la risposta corretta è quasi sempre quella che restringe — un modulo, pochi flag, un filtro — non quella che allarga.

Scegliere i moduli senza aver determinato il flusso. Se la connessione segue un percorso che non tocca il modulo su cui hai acceso i flag, il debug esce vuoto e la conclusione “non c’è niente” è falsa. fw ctl chain e fw monitor vengono prima, e le espressioni INSPECT non filtrano il traffico accelerato.

Lasciare il debug attivo in produzione. Un CTRL+C non disattiva nulla: senza la terna di comandi di reset, flag e filtri restano impostati, la CPU resta sotto carico e il disco continua a riempirsi. Su un cluster va fatto su ogni Cluster Member.