SphynxGenerateurDeConf » Historique » Version 13
Version 12 (Emmanuel GARETTE, 12/02/2010 09:55) → Version 13/14 (Gwenael Remond, 12/02/2010 10:02)
h1. SphynxGenerateurDeConf
h2. 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 IP nodes et 2 credentials
_connect_
Définition : lien sécurisé entre 2 nodes
Lié à :
1-n credential(s)
1-n extremity
_extremity_
Définition : ip publique ou privée d'un node.
h2. 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_.
h2. 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)
h3. 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)
h3. cohérence des configurations
Sur une machine cible, la seule vérification de cohérence est de type "ACID":http://fr.wikipedia.org/wiki/Transaction_informatique
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).
h2. 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 IP nodes et 2 credentials
_connect_
Définition : lien sécurisé entre 2 nodes
Lié à :
1-n credential(s)
1-n extremity
_extremity_
Définition : ip publique ou privée d'un node.
h2. 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_.
h2. 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)
h3. 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)
h3. cohérence des configurations
Sur une machine cible, la seule vérification de cohérence est de type "ACID":http://fr.wikipedia.org/wiki/Transaction_informatique
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).