SphynxGenerateurDeConf » Historique » Version 7
Gwenael Remond, 04/02/2010 13:37
| 1 | 1 | Gwenael Remond | h1. SphynxGenerateurDeConf |
|---|---|---|---|
| 2 | 1 | Gwenael Remond | |
| 3 | 1 | Gwenael Remond | h2. Modélisation |
| 4 | 1 | Gwenael Remond | |
| 5 | 1 | Gwenael Remond | _tunnel_ |
| 6 | 1 | Gwenael Remond | |
| 7 | 1 | Gwenael Remond | mise en relation de deux _extrémités_ (sphynx-amon, amon-amon, amon-autre...) |
| 8 | 1 | Gwenael Remond | de type 1-1 |
| 9 | 1 | Gwenael Remond | |
| 10 | 1 | Gwenael Remond | _réseau sécurisé_ |
| 11 | 1 | Gwenael Remond | |
| 12 | 1 | Gwenael Remond | |
| 13 | 1 | Gwenael Remond | un _réseau sécurisé_ est composé de _n_ tunnels |
| 14 | 1 | Gwenael Remond | |
| 15 | 6 | Gwenael Remond | _maître_ |
| 16 | 1 | Gwenael Remond | |
| 17 | 6 | Gwenael Remond | extrémité responsable du tunnel |
| 18 | 6 | Gwenael Remond | |
| 19 | 6 | Gwenael Remond | _esclave_ |
| 20 | 6 | Gwenael Remond | |
| 21 | 6 | Gwenael Remond | extrémité qui n'est pas responsable du tunnel |
| 22 | 6 | Gwenael Remond | |
| 23 | 1 | Gwenael Remond | Entre les deux extrémités d'un tunnel, il y a forcément un _maître_ et un _esclave_ |
| 24 | 6 | Gwenael Remond | car la configuration générée doit dépendre d'une seule responsabilité donnée d'un côté (et pas des deux). |
| 25 | 1 | Gwenael Remond | |
| 26 | 6 | Gwenael Remond | La sortie doit ressembler à une base tagguée de manière à connaître à tout moment le responsable du tunnel (le _maître_). |
| 27 | 6 | Gwenael Remond | Un tunnel est de la responsabilité d'un seul maître (d'une seule extrémité). |
| 28 | 6 | Gwenael Remond | Le maître connaît les esclaves mais les esclaves ne savent pas d'où vient le maître. |
| 29 | 1 | Gwenael Remond | |
| 30 | 6 | Gwenael Remond | *Donc le tunnel est indexé sur l'extrémité* maître, et L'ensemble des tunnels est une _diversité disjointe_. |
| 31 | 6 | Gwenael Remond | |
| 32 | 5 | Gwenael Remond | h2. La génération des _configurations_ |
| 33 | 5 | Gwenael Remond | |
| 34 | 1 | Gwenael Remond | _configuration_ |
| 35 | 3 | Gwenael Remond | |
| 36 | 7 | Gwenael Remond | base de données, fichier, etc, templatisée ou pas, |
| 37 | 7 | Gwenael Remond | à mettre sur une machine EOLE ou non |
| 38 | 7 | Gwenael Remond | (fichier cible identique à une base de données strongswan) |
| 39 | 1 | Gwenael Remond | |
| 40 | 1 | Gwenael Remond | Les configurations doivent pouvoir être **aggrégées** (puisque sur un Amon par exemple il peut y avoir plusieurs tunnels) |
| 41 | 1 | Gwenael Remond | Une configuration finale sur une machine cible est constituée d'une aggrégation qui provient de diverses extrémités. |
| 42 | 3 | Gwenael Remond | |
| 43 | 6 | Gwenael Remond | 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) |
| 44 | 1 | Gwenael Remond | |
| 45 | 1 | Gwenael Remond | h3. outils de génération des configurations |
| 46 | 5 | Gwenael Remond | |
| 47 | 6 | Gwenael Remond | 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. |
| 48 | 3 | Gwenael Remond | L'éditeur doit pouvoir manipuler des séries de paramètres-valeurs dynamiquement (comme dans ltsconfeditor par exemple) |
| 49 | 3 | Gwenael Remond | |
| 50 | 3 | Gwenael Remond | h3. cohérence des configurations |
| 51 | 3 | Gwenael Remond | |
| 52 | 4 | Gwenael Remond | Sur une machine cible, la seule vérification de cohérence est de type "ACID":http://fr.wikipedia.org/wiki/Transaction_informatique |
| 53 | 6 | Gwenael Remond | et surtout aucune de type de cohérence d'intégrité fonctionnelle, ce qui est infaisable. |
| 54 | 6 | Gwenael Remond | 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). |