Su un gateway Check Point lo stesso sintomo — traffico che non passa, SmartConsole che non si collega — può nascere in due mondi che si diagnosticano con strumenti diversi. Capire in quale dei due ti trovi è metà del lavoro di questo modulo.

Kernel space, user space e il firewall che si è spostato

Gaia è un sistema Linux: il kernel esegue i moduli caricati, lo user space esegue i processi. Per CoreXL, Check Point distingue due infrastrutture. Nel Kernel Space Firewall (KSFW) le istanze CoreXL Firewall girano nel kernel. Nello User Space Firewall (USFW) le istanze girano nello user space, modalità disponibile da R80.30 con il kernel Gaia 3.10.

La differenza non è accademica. Dove le istanze girano in user space, un’istanza è un processo: ha un PID, consuma memoria come un processo, può terminare e può essere riavviata da chi sorveglia i processi. Dove girano nel kernel, la stessa logica non compare in nessun elenco di processi e un guasto si manifesta come instabilità di sistema, non come daemon morto.

Da qui derivano due percorsi diagnostici separati. Lo user space si indaga con gli strumenti sui processi e con i log dei daemon. Il kernel si indaga con il kernel debug: si azzerano i flag con fw ctl debug 0, si alloca il buffer con fw ctl debug -buf, si abilitano moduli e flag con fw ctl debug -m, si raccoglie su file con fw ctl kdebug -T -f -o e si chiude di nuovo con fw ctl debug 0. È una procedura invasiva: la documentazione avverte che il debug aumenta il carico sulla CPU, consiglia una finestra di manutenzione e l’accesso da console seriale o SSH per non perdere la CLI se la CPU sale.

Il WatchDog: chi tiene in vita i processi

Il Check Point WatchDog (cpwd) è il processo che invoca e monitora i processi critici sulla macchina locale e tenta di riavviarli se falliscono. L’utility cpwd_admin ne mostra lo stato e lo configura; il WatchDog scrive le informazioni di monitoraggio in $CPDIR/log/cpwd.elg.

I sottocomandi coprono l’intero ciclo: list e monitor_list per lo stato, start e stop per avviare e fermare un processo monitorato, start_monitor e stop_monitor per il monitoraggio attivo, detach e del per sottrarre temporaneamente un processo alla sorveglianza, getpid, exist e flist per interrogare, config per configurare. Una sola voce non fa quello che il nome suggerisce: kill termina il processo WatchDog, non il processo monitorato.

Investigare senza cancellare le prove

La prima mossa è leggere, non agire. cpwd_admin list stampa lo stato di tutti i processi monitorati con sette colonne: APP, cioè il nome WatchDog del processo, PID, STAT (E per executing, T per terminated), #START, cioè quante volte il WatchDog lo ha avviato, START_TIME, cioè l’ultima volta che lo ha avviato, MON, come lo monitora, e COMMAND, il comando usato per avviarlo.

Quelle colonne separano guasti che altrimenti sembrano identici. Un processo che non parte affatto resta in T con #START fermo. Un processo che parte e muore subito mostra #START che cresce e START_TIME che avanza a ogni lettura: il WatchDog lo sta rimettendo su in continuazione, e visto da fuori il sintomo appare intermittente.

Intorno a questo si dispongono gli altri strumenti. cpstat mostra stato e statistiche delle applicazioni Check Point appoggiandosi al server AMON, in ascolto sulla porta 18192 per impostazione predefinita, e accetta -h per interrogare un gateway gestito dal Management Server. cpview è l’utility testuale integrata che mostra CPU, memoria e spazio su disco, con aggiornamento predefinito ogni 2 secondi modificabile con il tasto R. Il CPU Spike Detective registra i picchi di utilizzo della CPU senza impattare le prestazioni e si interroga da Gaia Clish con show spike-detective. Quando il caso arriva a Check Point Support, la raccolta con cpinfo è obbligatoria.

Trappole tipiche d’esame

  • Riavviare prima di aver verificato lo stato. Un riavvio del daemon o dei servizi azzera proprio il contesto che serve: PID, START_TIME e la progressione di #START sono la prova del comportamento, e dopo il riavvio non esistono più. Leggi cpwd_admin list almeno due volte a qualche secondo di distanza, poi decidi.
  • Confondere «non parte» con «parte e muore». Sono due diagnosi opposte. Nel primo caso guardi il comando di avvio, i prerequisiti e la licenza; nel secondo guardi $CPDIR/log/cpwd.elg e i log del daemon, perché il processo arriva a partire e poi incontra qualcosa che lo fa uscire. La colonna che li distingue è #START, non STAT.
  • Portare lo strumento sbagliato nel mondo sbagliato. Un kernel debug non mostrerà mai perché un daemon in user space non si avvia, e scorrere l’elenco dei processi non spiegherà un problema che vive nel kernel. In USFW le istanze firewall stanno in user space: prima di scegliere lo strumento, stabilisci in quale infrastruttura gira il firewall su quella macchina.