Etude sphynx » Historique » Version 4
Version 3 (Gwenael Remond, 15/01/2010 11:09) → Version 4/9 (Gwenael Remond, 15/01/2010 11:17)
h1. Etude sphynx
h2. Bilan de l'existant
* les fichiers de configuration sont générés directement sur le sphynx
* les configuration sont poussées de diverses manières, le sphynx et l'amon ne communiquent pas
* il y a plusieurs configurations indépendantes qui sont générées à partir d'une base xml (@sphynx.xml@)
* un amon a un et un seul sphynx, un sphynx peut avoir plusieurs amon
* il y a plusieurs tunnels (multitunnel)
* multitunnel, gestion de tunnel (ajout, suppression...)
* gestion des certificats
d'une manière générale, on peut :
* visualiser les confs, les éditer et les modifier (seulement depuis le sphynx)
* pousser les confs
h2. Nouvelles fonctionnalités éventuelles (en vrac)
* tunnel inter-amon
* haute dispo sphynx
* haute dispo amon ?
* route sur les amon (multi-routage)
* road warrior, tagger des adresses ip pour savoir si elles sont autorisées
(des ips sont attribués dynamiquement)
* autres fonctionnalités StrongSwann
h2. Nouvelles problématiques
h3. Ipsec, StrongSwan
* ipsec est intégré maintenant directement dans le noyau
* plusieurs technologies peuvent être utilisées, à priori le choix se porte sur StrongSwan
h3. La haute disponibilité
fonctionnalités nécessaires :
* pouvoir échanger des configurations entre deux sphynx, les cloner
* pouvoir _pousser_ des modifications d'une configuration à partir d'une autre
(un _diff_), et les _merger_ (fusionner)
h3. Le multi routage
Un amon est relié à _deux_ routeurs, via internet
ils sont reliés à un routeur derrière lequel il y a un (ou plusieurs) sphynx
C'est la même configuration d'un côté du routeur et de l'autre, cela implique de pouvoir "cloner" une configuration
h2. Autres fonctionnalités éventuelles à intégrer
* ne monter des tunnels _que_ pour un protocole (http)
* pouvoir bloquer des protocoles à l'intérieur d'un tunnel, l'OTP, etc..
* pouvoir ajouter des options particulière à un tunnel
h2. Possibilités de l'outil
* faire des templates d'établissement
* gérer plusieurs bases de données StrongSwan
* gérer des confs éventuellement (fichiers de route ou autre)
* gérer des fichiers de dictionnaire créole (ip templatisées, ip variables)
* templates de tunnel, dicos créole, générateur sur un amon
* paramètres globaux (ex: _StrictPolicy_) et paramètres locaux (ips, etc)
* paramètres dépendants de dictionnaires créole ou de variables automatiques
* paramètres modifiables dans le @gen_config@
Tous ces paramètres provenant de différentes sources doivent être changés
_sans que la structure du réseau ne soient affectée_.
h2. Bilan de l'existant
* les fichiers de configuration sont générés directement sur le sphynx
* les configuration sont poussées de diverses manières, le sphynx et l'amon ne communiquent pas
* il y a plusieurs configurations indépendantes qui sont générées à partir d'une base xml (@sphynx.xml@)
* un amon a un et un seul sphynx, un sphynx peut avoir plusieurs amon
* il y a plusieurs tunnels (multitunnel)
* multitunnel, gestion de tunnel (ajout, suppression...)
* gestion des certificats
d'une manière générale, on peut :
* visualiser les confs, les éditer et les modifier (seulement depuis le sphynx)
* pousser les confs
h2. Nouvelles fonctionnalités éventuelles (en vrac)
* tunnel inter-amon
* haute dispo sphynx
* haute dispo amon ?
* route sur les amon (multi-routage)
* road warrior, tagger des adresses ip pour savoir si elles sont autorisées
(des ips sont attribués dynamiquement)
* autres fonctionnalités StrongSwann
h2. Nouvelles problématiques
h3. Ipsec, StrongSwan
* ipsec est intégré maintenant directement dans le noyau
* plusieurs technologies peuvent être utilisées, à priori le choix se porte sur StrongSwan
h3. La haute disponibilité
fonctionnalités nécessaires :
* pouvoir échanger des configurations entre deux sphynx, les cloner
* pouvoir _pousser_ des modifications d'une configuration à partir d'une autre
(un _diff_), et les _merger_ (fusionner)
h3. Le multi routage
Un amon est relié à _deux_ routeurs, via internet
ils sont reliés à un routeur derrière lequel il y a un (ou plusieurs) sphynx
C'est la même configuration d'un côté du routeur et de l'autre, cela implique de pouvoir "cloner" une configuration
h2. Autres fonctionnalités éventuelles à intégrer
* ne monter des tunnels _que_ pour un protocole (http)
* pouvoir bloquer des protocoles à l'intérieur d'un tunnel, l'OTP, etc..
* pouvoir ajouter des options particulière à un tunnel
h2. Possibilités de l'outil
* faire des templates d'établissement
* gérer plusieurs bases de données StrongSwan
* gérer des confs éventuellement (fichiers de route ou autre)
* gérer des fichiers de dictionnaire créole (ip templatisées, ip variables)
* templates de tunnel, dicos créole, générateur sur un amon
* paramètres globaux (ex: _StrictPolicy_) et paramètres locaux (ips, etc)
* paramètres dépendants de dictionnaires créole ou de variables automatiques
* paramètres modifiables dans le @gen_config@
Tous ces paramètres provenant de différentes sources doivent être changés
_sans que la structure du réseau ne soient affectée_.