GDOI : pourquoi le serveur de clés n’est pas sur votre chemin de données

Le serveur de clés de groupe distribue la politique et les clés aux membres, et les membres protègent eux-mêmes le trafic. Cette phrase ressemble à une formalité jusqu’à ce qu’une conception traite le contrôleur comme un relais pour chaque paquet protégé ; alors la topologie gagne un saut dont elle n’a jamais eu besoin et le chemin du trafic dépend d’un équipement qui ne devait que distribuer de l’état. Dire où se trouve le serveur de clés et dire où circulent les données sont deux schémas différents, et GDOI est bâti autour de cette différence. L’inverser n’est pas une petite erreur de modélisation, car cela change ce que vous surveillez et ce que vous dimensionnez. Les sections ci-dessous suivent la division propre du protocole.

Deux types d’état de sécurité

RFC 6407 définit l’échange de traction du membre pour demander la politique et le matériel de clé, et un échange de poussée qui distribue la politique et les mises à jour de clés aux membres autorisés. Les deux gèrent des associations de sécurité. Aucun n’est le flux de données de l’application, donc un échange réussi prouve seulement que le canal de contrôle a fonctionné. Un membre peut s’enregistrer proprement, détenir des clés valides et néanmoins échouer à protéger ou à transférer le trafic si sa politique de données est erronée. Les deux défaillances ne se ressemblent en rien une fois que l’on sait quel échange porte laquelle.

La norme nomme aussi une association de sécurité de renouvellement qui protège les messages de mise à jour des clés, distincte des associations de sécurité de données qui décrivent comment les membres protègent le trafic.

Suivez les échanges, pas le schéma

Regardez à quoi sert chaque message. L’enregistrement indique au contrôleur quel membre demande et établit l’état ; le renouvellement indique aux membres que la politique ou les clés ont changé ; ensuite le trafic applicatif protégé circule entre les membres via l’association de sécurité de données installée. L’adresse du contrôleur apparaît dans les deux premiers et n’a pas du tout besoin d’apparaître dans le troisième.

C’est pourquoi un schéma d’interfaces dessiné selon l’adjacence physique trompe ici. L’interface du contrôleur est une source de contrôle, pas automatiquement le prochain saut de chaque paquet chiffré.

Trois enregistrements à conserver

Notez l’enregistrement authentifié du membre et la source de contrôle qu’il peut joindre, le chemin qui livre les mises à jour de clés ultérieures, ainsi que les routes et les rattachements qui portent le trafic applicatif protégé. Trois enregistrements, trois responsables, et une défaillance dans l’un d’eux produit un symptôme différent. Un membre qui s’enregistre puis ne reçoit jamais de mise à jour ressemble à un membre enregistré avec une politique obsolète, sauf si vous avez les deux enregistrements.

Gardez-les à côté de la configuration plutôt que dans la mémoire de quelqu’un. Les changements d’adhésion sont assez rares pour que le raisonnement ait toujours disparu au moment où il faut.

Interface, rattachement de service, chemin de traitement

Sur une passerelle basée sur les services, il existe une distinction supplémentaire : l’adresse physique sous-jacente n’est pas la même chose que le rattachement local de service, et l’implémentation de la plateforme décide comment le trafic atteint son chemin de traitement IPsec. Déplacer un service sur une interface physique ou ajouter une traduction sans rapport parce qu’un message d’erreur mentionnait une règle d’interface de service est une supposition déguisée en correctif.

Lisez la documentation propre à la plateforme pour savoir comment le rattachement de service reçoit le trafic. Le mécanisme dépend du fournisseur même lorsque le protocole est standard.

Les messages de protocole normalisés n’établissent pas non plus la compatibilité entre fournisseurs. Comparez les fonctions requises, les attributs de politique et d’association, la méthode d’authentification, ainsi que la plateforme et la version exactes avant de supposer que deux implémentations interopéreront.

La disponibilité du contrôle et le transfert des données sont des vérifications séparées

Planifiez l’accessibilité du contrôleur pour l’exploitation courante, pour les changements d’adhésion et pour les mises à jour de clés. Un échange applicatif qui réussit sur un état déjà installé ne prouve pas que le prochain enregistrement ou renouvellement atteindra le membre, et l’écart apparaît généralement des heures plus tard sous la forme d’un tunnel qui cesse d’accepter de nouveaux membres. Testez un enregistrement neuf, pas seulement une session qui fonctionne.

Testez ensuite le transfert séparément, le contrôleur hors du tableau. Deux vérifications, deux résultats, et un débat bien plus court sur la moitié qui est cassée.