Un guasto su Check Point non si risolve conoscendo più comandi degli altri: si risolve avendo un ordine. L’esame lo verifica chiedendo quale mossa viene prima, non quale strumento è più potente.

Il metodo prima dello strumento

La metodologia di troubleshooting è una sequenza identica su ogni caso: definire il problema in termini osservabili, delimitarne il perimetro, formulare un’ipotesi verificabile, provarla con un test capace anche di smentirla, applicare una sola correzione per volta e confermare che il sintomo sia davvero scomparso. Ogni passo deve produrre un fatto, e ogni fatto deve restringere il campo.

Definire il problema significa trasformare «la VPN non funziona» in una frase misurabile: quali sorgenti, verso quale destinazione, su quale servizio, da quando, sempre o a intermittenza, per tutti o per alcuni. Poi viene la domanda che chiude più casi di qualunque debug: che cosa è cambiato — un’installazione di policy, un hotfix, una modifica di routing a monte, un certificato rinnovato.

Delimitare il perimetro vuol dire stabilire se il guasto è del traffico o della gestione: l’amministratore che non apre SmartConsole e l’utente che non naviga sono problemi diversi anche se arrivano nella stessa telefonata. Infine, una modifica per volta: due correzioni insieme non dicono quale ha funzionato.

Il modello OSI come griglia di isolamento

Nel troubleshooting il modello OSI non serve a classificare protocolli: serve a decidere dove fare il prossimo test. Ogni livello ha una domanda propria e una prova che la chiude.

Ai livelli 1 e 2 chiedi se il collegamento esiste: stato e velocità delle interfacce, duplex, VLAN, risoluzione ARP verso il next hop. Al livello 3 chiedi se il pacchetto sa dove andare: tabella di routing, interfaccia di uscita, NAT, anti-spoofing e topologia degli oggetti. Al livello 4 chiedi se la sessione si apre: porta corretta, handshake completo, timeout, tabella delle connessioni. Sopra entrano le Software Blade che ispezionano il contenuto — Application Control, URL Filtering, Threat Prevention, HTTPS Inspection — dove un traffico regolare a livello 4 può essere fermato per motivi che a livello 4 non si vedono.

Le strategie sono tre: bottom-up quando il guasto è fisico o appena comparso, top-down quando un solo servizio è rotto, divide et impera quando esiste un test economico e decisivo. Un ping che passa mentre la connessione TCP muore elimina tre livelli con una prova sola.

Le risorse per diagnosticare Gateway e Management su Gaia

Le due macchine condividono il sistema operativo ma non gli strumenti utili, e confonderle costa punti.

Su entrambe Gaia offre il Gaia Portal, la cui pagina Overview espone widget di stato: System Overview con prodotto, versione, kernel edition, numero di build, uptime e piattaforma hardware; Blades con le Software Blade installate; Network Configuration con interfacce, indirizzi e stato del link; più grafici di CPU, memoria, packet rate e throughput. In Gaia Clish le stesse informazioni si leggono con show version all, show version os, show version product e show uptime.

Sempre su entrambe vive il WatchDog: cpwd_admin list stampa lo stato dei processi monitorati nelle colonne APP, PID, STAT, #START, START_TIME, MON e COMMAND. STAT vale E per un processo in esecuzione e T per uno terminato; MON vale Y per il monitoraggio attivo e N per quello passivo. Un #START alto con uno START_TIME recente è la firma di un processo che continua a morire e a essere riavviato.

cpstat interroga il server AMON e cambia significato secondo la macchina: la flag mg riguarda il Management Server, mentre fw, vpn e blades hanno senso sul Gateway; os vale su entrambe. CPView, il monitor testuale a schermo intero, è documentato per Security Gateway, ClusterXL e Security Group su piattaforma scalabile. CPInfo si raccoglie su tutte e due, ma il contenuto è diverso. Il CPU Spike Detective registra i picchi di CPU e si governa da Gaia Clish con show spike-detective e set spike-detective (gClish sulle piattaforme scalabili).

Lab: analizzare risorse e prestazioni

L’esercizio del modulo segue questa scaletta: prima la fotografia statica — versione, build, uptime, blade abilitate, spazio su disco — poi i processi con cpwd_admin list, poi CPU e memoria osservate mentre il sintomo si manifesta, infine la correlazione fra il picco e ciò che lo ha prodotto. Un disco pieno sul Management Server e un processo che si riavvia in ciclo danno sintomi diversissimi, e nessuno dei due si vede guardando il traffico.

Trappole tipiche d’esame

  • Partire dallo strumento invece che dal sintomo. Negli scenari la risposta corretta è quasi sempre il passo che restringe il campo, non quello che raccoglie più dati: «lanciare un debug del kernel» è raramente la prima mossa.
  • Saltare l’isolamento per livelli. Se la domanda ti dà già un indizio — il ping passa, l’interfaccia è up, la regola c’è — quell’indizio serve a escludere livelli, non a saltare al comando preferito.
  • Raccogliere un CPInfo senza sapere che cosa cercarci. Il CPInfo è una fotografia completa, non una diagnosi: senza una domanda precisa diventa solo un archivio da spedire al supporto.
  • Confondere le risorse del Management con quelle del Gateway. Un’opzione che mette una flag cpstat da Gateway sul Management Server, o CPView su un Management, è lì apposta: chiediti sempre su quale macchina ti ha messo la domanda.
  • Scambiare l’uptime della macchina per quello dei processi. Un server acceso da mesi può avere un daemon riavviato dieci minuti fa: lo dice cpwd_admin list.