Expert - Architecture & Optimisation

Module 9 : High Availability (HA)

Objectifs du module

Configurer le HA Actif/Actif et Actif/Passif
Comprendre le heartbeat, les synchronisations et le failover
Configurer le session sync et la synchronisation de configuration
Trouver et dépanner les problèmes HA

32

Concepts HA — Actif/Passif vs Actif/Actif

HA Groups, heartbeat, synchronisation, failover

25 min

High Availability FortiGate

Mode	Description	Avantages
Actif/Passif (A/P)	Un seul appareil actif, l'autre en attente	Simple, basculement rapide
Actif/Actif (A/A)	Deux appareils actifs, load-balancing	Meilleure utilisation des ressources

Démonstration pas à pas : Comparez A/P simple et rapide pour la plupart des sites contre A/A qui répartit la charge mais complexifie, prévoyez un lien heartbeat dédié comme ha1 avec intervalle d une seconde, et exigez mêmes modèles et firmware.

Heartbeat : Le lien de redondance entre les deux FortiGate, via un port dédié (recommandé) ou un port existant.

Pourquoi c'est important : Sans HA, la panne d un FortiGate unique coupe Internet et les VPN pour tout le site. Avec un cluster actif-passif ou actif-actif et un heartbeat en UDP 1944, le second prend le relais en quelques secondes.

L'analogie qui aide : Le HA, c est la doublure au théâtre : l actif joue sur scène, le passif connaît le texte par coeur grâce au heartbeat, et prend la scène sans que le public voie la bascule.

Protocole UDP sur port 1944 (HA heartbeat)
Intervalle par défaut : 1 seconde
Port recommandé : port dédié (ex: port9, ha1, ha2)

Pièges classiques : Croire que A/A double automatiquement le débit sans réglage ; utiliser un port de production pour le heartbeat ; mélanger des versions de firmware entre membres.

À vous de jouer : Quel mode HA pour un site qui veut la simplicité maximale ?

Voir la réponse

Le mode actif-passif, avec un seul actif, une configuration synchronisée et un basculement rapide et lisible.

33

Configuration HA Actif/Passif

HA group, priority, override, session pickup

30 min

Configuration HA Actif/Passif

Pourquoi c'est important : Deux maîtres avec le même group-name mais des priorités incohérentes provoquent des bascules incessantes. Avec Cluster_Prod, priorité 200 contre 100, override et session-sync, le rôle de chacun est déterministe.

L'analogie qui aide : Configurer le HA, c est désigner un capitaine et son remplaçant : priorité 200 pour le titulaire, 100 pour le remplaçant, même nom d équipe Cluster_Prod et liaison ha1 toujours branchée.

# === Primary (Master) ===
FGT60F # config system ha
FGT60F (ha) # set mode a-p
FGT60F (ha) # set group-name "Cluster_Prod"
FGT60F (ha) # set priority 200
FGT60F (ha) # set override enable
FGT60F (ha) # set hbdev "ha1" 0
FGT60F (ha) # set session-sync enable
FGT60F (ha) # set route-wait enable
FGT60F (ha) # set route-ttl 10
FGT60F (ha) # set hello-holddown 20
FGT60F (ha) # set ha-uptime-diff-factor 5
FGT60F (ha) # set ha-device-id-factor mac
FGT60F (ha) # set unicast-hb enable
FGT60F (ha) # end

# === Secondary (Slave) ===
FGT60F # config system ha
FGT60F (ha) # set mode a-p
FGT60F (ha) # set group-name "Cluster_Prod"
FGT60F (ha) # set priority 100
FGT60F (ha) # set override enable
FGT60F (ha) # set hbdev "ha1" 0
FGT60F (ha) # end

# Verifier le statut HA
FGT60F # get system ha status
FGT60F # diagnose sys ha dump-by vcluster
FGT60F # diagnose sys ha dump-by peer

Démonstration pas à pas : Configurez le primary en a-p avec group-name, priority 200, override enable, hbdev ha1, session-sync enable et unicast-hb, configurez le secondary en priorité 100, puis vérifiez avec get system ha status et diagnose sys ha dump-by peer.

Pièges classiques : Oublier override et voir le mauvais membre rester maître ; ne pas activer session-sync et couper les sessions au failover ; négliger route-wait qui fait basculer avant les routes.

À vous de jouer : Que garantissent priority et override ensemble ?

Voir la réponse

