«Non naviga» è una frase, non un guasto. La diagnosi su FortiGate consiste nel trasformarla in una domanda a cui l’apparato sa rispondere: il pacchetto arriva davvero? esce? quale politica lo ha visto e cosa ne ha fatto? La 7.6 mette in fila tre passi — definire il problema, restringerne l’ambito, scegliere lo strumento — e chi salta i primi due finisce a leggere output che non sa interpretare.

Sapere cosa è normale, prima che smetta di esserlo

Il monitoraggio dei comportamenti anomali non è uno strumento: è un confronto. Senza una fotografia dell’apparato in salute non c’è modo di dire se 40.000 sessioni sono tante. Registra periodicamente l’operatività normale e conservane l’output:

get system status
get system performance status
get system session status
get router info routing-table all
diagnose sys session list

execute tac report fa la stessa cosa in grande, fotografando ogni funzione anche se non l’hai configurata: il valore arriva quando lo rilanci durante il guasto e confronti le due uscite. Non allegarlo a un ticket se il supporto non lo ha chiesto: è enorme e quasi sempre superfluo.

L’anomalia si vede in tre posti. Il log eventi dice cosa è cambiato nella configurazione e quando. La tabella delle sessioni si legge cercando schemi strani: nessuna sessione oltre la rete interna, oppure tutte dirette a un unico indirizzo. Il tasso di creazione sessioni va misurato quando tutto funziona, proprio per riconoscerlo quando crolla.

Strato fisico e di rete: quello che si esclude in due minuti

Prima di aprire uno sniffer conviene chiudere i livelli bassi. Stato del collegamento, velocità negoziata e soprattutto contatori di errori e pacchetti scartati si leggono per singola scheda:

diagnose hardware deviceinfo nic port1
diagnose netlink interface list
diagnose ip address list

Un’interfaccia «up» con errori che crescono è un problema fisico travestito da problema di firewall: cavo, transceiver, mismatch di duplex. Un livello più su, get router info routing-table all e execute traceroute dicono se la rotta esiste e se il primo salto è quello atteso. Qui si annida la trappola più comune: FortiGate è un firewall a stati, e una rotta di ritorno diversa da quella di andata produce traffico asimmetrico che l’apparato scarta pur essendo tutto «raggiungibile».

Lo sniffer: il pacchetto arriva davvero?

Lo sniffer risponde a una sola domanda, la più importante: quel pacchetto tocca il FortiGate, e da quale interfaccia?

diagnose sniffer packet <interfaccia> <'filtro'> <verbosita> <conteggio> <tsformat>
diagnose sniffer packet any 'host 10.1.1.20 and port 443' 4 100 l

L’interfaccia può essere any, il filtro va fra apici singoli e none significa nessun filtro. La verbosità va da 1 a 6: 1 stampa le sole intestazioni, 4 aggiunge il nome dell’interfaccia — ed è il livello che serve davvero, perché senza sapere da quale porta è entrato o uscito un pacchetto la cattura racconta metà della storia. Il conteggio ferma la cattura da solo, altrimenti si interrompe con CTRL+C.

Due trappole. Sugli apparati con processori NP il traffico scaricato in hardware non passa dalla CPU: se non disabiliti l’offload, la traccia cambia o non mostra nulla. E l’output scorre più veloce di quanto tu possa leggerlo, quindi predisponi il salvataggio su file. In alternativa la cattura si àncora a una politica con set capture-packet enable, ma servono un disco e il log attivo sulla politica; il PCAP si scarica dai dettagli del log di traffico.

Il debug flow: perché il FortiGate ha deciso così

Se lo sniffer dice che il pacchetto c’è ma non esce, il debug flow spiega la decisione. Si costruisce a pezzi e si avvia alla fine:

diagnose debug flow filter addr 10.1.1.20
diagnose debug flow show function-name enable
diagnose debug enable
diagnose debug flow trace start 100

L’output racconta il percorso in ordine: received a packet con protocollo, porte e interfaccia di ingresso; allocate a new session oppure Find an existing session con la direzione, originale o di risposta; find a route: gw-... via portX; find SNAT con indirizzo e porta scelti; e infine la riga che chiude quasi ogni diagnosi, Allowed by Policy-3: SNAT. Se quella riga manca, o riporta un identificativo di politica diverso da quello che credevi, il problema non è la rete: è l’ordine delle regole.

Anche qui l’offload NP acceca lo strumento, e per aggirarlo si prova con ICMP, che non viene scaricato in hardware. Soprattutto: con FortiAnalyzer o FortiGate Cloud collegati il debug flow viene registrato come log eventi e ne genera una quantità notevole. Tienilo acceso il tempo minimo e chiudi sempre con diagnose debug flow trace stop e diagnose debug disable.

Il terzo punto di vista: la tabella delle sessioni

Sniffer e debug flow guardano il pacchetto; la tabella delle sessioni guarda la conversazione. Si filtra prima, una riga per criterio, e si elenca poi:

diagnose sys session filter src 10.11.101.112
diagnose sys session filter dport 443
diagnose sys session list

Serve a due cose: ricavare la politica che sta gestendo davvero una connessione, e verificare il NAT sorgente visto da fuori. I filtri nsrc e nport trovano la sessione partendo da indirizzo e porta tradotti, l’unico appiglio quando la segnalazione arriva dal capo opposto del collegamento. Se serve costringere un flusso a ricostruirsi, lo stesso filtro seguito da diagnose sys session clear azzera solo le sessioni selezionate: controlla il filtro due volte prima di premere invio.