I quattro laboratori del modulo mettono davanti a guasti diversi (traffico che non passa, policy che non fa quello che credi, instradamento sbagliato, NAT che traduce dove non dovrebbe) e a un solo strumento di lettura: la cattura da riga di comando. Il metodo resta lo stesso in tutti e quattro; cambia l’ipotesi che vai a smentire.

Prima di catturare: un’ipotesi e un filtro stretto

Su un gateway in produzione una cattura senza filtro è illeggibile entro pochi secondi. Con fw monitor il filtro semplificato -F prende cinque campi (IP sorgente, porta sorgente, IP destinazione, porta destinazione, numero di protocollo), accetta 0 come “qualsiasi” e ammette fino a cinque istanze in OR; è anche l’unico filtro che si applica al traffico accelerato da SecureXL. Sfrutta le istanze multiple per scrivere anche la tupla invertita: se filtri una sola direzione vedi metà conversazione e concludi male. L’espressione INSPECT di -e è più espressiva, ma non tocca il traffico accelerato.

Poi decidi dove guardare. tcpdump e cppcap stanno sull’interfaccia e ti dicono che cosa è arrivato e che cosa è partito; fw monitor sta nella Firewall Virtual Machine e ti dice che cosa è successo in mezzo, mostrando lo stesso pacchetto ai quattro punti di ispezione: i (pre-inbound), I (post-inbound), o (pre-outbound), O (post-outbound). Salva sempre su file (-o per fw monitor, -o per cppcap) invece di leggere a schermo: la sequenza dei punti si ricostruisce con calma, non a memoria.

Traffico fondamentale e problemi di policy

Il primo laboratorio è una domanda sola: il pacchetto arriva davvero? Se tcpdump o cppcap sull’interfaccia di ingresso non mostrano nulla, il guasto è a monte del gateway (instradamento del client, VLAN, ARP, apparato intermedio) e continuare a debuggare il firewall è tempo perso. Se arriva sull’interfaccia ma fw monitor non lo vede al punto i, il primo sospetto è il tuo filtro, non il prodotto.

Il secondo laboratorio comincia dove il pacchetto c’è a i e non c’è a I: è stato scartato durante l’ispezione in ingresso, e il primo indiziato è la rule base. Qui vale una regola di lettura: fw monitor non registra il drop, registra un’assenza. Il drop lo deduci dal punto che manca, e il nome della regola che lo ha causato lo leggi nei log in SmartConsole, non nella cattura. Se la connessione non compare nemmeno nei log, chiediti se la regola che la scarta ha il tracking impostato: una regola senza log produce esattamente lo stesso silenzio di una regola che non esiste.

Instradamento e NAT

Per l’instradamento la prova sta nel nome dell’interfaccia che fw monitor stampa su ogni riga. Se il pacchetto è a i e a I ma non compare a o su nessuna interfaccia, non è mai stato instradato; se compare a o sull’interfaccia sbagliata, la tabella di routing non è quella che pensavi. Il caso più insidioso è il ritorno: la richiesta esce, la risposta rientra da un’altra strada e la connessione muore in modo asimmetrico. Si vede solo catturando entrambe le direzioni, ed è il motivo per cui la tupla invertita nel filtro non è un lusso.

Per il NAT la tecnica è il confronto fra i quattro punti. Cattura la stessa connessione e guarda a quale transizione cambiano indirizzo e porta: se cambiano fra i e I la traduzione è avvenuta sul lato in ingresso, se cambiano fra o e O sul lato in uscita. Una cattura di sola interfaccia non te lo dirà mai: vedrai un indirizzo da una parte e un altro dall’altra, senza sapere dove sia successo il passaggio. Ricorda anche che un NAT sbagliato si presenta spesso travestito da problema di routing, perché il traffico di ritorno viene indirizzato a un indirizzo che nessuno sa raggiungere.

Trappole tipiche d’esame

  • Scambiare l’uscita di fw monitor per quella di tcpdump. Sono due punti diversi della catena. Un pacchetto visto da tcpdump sull’interfaccia non è stato ancora accettato da nessuna regola, e un pacchetto visto da fw monitor a I non è detto che sia mai uscito sul cavo. Nello scenario del laboratorio sulla policy, questa confusione fa dichiarare “il traffico passa” quando il gateway lo sta scartando un passo più in là.
  • Non distinguere i punti di ispezione i, I, o, O. Sono l’unico modo per separare un problema di policy da uno di routing e da uno di NAT: manca I, guarda le regole; manca o, guarda l’instradamento; cambia l’indirizzo fra due punti, stai guardando la traduzione. E la direzione è quella del pacchetto, non della connessione: la risposta del server è inbound sull’interfaccia da cui rientra, quindi ricompare come i e I.
  • Attribuire a un flag un effetto sulla verbosità che non ha. Se la cattura sembra povera, prima di alzare qualsiasi livello verifica quanto stai catturando di ogni frame: in cppcap -c limita i byte per frame con default 96, e il payload troncato non torna con nessuna opzione di visualizzazione. Allo stesso modo -w e -W governano la rotazione dei file, -f il filtro: nessuno dei tre aggiunge dettaglio al pacchetto.