Que le membre à 200 reprend la main après retour, sans flottement, car la préemption est autorisée et déterministe.

34

Synchronisation et failover

Sync config, session sync, failover trigger

20 min

Synchronisation HA

Pourquoi c'est important : Sans session-sync, chaque failover coupe les appels et les transferts en cours. Avec la synchronisation de configuration et des sessions sur ha1, les flux survivent à la bascule.

L'analogie qui aide : La synchro HA est comme une répétition en miroir : le passif apprend chaque pas de danse des sessions pour continuer la chorégraphie sans faux pas au signal failover.

# Forcer la synchronisation
FGT60F # execute ha manage 0
FGT60F # diagnose sys session sync clear
FGT60F # execute fabric-restart

# Forcer un failover
FGT60F # execute ha failover

# Diagnostiquer la synchro
FGT60F # diagnose sys ha dump-by vcluster
FGT60F # diagnose sys ha dump-by peer
FGT60F # diagnose sys ha dump-by mtx

# Synchronisation des sessions
# Mode 0 : session-sync (toutes les sessions)
# Mode 1 : session-sync-exclude (exclure certaines)
# Mode 2 : session-sync-filter (inclus only)
FGT60F # config system ha
FGT60F (ha) # set session-sync enable
FGT60F (ha) # set session-sync-dev "ha1"
FGT60F (ha) # end

# Logs HA
FGT60F # execute log filter field type system
FGT60F # execute log filter field module ha
FGT60F # execute log display

Démonstration pas à pas : Activez session-sync et session-sync-dev ha1, surveillez avec diagnose sys ha dump-by vcluster et diagnose sys session sync status, filtrez les logs system module ha, et ne forcez execute ha failover qu en fenêtre de test.

Pièges classiques : Forcer un failover en production pour voir ; couper le lien ha1 pendant la synchro ; ignorer les compteurs de sessions non synchronisées.

À vous de jouer : Que faut-il vérifier avant un failover volontaire ?

Voir la réponse

Que la configuration est synchronisée, que les sessions sont répliquées et que la fenêtre de maintenance est validée avec un plan de retour.

35

HA — Troubleshooting

Dépannage HA, split-brain, heartbeat

20 min

Dépannage HA

Problèmes HA courants

Split-brain — Les deux unités sont maîtres (cause: heartbeat coupé)
Frequents failovers — Priority trop proches, heartbeat instable
Pas de synchronisation — Version firmware différente
MAC flap — Câbleage HA mal configuré

Pourquoi c'est important : Un heartbeat coupé donne deux maîtres en split-brain avec des MAC qui flappent. Le diagnostic va de dump-by vcluster au test ping du heartbeat puis à la vérification des versions.

L'analogie qui aide : Le split-brain, ce sont deux chefs qui donnent des ordres opposés parce que le téléphone heartbeat est coupé : il faut rétablir la ligne avant de décider qui commande.

# Diagnostic HA
FGT60F # diagnose sys ha dump-by vcluster
FGT60F # diagnose sys ha dump-by peer
FGT60F # diagnose sys ha dump-by mtx
FGT60F # diagnose sys ha dump-by status

# Tester le heartbeat
FGT60F # execute ping 10.0.0.2

# Verifier la synchro
FGT60F # diagnose sys session sync list
FGT60F # diagnose sys session sync status

# Forcer la synchro
FGT60F # execute fabric-restart

Démonstration pas à pas : Lancez diagnose sys ha dump-by vcluster, peer et status, testez le heartbeat avec execute ping, contrôlez diagnose sys session sync list et status, puis réunifiez avec execute fabric-restart après avoir fixé le câble ou la version.

Pièges classiques : Redémarrer les deux membres en même temps ; laisser deux firmwares différents ; ignorer les MAC flap qui signalent un câblage en boucle.

À vous de jouer : Quel symptôme signe un split-brain et quelle cause d abord ?

Voir la réponse

Deux unités maîtresses simultanées, causées en premier par la coupure ou l instabilité du lien heartbeat.

Module 10 : FortiManager et FortiAnalyzer

36

FortiManager — Gestion centralisée

ADOM, provisioning, installations, scripts

25 min

FortiManager — Gestion centralisée des FortiGate

FortiManager permet de gérer plusieurs FortiGate depuis une console centralisée.

Pourquoi c'est important : Administrer dix FortiGate un par un multiplie les divergences de politiques. Avec FortiManager et les ADOM, on pousse un package commun depuis 192.168.40.10 et on audite qui a dévié.

