La modalità di ispezione non è una manopola delle prestazioni: è una lista di funzioni. Quando in una policy scegli flow al posto di proxy non stai chiedendo al FortiGate soltanto di andare più veloce, gli stai togliendo la capacità di ricostruire il contenuto, e con essa una serie precisa di controlli. L’esame lo verifica quasi sempre allo stesso modo: un estratto di configurazione, e la domanda su perché una funzione non compaia nella GUI. La risposta sta nella modalità.
Come si comportano i due motori
In flow mode il traffico che attraversa la policy non viene bufferizzato. Il payload è ispezionato pacchetto per pacchetto e il FortiGate trattiene l’ultimo pacchetto finché la scansione non produce un verdetto. Se rileva una violazione invia un pacchetto di reset al ricevente: la connessione si chiude e il payload non arriva completo. Tutti i moduli flow applicabili vengono applicati simultaneamente in un singolo passaggio, con pattern matching Direct Filter Approach (DFA) che viene offloadato e accelerato dai processori CP8 o CP9. È la modalità selezionata di default sulle policy nuove ed è quella raccomandata, a meno che non ti servano funzioni specifiche del proxy.
In proxy mode il FortiGate bufferizza davvero. I pacchetti di un file, di un messaggio email o di una pagina web restano fermi sul firewall finché l’intero payload non è stato ispezionato; poi il contenuto viene rilasciato al destinatario oppure scartato e sostituito con un replacement message. Da questa differenza discendono due leve che in flow non hai: puoi bloccare o ignorare i file che superano una certa dimensione, e puoi attivare il client comforting, che invia al client piccole porzioni del payload durante la scansione per evitare il timeout.
Cosa esiste solo in proxy
Alcune capability dei security profile sono disponibili solo in proxy: Video Filter, Inline CASB, Web Application Firewall, Content Disarm and Reconstruction, le quota web e la Sandbox Inline Scanning. Altre sono proxy in senso stretto, cioè non hanno nemmeno un equivalente flow: SSL Offloading, Explicit Web Proxy e ZTNA.
Due righe della tabella di confronto sembrano contraddittorie e non lo sono. Data Loss Prevention in flow mode è configurabile da CLI ma non compare nella GUI; SSH Filter in flow non esiste affatto e in proxy è raggiungibile solo da CLI. Se un esercizio ti mostra un profilo che «non c’è» nella GUI, chiediti prima se è semplicemente nascosto: per configurare i profili in una firewall policy da CLI devi abilitare utm-status.
Sul web filter il flow mode perde tre cose in modo netto: la Category Usage Quota, il Web Profile Override e quasi tutte le Proxy Option, di cui sopravvivono solo HTTP POST Action e Remove Cookies. In più, in flow le local category e le remote category non supportano le azioni warning e authenticate e non possono essere sottoposte a override.
Certificate inspection: cosa vede il firewall senza decifrare
FortiOS include quattro profili SSL/SSH precaricati. Tre sono in sola lettura e vanno clonati per essere modificati — certificate-inspection, deep-inspection e no-inspection — mentre custom-deep-inspection è direttamente editabile.
Con la certificate inspection il FortiGate ispeziona soltanto le intestazioni fino al livello SSL/TLS: non apre il payload. È la scelta giusta quando devi controllare l’accesso ai siti senza decifrare, tipicamente per ragioni di privacy. Il prezzo è che il filtraggio web si regge interamente su ciò che resta visibile in chiaro nell’handshake, cioè l’SNI del ClientHello e il certificato restituito dal server.
Qui vive il parametro che l’esame chiede più spesso, il Server certificate SNI check. Con enable, se l’SNI dell’hello non combacia con il campo CN o SAN del certificato restituito, il FortiGate usa il CN del certificato del server per il filtraggio URL. Con strict un mismatch chiude la connessione. Con disable il controllo non viene fatto.
Ricorda anche che il profilo certificate-inspection integrato è in sola lettura e ascolta solo sulla porta 443: se il server pubblica su una porta non standard devi creare un profilo nuovo e aggiungere quella porta al campo HTTPS, oppure abilitare Inspect All Ports.
Porte e versioni TLS si comportano in modo diverso
Il protocol port mapping funziona solo con l’ispezione proxy. In flow mode, con la deep inspection attiva, tutte le porte vengono comunque scansionate, che Inspect all ports sia abilitato o no. Con la certificate inspection, invece, flow e proxy si comportano allo stesso modo: se Inspect all ports è disabilitato viene ispezionato solo quanto elencato in Protocol Port Mapping.
Il controllo della versione SSL non è supportato in flow-based inspection. I comandi seguenti hanno effetto solo su policy proxy.
config firewall ssl-ssh-profile
edit "custom-deep-inspection"
config https
set min-allowed-ssl-version tls-1.2
set unsupported-ssl-version block
end
next
end
Come scegliere, in pratica
Parti da flow e passa a proxy solo sulle policy che hanno davvero bisogno di una funzione proxy-only. Applicare lo stesso scan mode a tutte le policy aiuta a ottimizzare le prestazioni: evita il misto senza una ragione.
E tieni a mente il vincolo che fa fallire più configurazioni di ogni altro: il feature set del profilo web filter deve coincidere con l’inspection mode della firewall policy che lo usa. Se nella GUI non vedi nemmeno il selettore Feature set, abilitalo da CLI.
config system settings
set gui-proxy-inspection enable
end