SphynxGenerateurDeConf¶

Modélisation¶

tunnel

mise en relation de deux extrémités (sphynx-amon, amon-amon, amon-autre...)
  de type 1-1

réseau sécurisé

un réseau sécurisé est composé de n tunnels

Entre les deux extrémités d'un tunnel, il y a forcément un maître et un esclave
car la configuration générée doit dépendre d'une responsabilité donnée d'un côté (et pas des deux).

La génération des configurations¶

configuration

base de données, templatisée ou pas, à mettre sur une machine EOLE ou non (fichier cible identique à une base de données strongswan)

Les configurations doivent pouvoir être aggrégées (puisque sur un Amon par exemple il peut y avoir plusieurs tunnels)
Une configuration finale sur une machine cible est constituée d'une aggrégation qui provient de diverses extrémités.

Les configurations doivent pouvoir être templatisées de manière à être "instanciables", par exemple sur un EOLE, elles doivent pouvoir être générées directement sous un format compatible strongswan. (comme une configuration Era par exemple)

La sortie doit ressembler à une base tagguée de manière à connaître à tout moment le responsable du tunnel (le maître).
Un tunnel est de la responsabilité d'un seul maître (d'une seule extrémité).
Le maître connaît les esclaves mais les esclaves ne savent pas d'où vient le maître.

outils de génération des configurations¶

L'outil de génération doit pouvoir être lancé en local (pas d'appli web), en ligne de commande ou bien une interface graphique lancée uniquement en framebuffer.
L'éditeur doit pouvoir manipuler des séries de paramètres-valeurs dynamiquement (comme dans ltsconfeditor par exemple)

cohérence des configurations¶

Sur une machine cible, la seule vérification de cohérence est de type ACID
et pas de type de cohérence d'intégrité fonctionnelle. En clair, cela veut dire que la seule vérification à faire in fine c'est que les tunnels ne soient pas identiques.

Donc le tunnel est indexé sur l'extrémité

L'ensemble des tunnels est une diversité disjointe.