L'analogie qui aide : FortiManager est comme la tour de contrôle : chaque avion FortiGate garde son pilote, mais les plans de vol des politiques sont validés et distribués depuis le centre.

# Enregistrer FortiManager depuis FortiGate
FGT60F # config system central-management
FGT60F (central-management) # set type fortimanager
FGT60F (central-management) # set fmg "192.168.40.10"
FGT60F (central-management) # set fmg-source-ip 192.168.40.1
FGT60F (central-management) # end

# Verifier la connexion
FGT60F # diagnose debug application fnbam-daemon -1
FGT60F # diagnose debug enable

# Mode normal (mode managed)
FGT60F # execute central-mgmt run local -manage enable

# Installer les packages
FGT60F # config system central-management
FGT60F (central-management) # set focal-fortigate
FGT60F (central-management) # set enable-fmg-access enable
FGT60F (central-management) # end

Démonstration pas à pas : Déclarez central-management vers fmg 192.168.40.10, vérifiez avec diagnose debug application fnbam-daemon, passez en mode managed, puis installez le package ADOM après révision des différences.

Pièges classiques : Pousser un package sans preview et écraser une exception locale ; mélanger les ADOM et diffuser une politique au mauvais périmètre ; perdre l accès si le FortiManager est injoignable sans procédure locale.

À vous de jouer : Que vérifier avant d installer un package FortiManager ?

Voir la réponse

Le diff avec la configuration locale, le bon ADOM cible et une sauvegarde permettant un retour arrière rapide.

37

FortiAnalyzer — Logs et rapports

Stockage logs, rapports, dashboards, SOAR

25 min

FortiAnalyzer — Analyse et rapports

Pourquoi c'est important : Garder les logs uniquement sur le boîtier les fait écraser par rotation dès 500 Mo. En envoyant en temps réel vers FortiAnalyzer 192.168.40.20 avec reliable-enable, on conserve la preuve pour l audit.

L'analogie qui aide : FortiAnalyzer est comme la boîte noire : même si l avion redémarre, l enregistrement temps réel des événements permet de rejouer l incident et de prouver la conformité.

# Envoyer les logs a FortiAnalyzer
FGT60F # config log fortianalyzer setting
FGT60F (setting) # set status enable
FGT60F (setting) # set server 192.168.40.20
FGT60F (setting) # set source-ip 192.168.40.1
FGT60F (setting) # set serial "FAZ-XXXXXXXX"
FGT60F (setting) # set upload-option realtime
FGT60F (setting) # set interface-select-mode auto
FGT60F (setting) # set reliable-enable enable
FGT60F (setting) # end

# Verifier la connexion FortiAnalyzer
FGT60F # diagnose test application forticloudlogger 3

# Logs locaux en complement
FGT60F # config log disk setting
FGT60F (setting) # set status enable
FGT60F (setting) # set diskfull erase
FGT60F (setting) # set max-logsize 500
FGT60F (setting) # end

Démonstration pas à pas : Activez log fortianalyzer setting vers server 192.168.40.20 en realtime avec reliable-enable, gardez un log disk local en erase avec max-logsize 500 en tampon, puis testez avec diagnose test application forticloudlogger.

Pièges classiques : Tout mettre en best-effort UDP et perdre les logs d attaque ; ne jamais tester la connexion ; saturer le disque sans politique diskfull.

À vous de jouer : Pourquoi activer reliable-enable vers FortiAnalyzer ?

Voir la réponse

Pour garantir la livraison des logs même en cas de microcoupure réseau, sans trou dans la piste d audit.

38

SOC Fabric et intégration

Security Fabric, Fabric Connectors, automation

20 min

Security Fabric et intégration

Pourquoi c'est important : Sans Fabric, chaque outil alerte dans son coin et la réponse reste manuelle. Avec un connecteur syslog et un stitch High_CPU_Alert vers Send_Email, le FortiGate prévient seul l admin.

L'analogie qui aide : Le Security Fabric est comme un système nerveux : le capteur trigger sent la fièvre CPU, le nerf stitch transmet, et la main action envoie le mail sans attendre une ronde humaine.

# Configurer le Security Fabric
FGT60F # config fabric-interconnect
FGT60F (interconnect) # set status enable
FGT60F (interconnect) # set device-id 1
FGT60F (interconnect) # set group-name "Fabric_Prod"
FGT60F (interconnect) # end

