Il laboratorio non chiede di riparare: chiede di misurare. Le due prove di questo modulo, verificare lo stato dei processi e analizzarne la connettività, si superano con pochi comandi letti bene e con la disciplina di non toccare nulla prima di aver registrato la situazione di partenza.

Fotografare lo stato dei processi

cpwd_admin list stampa lo stato di tutti i processi monitorati dal WatchDog. Le colonne sono APP, PID, STAT, #START, START_TIME, MON e COMMAND. APP è il nome WatchDog del processo; STAT vale E per executing e T per terminated; #START conta quante volte il WatchDog ha avviato quel processo; START_TIME è l’ultimo avvio; MON dice come il WatchDog lo sorveglia; COMMAND è il comando con cui lo lancia, ed è esattamente ciò che devi riprodurre se provi un avvio manuale.

Tre comandi completano la fotografia. cpwd_admin getpid restituisce il PID di un singolo processo monitorato. cpwd_admin exist verifica che il WatchDog stesso sia vivo: se non lo è, l’assenza di riavvii non dice nulla sui processi. cpwd_admin flist salva su file lo stato di tutti i processi monitorati, ed è il modo pulito di conservare il «prima» da confrontare con il «dopo».

cpwd_admin monitor_list stampa invece lo stato dei processi attivamente monitorati, con colonne diverse: APP, FILE_NAME, NO_MSG_TIMES e LAST_MSG_TIME. Il monitoraggio attivo si appoggia ai messaggi che il processo produce, quindi qui leggi da quanto tempo quel processo non dà più segno di sé. Un processo in E che ha smesso di mandare messaggi è vivo per il sistema operativo e muto per il WatchDog: è un guasto che list da solo non mostra.

Sospendere il WatchDog senza falsare la prova

Se fermi un daemon monitorato per provarne l’avvio a mano, il WatchDog lo riavvia e tu stai misurando il WatchDog. Per questo si usa cpwd_admin detach, che stacca temporaneamente il processo dal monitoraggio: il processo resta vivo, ma sparisce dall’output di list. La modifica vale finché tutti i servizi Check Point non ripartono al boot o con cpstart.

cpwd_admin stop ferma un processo monitorato e vuole il comando di arresto corretto: si passano -name, -path con il percorso completo dell’eseguibile e -command con il comando e i suoi argomenti, per esempio fw kill fwm per FWM o cpd_admin stop per CPD. Anche questa modifica non sopravvive al riavvio. start riavvia il processo come monitorato; stop_monitor e start_monitor sospendono e riprendono il monitoraggio attivo; del rimuove temporaneamente il processo dal database dei monitorati. E ricorda che kill agisce sul WatchDog, non sul processo che stai indagando.

Analizzare la connettività dei processi

Un processo vivo che non risponde è un problema di connettività, non di stato. cpstat mostra stato e statistiche delle applicazioni Check Point per famiglia: fw, os, ha, blades, vpn, ips, dlp, mg, persistency. Si appoggia al server AMON, in ascolto sulla porta 18192 per impostazione predefinita, e accetta -h per interrogare un Security Gateway gestito dal Management Server indicandone indirizzo IPv4, hostname oppure oggetto DAIP.

Da qui si ricava un test pulito. Se cpstat eseguito in locale sul gateway risponde e cpstat -h lanciato dal Management Server no, il processo sta funzionando e il difetto è sul percorso verso AMON: rete, NAT o fiducia fra i due nodi. Il caso contrario indica un’applicazione che non pubblica più i propri contatori.

I parametri -o, -c ed -e ripetono la rilevazione a intervalli: due campioni dicono se un contatore si muove, mentre uno solo dice soltanto che esiste. Per il contesto di sistema, cpview si aggiorna ogni 2 secondi, si naviga con le frecce, Enter entra nella vista, Esc torna al menu e Q esce.

Trappole tipiche d’esame

  • Riavviare prima di verificare. Il riavvio distrugge i dati che servono: PID, START_TIME e la progressione di #START. La sequenza corretta è cpwd_admin list, poi monitor_list, poi flist per salvare l’istantanea, e solo dopo un’azione correttiva.
  • Confondere un processo che non parte con uno che parte e muore. Nell’output di list il primo resta in T con #START immobile; il secondo alterna E e T con #START che cresce e START_TIME che avanza. Se leggi una volta sola non li distingui: rileggi a distanza di qualche secondo.
  • Trattare un problema di user space come se fosse di kernel space. Se un daemon è vivo ma non risponde alle interrogazioni, il difetto sta nel canale applicativo, cioè AMON, la porta 18192, il percorso di rete, e nessun kernel debug lo spiegherà. Prima stabilisci se il processo esiste, poi se parla.