Su un FortiGate, «routing statico» non significa scrivere una default route e andare a casa. Le domande d’esame su questo dominio arrivano quasi sempre come un estratto di get router info routing-table all da interpretare: quale rotta è finita in tabella, perché quella e non l’altra, e in che ordine viene consultata rispetto alle policy route.

Cosa contiene davvero una rotta statica

La destinazione può essere una subnet, un oggetto indirizzo o un Internet Service. Non tutti gli address object sono ammessi: nell’elenco compaiono solo quelli con la configurazione per il routing statico abilitata, e gli indirizzi di tipo geography non si possono usare. Per instradare verso un FQDN serve prima abilitare allow-routing sull’oggetto.

config firewall address
    edit "Fortinet-Documentation-Website"
        set type fqdn
        set fqdn docs.fortinet.com
        set allow-routing enable
    next
end

Poi ci sono i tre numeri che decidono tutto. La distanza amministrativa va da 1 a 255 con default 10 e sceglie fra rotte concorrenti prima che entrino in tabella. La priorità va da 1 a 65535 con default 1 e agisce dopo, fra rotte già in tabella con la stessa distanza: vince il valore più basso. Il peso, da 0 a 255, serve al bilanciamento ECMP.

La trappola più frequente riguarda la default route appresa via DHCP. Sui modelli entry-level la WAN è preconfigurata in DHCP e la rotta appresa entra con distanza 5, quindi batte la tua default statica a distanza 10. Se la tua rotta sembra sparita, guarda l’interfaccia prima della rotta: puoi disabilitare il recupero del gateway dal server oppure cambiare quella distanza.

Infine la blackhole route, che scarta il traffico invece di reinstradarlo. Serve quando non vuoi che il traffico esca da un’altra parte: se un tunnel IPsec cade, senza blackhole il traffico per la sede remota ricadrebbe sulla default route verso Internet, o su un altro tunnel. Per questo la creazione guidata IPsec le crea da sola.

Tre tabelle, non una

Molti errori di lettura nascono dal confondere tre oggetti diversi. Il routing database contiene tutte le rotte apprese da tutti i protocolli, comprese quelle scartate: le selezionate sono marcate con il simbolo di maggiore, quelle installate nella FIB con l’asterisco. La routing table contiene solo le migliori. La kernel routing table è la FIB vera, quella consultata pacchetto per pacchetto.

get router info routing-table all
get router info routing-table database
get router info kernel
get router info routing-table details 4.4.4.4

Il criterio di selezione, in ordine: vince sempre la rotta più specifica; a parità di prefisso vince la distanza più bassa; se la distanza è pari entrano tutte in tabella e decidono costo e priorità; se sono uguali anche quelli, il traffico viene distribuito in ECMP.

Una riga si legge così. In B 192.168.0.0/24 [20/0] via 172.31.0.1, MPLS, 00:31:43 la lettera è il protocollo di origine, la coppia fra parentesi è distanza e metrica, poi next hop, interfaccia di uscita e anzianità della rotta. Le rotte connesse non hanno next hop. Nella GUI le stesse informazioni stanno in Dashboard > Network, widget Routing, dove Route Lookup ti dice quale rotta prenderebbe un pacchetto verso una destinazione.

Due dettagli che si pagano cari: con i VDOM abilitati i comandi di routing vanno dati dentro un VDOM, non nel contesto global; e il VRF segmenta ulteriormente, perché i pacchetti passano solo fra interfacce con lo stesso VRF.

L’ordine in cui il FortiGate decide

Il route lookup avviene tipicamente due volte nella vita di una sessione: sul primo pacchetto dell’iniziatore e sul primo di risposta. L’esito finisce nella session table, ed è il motivo per cui una modifica alla tabella non si riflette subito sul traffico in corso.

L’ordine di consultazione è: prima le policy route, poi la FIB; se nessuna delle due produce una corrispondenza il pacchetto viene scartato. Le policy route si valutano dall’alto verso il basso e vince la prima che contiene abbastanza informazioni per instradare. Abbastanza significa almeno l’interfaccia di uscita oppure il gateway: se ne indichi uno solo, il FortiGate cerca l’altro nella routing table, e se non lo trova quella policy route non corrisponde e si continua con l’elenco. Anche indicandoli entrambi deve comunque esistere una rotta che renda quel gateway raggiungibile da quell’interfaccia.

RPF, cambi di rotta e sessioni già aperte

Su ogni pacchetto in ingresso il FortiGate fa un lookup inverso sull’IP sorgente per capire se è arrivato da un’interfaccia legittima: è il controllo RPF, e protegge dallo spoofing. La modalità di default, feasible path, chiede solo che esista almeno una rotta attiva verso la sorgente attraverso l’interfaccia di ingresso; in modalità strict la rotta migliore verso la sorgente deve essere proprio quell’interfaccia.

config system settings
    set strict-src-check enable
end

È la spiegazione di metà dei pacchetti scartati «senza motivo»: se un’interfaccia non ha una rotta di ritorno, il traffico entrante da lì muore prima ancora delle policy.

Quando la tabella cambia, il comportamento predefinito dipende dal NAT. Senza SNAT il FortiGate svuota le informazioni di routing dalla session table e rifà il lookup; abilitando preserve-session-route sull’interfaccia le sessioni esistenti restano invece sulla vecchia strada. Con SNAT il default è opposto: le sessioni continuano a uscire dalla stessa interfaccia finché la vecchia rotta è attiva, a meno di abilitare snat-route-change.