# Fabric Connectors
FGT60F # config fabric connector
FGT60F (connector) # edit 1
FGT60F (1) # set name "Syslog_Connector"
FGT60F (1) # set type syslog
FGT60F (1) # set server 10.0.1.200
FGT60F (1) # set port 514
FGT60F (1) # set protocol udp
FGT60F (1) # next
FGT60F (connector) # end

# Automation Stitch
FGT60F # config automation-trigger
FGT60F (trigger) # edit "High_CPU_Alert"
FGT60F (High_CPU_Alert) # set event-type event-log
FGT60F (High_CPU_Alert) # set logid 0100022000
FGT60F (High_CPU_Alert) # next
FGT60F (trigger) # end

FGT60F # config automation-action
FGT60F (action) # edit "Send_Email"
FGT60F (Send_Email) # set action-type email
FGT60F (Send_Email) # set email-to admin@example.com
FGT60F (Send_Email) # set email-from fortigate@example.com
FGT60F (Send_Email) # set email-server mail.example.com
FGT60F (Send_Email) # next
FGT60F (action) # end

FGT60F # config automation-stitch
FGT60F (stitch) # edit "CPU_High_Stitch"
FGT60F (CPU_High_Stitch) # set trigger "High_CPU_Alert"
FGT60F (CPU_High_Stitch) # set action "Send_Email"
FGT60F (CPU_High_Stitch) # next
FGT60F (stitch) # end

Démonstration pas à pas : Créez fabric-interconnect Fabric_Prod, ajoutez le connector syslog vers 10.0.1.200:514 en UDP, créez le trigger event-log, l action email vers admin@example.com, puis liez-les dans le stitch CPU_High_Stitch et testez.

Pièges classiques : Automatiser un blocage sans validation humaine ; multiplier les stitches qui spamment ; oublier de sécuriser le relais mail utilisé par l action.

À vous de jouer : Quel trio forme une automation complète ?

Voir la réponse

Un trigger qui détecte, une action qui exécute et un stitch qui les relie avec journalisation.

Module 11 : Routage Avancé

39

Route statique, Policy Routing, SD-WAN

Routes statiques,策略路由, SD-WAN zones

30 min

Routage avancé FortiGate

Pourquoi c'est important : Avec une seule route par défaut, la coupure du FAI coupe tout le site. Avec deux routes de distances 10 et 20, du policy routing par source et une zone SD-WAN avec health-check vers 8.8.8.8, le trafic bascule proprement.

L'analogie qui aide : Le routage avancé, c est le GPS avec itinéraires bis : la route distance 10 est l autoroute, la distance 20 la déviation, le policy routing envoie les camions par port1 et le SD-WAN surveille le trafic en temps réel.

# Routes statiques
FGT60F # config router static
FGT60F (static) # edit 1
FGT60F (1) # set dst 0.0.0.0/0
FGT60F (1) # set gateway 192.168.1.1
FGT60F (1) # set device port1
FGT60F (1) # set distance 10
FGT60F (1) # set priority 1
FGT60F (1) # next
FGT60F (static) # edit 2
FGT60F (2) # set dst 0.0.0.0/0
FGT60F (2) # set gateway 192.168.2.1
FGT60F (2) # set device port3
FGT60F (2) # set distance 20
FGT60F (2) # set priority 2
FGT60F (2) # next
FGT60F (static) # end

# Policy Routing
FGT60F # config router policy
FGT60F (policy) # edit 1
FGT60F (1) # set input-device port2
FGT60F (1) # set src 10.0.1.0/24
FGT60F (1) # set dst 0.0.0.0/0
FGT60F (1) # set gateway 192.168.1.1
FGT60F (1) # set output-device port1
FGT60F (1) # next
FGT60F (policy) # end

# SD-WAN Zones
FGT60F # config system sdwan
FGT60F (sdwan) # set status enable
FGT60F (sdwan) # config zone
FGT60F (zone) # edit "WAN_Zone"
FGT60F (WAN_Zone) # set interface "port1" "port3"
FGT60F (WAN_Zone) # next
FGT60F (zone) # end

