Dal sintomo al comando: scegliere il livello

Un ticket che dice “il gateway non passa traffico” non è una diagnosi: è un sintomo che può nascere a quattro livelli diversi. La policy installata può essere vecchia o assente. Un processo in user space può essere morto e rientrare in un ciclo di riavvii. Il kernel può scartare i pacchetti in un punto preciso della catena di ispezione. Oppure il guasto non è affatto sul gateway, ma nel canale che lo lega al Management Server. Il mestiere del troubleshooter esperto è scegliere, per ogni sintomo, il comando che dà la risposta più economica: quello che costa meno CPU e non distrugge lo stato da cui dipende la diagnosi successiva.

La regola operativa è una sola, e vale anche come criterio per rispondere all’esame: si sale di costo, non si parte dall’alto. Prima i comandi di sola lettura, poi la cattura del traffico, e solo alla fine il debug del kernel, l’unico strumento capace di mettere in ginocchio una macchina in produzione.

Policy e processi: la fotografia che non si può rifare

fw stat restituisce il nome della policy installata, la data dell’ultima installazione e le interfacce protette, con la direzione in cui la policy le protegge. Con -l aggiunge le statistiche per interfaccia (pacchetti totali, rifiutati, scartati, accettati), con -s stampa una riga per interfaccia. La documentazione R82 lo dichiara mantenuto solo per retrocompatibilità e indica cpstat -f policy fw come strumento attuale: le due strade rispondono alla stessa domanda, e riconoscerle entrambe evita di scartare l’opzione corretta.

cpwd_admin list è la fotografia dei processi sorvegliati dal WatchDog, e va letta per colonne. APP è il nome WatchDog del processo monitorato, PID il suo identificativo, STAT vale E quando il processo è in esecuzione e T quando è terminato. #START dice quante volte il WatchDog lo ha avviato: un numero alto su una macchina accesa da poco racconta un ciclo di crash e riavvio che nessun altro comando dichiara. START_TIME è l’ultimo avvio, MON indica se il monitoraggio è attivo (Y) o passivo (N), COMMAND la riga con cui il processo è stato lanciato. Il parametro -full aggiunge timeout, limiti di risorsa e percorsi completi.

Questa tabella è volatile: un cpstop seguito da cpstart la azzera, #START torna basso, START_TIME si allinea, e la prova che il processo rientrava in loop sparisce insieme al sintomo. Si raccoglie prima, si agisce dopo.

Risorse, CoreXL e percorso del pacchetto

CPView è l’utility testuale integrata che mostra in tempo reale CPU, memoria, spazio disco e i dati delle Software Blade. Si naviga con le frecce; Enter entra in View Mode, Esc torna al Menu Mode, R cambia la frequenza di aggiornamento (due secondi per impostazione predefinita), P mette in pausa la raccolta, Q esce. È il modo più rapido per capire se il sintomo è saturazione e non configurazione.

Quando il sospetto riguarda la distribuzione del carico, fw ctl affinity -l mostra su quali core sono attestate le interfacce, le istanze firewall CoreXL (fw_0, fw_1 e seguenti) e i demoni in user space come fwd. L’opzione -a estende a tutte le affinità correnti, -v aggiunge i numeri di IRQ delle interfacce, -r ribalta la vista partendo dai core.

Se invece il traffico entra e non esce, la domanda diventa dove viene toccato il pacchetto. fw ctl chain elenca i moduli della catena di ispezione, separati per senso inbound e outbound e ordinati per priorità, dai valori negativi in su: è la mappa che serve prima di catturare qualsiasi cosa. fw monitor 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. Con -e si passa l’espressione INSPECT, con -o il file in formato pcap, da scrivere sempre con percorso completo sulla partizione più capiente, tipicamente /var/log. Un avvertimento documentato: quei filtri INSPECT non si applicano al traffico accelerato. Solo se anche questo livello non basta si scende al debug del kernel.

Trappole tipiche d’esame

Ricostruire la SIC prima di averla accusata con prove. Uno scenario che descrive un gateway irraggiungibile da SmartConsole invita a rispondere “reset e init della SIC”. È quasi sempre la risposta sbagliata: il reset revoca il certificato, impone una reinstallazione della policy per distribuire la CRL aggiornata e cancella proprio il contesto che serviva a capire. Prima si dimostra che la fiducia è rotta, poi la si ricostruisce.

Riavviare i processi prima di averne raccolto lo stato. Un cpstop e cpstart risolve il sintomo e distrugge la prova. Quando fra le opzioni una contiene un riavvio e un’altra una raccolta, la raccolta viene prima, a meno che il testo dichiari esplicitamente che lo stato è già stato acquisito.

Attribuire al gateway un guasto che sta nel canale verso il Management Server. Policy che non si installa, log che non arrivano, stato non comunicante in SmartConsole: sono sintomi del canale, non del motore di enforcement. Se il gateway ha una policy installata, i processi in stato E e risorse normali, il difetto è altrove, e ogni minuto speso sul gateway è perso.