SphynxGenerateurDeConf¶

Implémentation¶

Remarque : les notations utilisées sont génériques et font référence à la théorie des graphes

http://en.wikipedia.org/wiki/Glossary_of_graph_theory

node

Définition : concentrateur VPN.

Exemple : Etablissement 1, collectivité, Sphynx
lié à : connect

credential

Définition : certificat permettant d'établir une connexion ipsec.

extremity

Définition : adresse IP publique et éventuellement privée du node.

vertex

Définition : sous-réseau ou machine

Exemple : Scribe de l'établissement 1, pédago de l'établissement 2

Lié à : un node et un template

template

Définition : nom d'un sous-réseau ou machine générique existant dans 1-n node(s).

Exemple : admin, pédago, Scribe

edge

Définition : tunnel VPN entre 2 vertex passant dans un connect

connect

Définition : lien sécurisé orienté avec 2 extremities et 2 credentials

Lié à :
1-n credential(s)
1-n extremity

extremity

Définition : ip publique ou privée d'un node.

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

maître

extrémité responsable du tunnel

esclave

extrémité qui n'est pas responsable du tunnel

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 seule responsabilité donnée d'un côté (et pas des deux).

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.

Donc le tunnel est indexé sur l'extrémité maître, et L'ensemble des tunnels est une diversité disjointe.

La génération des configurations¶

configuration

base de données, fichier, etc, 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 pour le lance.firewall non encore instancié dans Era par exemple)

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 mais 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 surtout aucune de type de cohérence d'intégrité fonctionnelle, ce qui est infaisable.
En clair, cela veut dire que la seule vérification à faire in fine c'est que les tunnels ne soient pas identiques (plusieurs tunnels sur une même machine qui aient la même IP).