FGT60F (sdwan) # config members
FGT60F (members) # edit 1
FGT60F (1) # set interface "port1"
FGT60F (1) # set zone "WAN_Zone"
FGT60F (1) # set gateway 192.168.1.1
FGT60F (1) # set priority 1
FGT60F (1) # next
FGT60F (members) # edit 2
FGT60F (2) # set interface "port3"
FGT60F (2) # set zone "WAN_Zone"
FGT60F (2) # set gateway 192.168.2.1
FGT60F (2) # set priority 2
FGT60F (2) # next
FGT60F (members) # end
FGT60F (sdwan) # end

# Performance SLA
FGT60F # config system sdwan
FGT60F (sdwan) # config health-check
FGT60F (health-check) # edit "SLA_Internet"
FGT60F (SLA_Internet) # set server 8.8.8.8
FGT60F (SLA_Internet) # set protocol ping
FGT60F (SLA_Internet) # set interval 1000
FGT60F (SLA_Internet) # set probe-timeout 1000
FGT60F (SLA_Internet) # set failure 3
FGT60F (SLA_Internet) # next
FGT60F (health-check) # end
FGT60F (sdwan) # end

Démonstration pas à pas : Créez deux static vers 0.0.0.0/0 par port1 et port3 avec distances 10 et 20, ajoutez une router policy de port2 vers port1 pour 10.0.1.0/24, montez la zone WAN_Zone avec members et health-check ping interval 1000, puis coupez port1 pour valider la bascule.

Pièges classiques : Deux routes égales sans health-check qui balancent au hasard ; oublier la politique pare-feu sur le second lien ; laisser un health-check trop agressif qui flappe.

À vous de jouer : Pourquoi ajouter un health-check au SD-WAN ?

Voir la réponse

Pour ne basculer que sur un lien réellement joignable, mesuré par ping vers une cible fiable, et éviter les bascules sur un lien monté mais muet.

40

BGP et OSPF

Routage dynamique, neighbours, areas, redistribution

35 min

Routage dynamique — OSPF et BGP

Pourquoi c'est important : Déclarer des réseaux en OSPF sans area cohérente isole un site. Avec router-id 10.0.1.1, area 0.0.0.0 et redistribution connected, puis BGP en AS 65001 vers 65002, chaque site apprend les bons préfixes.

L'analogie qui aide : OSPF et BGP sont comme les horaires de trains partagés entre gares : chaque FortiGate publie ses quais 10.0.1.0/24 et lit ceux des voisins pour router sans détour.

# OSPF Configuration
FGT60F # config router ospf
FGT60F (ospf) # set router-id 10.0.1.1
FGT60F (ospf) # config area
FGT60F (area) # edit 0.0.0.0
FGT60F (0.0.0.0) # set type regular
FGT60F (0.0.0.0) # next
FGT60F (area) # end

FGT60F (ospf) # config network
FGT60F (network) # edit 1
FGT60F (1) # set prefix 10.0.1.0/24
FGT60F (1) # set area 0.0.0.0
FGT60F (1) # next
FGT60F (network) # edit 2
FGT60F (2) # set prefix 10.0.2.0/24
FGT60F (2) # set area 0.0.0.0
FGT60F (2) # next
FGT60F (network) # end

FGT60F (ospf) # config redistribute "connected"
FGT60F (ospf) # set status enable
FGT60F (ospf) # end

# BGP Configuration
FGT60F # config router bgp
FGT60F (bgp) # set as 65001
FGT60F (bgp) # set router-id 10.0.1.1
FGT60F (bgp) # config neighbor
FGT60F (neighbor) # edit "10.0.2.1"
FGT60F (10.0.2.1) # set remote-as 65002
FGT60F (10.0.2.1) # set soft-reconfiguration enable
FGT60F (10.0.2.1) # next
FGT60F (neighbor) # end
FGT60F (bgp) # config network
FGT60F (network) # edit 1
FGT60F (1) # set prefix 10.0.1.0/24
FGT60F (1) # next
FGT60F (network) # end
FGT60F (bgp) # end

# Verification
FGT60F # get router info routing-table ospf
FGT60F # get router info bgp summary
FGT60F # get router info bgp neighbors

Démonstration pas à pas : Configurez router ospf avec router-id, area et networks, activez redistribute connected, configurez router bgp AS 65001 avec neighbor 10.0.2.1 en remote-as 65002 et network 10.0.1.0/24, puis vérifiez avec get router info routing-table ospf et bgp summary.

Pièges classiques : Deux router-id identiques qui cassent l adjacence ; redistribuer sans filtre et injecter des milliers de routes ; oublier soft-reconfiguration et couper pour appliquer.

