FortiGate : VPN IPsec, négociation, routes et redondance

Un VPN IPsec protège des échanges entre pairs, mais sa présence ne prouve pas qu’une application distante est joignable. Préparez les réseaux locaux et distants, les passerelles et les services à autoriser. Le tunnel, les routes et les politiques doivent donner un chemin cohérent à ce trafic.

Dans FortiOS, les réglages Phase 1 et Phase 2 organisent les paramètres de négociation. L’assistant VPN fournit des scénarios, notamment site-à-site et hub-and-spoke. Comprenez le résultat de l’assistant et ses dépendances au lieu de traiter ses objets comme une configuration opaque.

Phase 1 décrit notamment les pairs, l’authentification et les paramètres utilisés par IKE. Phase 2 associe la protection IPsec et les sélecteurs de trafic à cette configuration. Les propositions doivent être compatibles entre les deux extrémités pour établir la protection attendue.

Ces noms de configuration ne décrivent pas exactement les mêmes messages pour toutes les versions d’IKE. Le repère de révision reste de distinguer la relation avec le pair et la protection du trafic. Comparez les choix réellement configurés et les événements de négociation avant de modifier plusieurs propositions.

Les sélecteurs définissent les adresses locales et distantes concernées par la protection. Un tunnel peut paraître établi alors qu’un flux ne correspond pas aux sélecteurs attendus. Comparez les réseaux des deux côtés et les adresses réellement présentées après les éventuelles traductions.

Dans un scénario route-based, la route vers le réseau distant et les politiques entre interfaces participent à l’accès. La direction d’initiation du besoin compte également : autoriser une application d’un site à l’autre n’accorde pas tous les nouveaux flux dans l’autre sens.

Découpez la recette : joindre le pair, établir la négociation, vérifier la protection du trafic puis atteindre le service distant. Les journaux et les compteurs sont à rapprocher d’une communication précise. Un paquet sortant sans réponse appelle aussi une vérification des routes et règles du site distant.

Pour une topologie redondante ou maillée, dessinez les chemins principaux et alternatifs ainsi que les conditions de sélection. Étudiez ensuite l’impact d’un défaut sur les nouvelles communications et sur les sessions existantes. La redondance du tunnel ne remplace pas la validation du routage et de l’application.

Dessiner deux sites et leurs réseaux protégés, puis ajouter un chemin redondant. Préparer la vérification du tunnel et du trafic utile ; expliquer pourquoi un tunnel établi ne suffit pas à prouver l’accès à une application.

Pour terminer, formulez votre résultat attendu, les observations relevées et une hypothèse alternative si le résultat diffère. Conservez la version du produit et le contexte de test avec vos notes de laboratoire.