Tre strumenti, tre domande diverse. cpstat risponde a «quanto vale questo contatore adesso», CPView a «come si muove nel tempo», CPInfo a «com’era tutta la macchina quando è successo». L’esame chiede quale dei tre serve in uno scenario dato.

cpstat: interrogare AMON per un dato preciso

cpstat mostra lo stato e le statistiche delle applicazioni Check Point interrogando il server AMON, che risponde di default sulla porta 18192. La sintassi combina un Application Flag obbligatorio con parametri opzionali:

cpstat [-d] [-h Host] [-p Port] [-s SICname] [-f Flavor] [-o PollingInterval] [-c Count] [-e Period] ApplicationFlag

Gli Application Flag più usati sono os per il sistema operativo, fw per il firewall, vpn, blades, ha per il cluster, mg per il Management Server, oltre a persistency, thresholds, vsx e le flag delle singole blade. Ogni applicazione ha più Flavor, scelti con -f, che selezionano quale gruppo di contatori stampare.

I parametri che fanno la differenza in laboratorio sono tre. Con -o si indica ogni quanti secondi ripetere la raccolta (con 0 gira una volta sola), con -c quante iterazioni fare prima di fermarsi, con -e su quale intervallo calcolare le statistiche. Un esempio documentato: cpstat -f perf -o 2 -c 2 os raccoglie i dati di performance del sistema operativo ogni due secondi per due volte. Il parametro -h merita attenzione a parte: permette di interrogare un altro host gestito indicandone indirizzo, hostname oppure oggetto DAIP, quindi dal Management Server si possono leggere i contatori di un Gateway senza aprirci una sessione. Infine -d esegue in modalità debug e mostra le query e le risposte scambiate.

CPView: la statistica che si muove

CPView è un’utility testuale integrata che mostra dati statistici in tempo reale: informazioni generali come CPU, memoria e spazio su disco, più i contatori specifici delle Software Blade. La documentazione R82 la colloca su Security Gateway, ClusterXL e Security Group su piattaforma scalabile.

La navigazione è tutta da tastiera. Le frecce spostano la selezione e scorrono, Enter entra in View Mode, Esc torna al Menu Mode, Home riporta alla vista iniziale e Q esce. Il refresh è di due secondi per impostazione predefinita e si cambia con R; la barra spaziatrice forza un aggiornamento immediato, P mette in pausa e riprende la raccolta, W alterna la modalità normale e quella wide, C salva la pagina corrente in un file. Quel C è il passaggio che trasforma un’osservazione in una prova allegabile al caso.

CPInfo: raccogliere sul Management e sul Gateway

CPInfo è l’utility che raccoglie i dati diagnostici della macchina Check Point nel momento in cui viene eseguita, e la documentazione è esplicita: raccoglierli è obbligatorio quando si apre un caso al supporto Check Point. Si lancia da Expert mode e produce un archivio da allegare al ticket.

Il punto che il laboratorio insiste a far ripetere è che i CPInfo sono due, non uno. Sul Security Management Server l’archivio contiene la configurazione della gestione: database degli oggetti, policy, licenze, stato dei processi di management, log di sistema del server. Sul Security Gateway contiene il mondo del traffico: interfacce e routing, policy installata e quando, tabelle del kernel, stato delle blade di ispezione, contatori di accelerazione. Nessuno dei due può rispondere alle domande dell’altro, e il supporto li chiede entrambi proprio per questo.

Due accortezze valgono anche sul campo: controllare lo spazio libero prima di lanciarlo e annotare l’ora della raccolta rispetto a quella del sintomo. Un CPInfo preso il giorno dopo racconta una macchina già rimessa a posto.

Leggere l’output senza perdersi

Un CPInfo si apre con una domanda in mano, mai «per vedere se c’è qualcosa». La sequenza che funziona parte dall’identità della macchina — versione, build, hotfix e blade abilitate — passa allo stato dei processi, dove la tabella di cpwd_admin list dice se qualcosa è terminato o riavviato più volte, e prosegue verso l’area suggerita dal sintomo: routing e interfacce per un problema di flusso, licenze e processi di management per una SmartConsole che non si connette, risorse e contatori per un degrado di prestazioni. Il nome della policy installata e il suo orario sono la prima cosa da confrontare con l’ora in cui il guasto è comparso.

Il confronto batte la lettura singola: due CPInfo dello stesso host, uno di quando funzionava e uno di adesso, mostrano la differenza invece di farla indovinare.

Trappole tipiche d’esame

  • Partire dallo strumento invece che dal sintomo. Se lo scenario descrive un degrado che dura da ore, CPView in tempo reale arriva tardi; se descrive un valore da leggere una volta, montare un debug è sproporzionato. La domanda è sempre quale strumento risponde a quella domanda lì.
  • Raccogliere un CPInfo senza sapere che cosa cercarci. Nelle risposte, «raccogliere un CPInfo» da solo è quasi sempre incompleto: quella corretta dice anche su quale macchina e che cosa si andrà a verificare dentro.
  • Confondere le risorse del Management con quelle del Gateway. cpstat mg interroga il Management Server, CPView è documentato per Gateway, ClusterXL e Security Group: un’opzione che scambia le due macchine è una distrazione preparata.
  • Dimenticare che cpstat può interrogare da remoto. Con -h si legge un host gestito senza collegarsi in SSH, e l’opzione che lo ignora costringe a un passaggio inutile.
  • Leggere -o come durata. -o è l’intervallo fra due raccolte, non il tempo totale: la durata nasce dalla combinazione con -c.