À vous de jouer : Que vérifier si un préfixe BGP n apparaît pas ?

Voir la réponse

Le voisinage, l AS distant, le network déclaré et les filtres, avec get router info bgp neighbors et summary.

Module 12 : Debug et Troubleshooting

41

Diagnostique réseau — Ping, traceroute, sniffer

Outils de diagnostic, capture paquets, debug

25 min

Outils de diagnostic réseau

Pourquoi c'est important : Accuser le pare-feu sans preuve fait perdre des heures. Avec execute ping, traceroute, sniffer sur port1 et debug flow filtré sur 10.0.1.50, on prouve où le paquet s arrête.

L'analogie qui aide : Diagnostiquer, c est ausculter : le ping prend le pouls, le traceroute suit la colonne vertébrale des sauts, le sniffer fait la radio et le debug flow lit l ordonnance du pipeline.

# Ping depuis le FortiGate
FGT60F # execute ping 10.0.1.100
FGT60F # execute ping-options source 10.0.1.1
FGT60F # execute ping 10.0.1.100
FGT60F # execute ping-options repeat-count 10
FGT60F # execute ping-options data-size 1400
FGT60F # execute ping-options timeout 5
FGT60F # execute ping 10.0.1.100

# Traceroute
FGT60F # execute traceroute 8.8.8.8
FGT60F # execute traceroute-options max-ttl 20
FGT60F # execute traceroute-options timeout 2
FGT60F # execute traceroute 10.0.1.100

# Sniffer packet
FGT60F # diagnose sniffer packet port1 'host 10.0.1.50' 4 0 l
FGT60F # diagnose sniffer packet any 'tcp port 443' 6 0 a

# Debug packet flow
FGT60F # diagnose debug flow filter addr 10.0.1.50
FGT60F # diagnose debug flow show function-name enable
FGT60F # diagnose debug flow show function-name enable
FGT60F # diagnose debug flow trace start 100
FGT60F # diagnose debug enable

# Voir les resultats
FGT60F # diagnose debug disable

Démonstration pas à pas : Lancez execute ping puis traceroute vers 8.8.8.8, capturez avec diagnose sniffer packet port1 host 10.0.1.50, filtrez le flow sur addr 10.0.1.50 avec trace start 100 puis diagnose debug enable, lisez, puis coupez avec diagnose debug disable.

Pièges classiques : Sniffer en any sans filtre en heure de pointe ; laisser le debug activé et remplir le disque ; tester depuis la mauvaise source sans ping-options source.

À vous de jouer : Quel ordre minimal pour isoler une coupure ?

Voir la réponse

Ping passerelle puis Internet, traceroute, sniffer ciblé, debug flow filtré, puis lecture des politiques et des routes.

42

Debug flow — Packet flow FortiGate

Pipeline de traitement des paquets, debug flow

30 min

Debug Flow — Packet Flow Pipeline

Le packet flow de FortiGate suit un pipeline précis :

Pourquoi c'est important : Un accept qui ne passe pas vient souvent d une UTM ou d un NAT après la policy. Le debug flow montre recv, policy 1 match, création de session, NAT de 10.0.1.50, inspection UTM puis send ou deny motivé.

L'analogie qui aide : Le packet flow est comme une chaîne de montage : réception, contrôle qualité policy, atelier UTM, peinture NAT, expédition send, avec un tampon à chaque étape.

1. Recv — Réception du paquet sur l'interface
2. Policy — Vérification de la politique de pare-feu
3. UTM — Inspection UTM (AV, IPS, Web Filter...)
4. NAT — Application du NAT
5. Send — Envoi du paquet

# Debug flow — captures le pipeline complet
FGT60F # diagnose debug flow filter addr 10.0.1.50
FGT60F # diagnose debug flow filter port 443
FGT60F # diagnose debug flow show interface-name enable
FGT60F # diagnose debug flow show timestamp enable
FGT60F # diagnose debug flow trace start 10
FGT60F # diagnose debug enable

# Exemple de sortie debug flow
# id=2030 msg="policy 1 match" action=accept
# id=2030 msg="Created session"
# id=2030 msg="NAT" src=10.0.1.50 dst=142.250.80.46
# id=2030 msg="send"
# id=2030 msg="policy 1 accept"

# Diagnostique des erreurs courantes
FGT60F # diagnose debug application fnbamd -1
FGT60F # diagnose debug application sslvpn -1
FGT60F # diagnose debug application ike -1

Démonstration pas à pas : Filtrez diagnose debug flow filter addr 10.0.1.50 et port 443, activez interface-name et timestamp, lancez trace start 10 puis diagnose debug enable, lisez policy 1 match et Created session, puis coupez proprement.

Pièges classiques : Filtrer trop large et noyer le résultat ; interpréter un deny sans regarder l étape UTM ou NAT ; oublier de désactiver le debug.

À vous de jouer : Que prouve la ligne policy 1 match suivie de deny ?

Voir la réponse

Que la bonne règle est trouvée mais qu une étape suivante comme UTM, NAT ou route refuse ou échoue, à inspecter dans les lignes suivantes.

43

Performance et optimisation

Monitoring CPU, mémoire, sessions, NP/CP offload

20 min

Performance et optimisation

Pourquoi c'est important : Un CPU à 90 pour cent avec des sessions qui explosent annonce un déni de service ou une boucle. Avec performance status, session stat et offload NP6, on sait s il faut optimiser ou ajouter du matériel.

L'analogie qui aide : Optimiser, c est lire le tableau de bord : régime CPU, jauge mémoire, compteur de sessions et voyant offload NP6 et CP qui dit si le moteur matériel soulage le processeur.

# Performance systeme
FGT60F # get system performance status
FGT60F # get system performance top

# Historique CPU
FGT60F # diagnose sys cpu-history

# Sessions actives
FGT60F # diagnose sys session info
FGT60F # diagnose sys session list
FGT60F # diagnose sys session stat

# Offload hardware (NP6)
FGT60F # diagnose hardware deviceinfo np6
FGT60F # diagnose npu np6 dme info

# Statistiques CP (Content Processor)
FGT60F # diagnose hardware deviceinfo cp

# Memoire et buffers
FGT60F # diagnose hardware deviceinfo memory
FGT60F # diagnose sys flash list

# Table ARP
FGT60F # get system arp

# Table MAC
FGT60F # get system interface mac

Démonstration pas à pas : Affichez get system performance status et top, lisez diagnose sys cpu-history, comptez avec diagnose sys session stat et list, contrôlez l offload avec diagnose hardware deviceinfo np6 et cp, puis purgez ou optimisez les politiques les plus gourmandes.

Pièges classiques : Tuer des sessions légitimes en masse ; désactiver l offload sans comprendre ; conclure au matériel sans avoir lu les top talkers.

À vous de jouer : Quels trois indicateurs suivre en premier sur un FortiGate lent ?

Voir la réponse

Charge CPU, mémoire et nombre de sessions, croisés avec l état de l offload matériel NP et CP.

44

Cas pratiques de troubleshooting

Scénarios réels, méthodologie, check-list

25 min

Cas pratiques de troubleshooting

Cas 1 : Pas de connectivité Internet

1. Vérifier le statut des interfaces : show system interface
2. Vérifier la route par défaut : get router info routing-table all
3. Ping depuis le FortiGate : execute ping 8.8.8.8
4. Vérifier la règle : show firewall policy
5. Debug flow : diagnose debug flow filter srcip 10.0.1.50

Pourquoi c'est important : Sans méthode, chaque incident repart de zéro. Les trois check-lists types coupure Internet, IPSec muet et SSL-VPN fermé avec show, get, ping et debug ciblé ramènent le MTTR de plusieurs heures à quelques minutes.

L'analogie qui aide : Troubleshooter, c est suivre une recette d urgence : pour Internet on goûte interfaces, routes et debug, pour IPSec on vérifie PSK et IKE, pour SSL-VPN on contrôle port 10443 et certificats.

Cas 2 : VPN IPSec ne se connecte pas

1. Vérifier le PSK/certificat : show vpn ipsec phase1-interface
2. Vérifier les routes : get router info routing-table all
3. Vérifier la connectivité : execute ping vers le peer
4. Debug IKE : diagnose debug application ike 255
5. Vérifier les ports UDP 500/4500

Cas 3 : SSL-VPN ne démarre pas

1. Vérifier le port : get vpn ssl settings | grep port
2. Vérifier les certificats : show vpn certificate
3. Vérifier les utilisateurs : show user local
4. Vérifier les firewall rules (port 10443)
5. Logs : execute log display

Pièges classiques : Sauter les vérifications de base vers le debug avancé ; changer plusieurs paramètres à la fois ; ne pas noter les commandes déjà testées.

À vous de jouer : Quelle première commande commune aux trois cas pratiques ?

Voir la réponse

La vérification de la configuration et de l état avec show ou get, avant tout debug, pour écarter une erreur de paramétrage évidente.

Démonstration pas à pas : Pour Internet, enchaînez show system interface, get router info routing-table all, execute ping 8.8.8.8 et debug flow ; pour IPSec, show vpn ipsec phase1-interface puis debug ike 255 ; pour SSL-VPN, get vpn ssl settings, show user local et logs.

45

Logs et monitoring

Types de logs, filters, syslog, FortiAnalyzer

20 min

Logs et monitoring

Pourquoi c'est important : Sans filtre, execute log display noie l analyste sous des milliers de lignes. En filtrant par type forward et action denied avec limit 50, puis en centralisant vers syslog 10.0.1.200:514, on rend l audit exploitable.

L'analogie qui aide : Les logs sont comme les archives d un tribunal : bien classés par type traffic, event et UTM, filtrés par affaire denied et centralisés chez FortiAnalyzer, ils font foi au lieu de moisir en cave.

# Types de logs
# - Traffic (forward, local, multicast)
# - Event (system, VPN, HA, etc.)
# - UTM (AV, IPS, Web, App)
# - Anomaly

# Configuration des logs
FGT60F # config log setting
FGT60F (setting) # set fuzzy-log disable
FGT60F (setting) # set user-anonymize disable
FGT60F (setting) # set per-packet-logging disable
FGT60F (setting) # end

# Logs sur disque
FGT60F # config log disk setting
FGT60F (setting) # set status enable
FGT60F (setting) # set max-logsize 500
FGT60F (setting) # set diskfull erase
FGT60F (setting) # set roll-over enable
FGT60F (setting) # end

# Filtrer les logs
FGT60F # execute log filter type forward
FGT60F # execute log filter field action denied
FGT60F # execute log filter start 0
FGT60F # execute log filter limit 50
FGT60F # execute log display

# Syslog distant
FGT60F # config log syslogd setting
FGT60F (setting) # set status enable
FGT60F (setting) # set server 10.0.1.200
FGT60F (setting) # set port 514
FGT60F (setting) # set mode udp
FGT60F (setting) # set reliable enable
FGT60F (setting) # end

Démonstration pas à pas : Réglez log setting et log disk setting avec max-logsize 500 et diskfull erase, filtrez avec execute log filter type forward puis field action denied avec limit 50 puis display, puis activez log syslogd setting vers 10.0.1.200:514 en reliable.

Pièges classiques : Logger en all sans rotation et saturer le disque ; anonymiser sans besoin et perdre la traçabilité ; envoyer en UDP sans reliable pour des logs de sécurité.

À vous de jouer : Comment afficher les 50 derniers refus sans être noyé ?

Voir la réponse

Filtrer type forward et action denied, fixer start et limit à 50, puis display, avec export vers syslog ou FortiAnalyzer pour l historique.

Architecture & Optimisation

Module 9 : High Availability (HA)

Objectifs du module

Concepts HA — Actif/Passif vs Actif/Actif

High Availability FortiGate

Configuration HA Actif/Passif

Configuration HA Actif/Passif

Synchronisation et failover

Synchronisation HA

HA — Troubleshooting

Dépannage HA

Problèmes HA courants

Module 10 : FortiManager et FortiAnalyzer

FortiManager — Gestion centralisée

FortiManager — Gestion centralisée des FortiGate

FortiAnalyzer — Logs et rapports

FortiAnalyzer — Analyse et rapports

SOC Fabric et intégration

Security Fabric et intégration

Module 11 : Routage Avancé

Route statique, Policy Routing, SD-WAN

Routage avancé FortiGate

BGP et OSPF

Routage dynamique — OSPF et BGP

Module 12 : Debug et Troubleshooting

Diagnostique réseau — Ping, traceroute, sniffer

Outils de diagnostic réseau

Debug flow — Packet flow FortiGate

Debug Flow — Packet Flow Pipeline

Performance et optimisation

Performance et optimisation

Cas pratiques de troubleshooting

Cas pratiques de troubleshooting

Cas 1 : Pas de connectivité Internet

Cas 2 : VPN IPSec ne se connecte pas

Cas 3 : SSL-VPN ne démarre pas

Logs et monitoring

Logs et monitoring