Etude sphynx » Historique » Version 5
Version 4 (Gwenael Remond, 15/01/2010 11:17) → Version 5/9 (Gwenael Remond, 15/01/2010 11:27)
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 (deux amon se voient entre eux)
* 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
* le multi-sphynx (un amon avec plusieurs sphynx)
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 très attendues
* 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_.
h3. Le tunnel "dynamique"
* ajout groupé de tunnels, modifications groupées
* template de tunnel
* une ip a changée sur l'amon, le sphyx doit le savoir et mettre à jour le tunnel
en conséquence
* faut-il, notamment dans le cadre du multi-sphynx,
qu'un client avec ipsec puisse permettre d'échanger des données deux grands réseau (ex : ADRIATIC)
* un tunnel réellement _dynamique_ ? Capable de s'enregister et de créer un tunnel automatiquement ?
cela nécessiterait que les amon soient enregistrés et que le sphynx puisse communiquer avec eux
et surtout leur faire confiance
h2. Conclusion momentanée
Maintenir une cohérence du réseau global (est-ce que ça sera au niveau du sphynx ?
Est-ce que le sphynx a toutes les informations _exactes_, valeurs d'ips, etc...)
Il est clair qu'il doit y avoir un endroit ou toutes les informations doivent
être connues (serait-ce au niveau du sphynx?)
de manière à pouvoir *vraiment* vérifier l'intégrité du réseau
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 (deux amon se voient entre eux)
* 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
* le multi-sphynx (un amon avec plusieurs sphynx)
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 très attendues
* 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_.
h3. Le tunnel "dynamique"
* ajout groupé de tunnels, modifications groupées
* template de tunnel
* une ip a changée sur l'amon, le sphyx doit le savoir et mettre à jour le tunnel
en conséquence
* faut-il, notamment dans le cadre du multi-sphynx,
qu'un client avec ipsec puisse permettre d'échanger des données deux grands réseau (ex : ADRIATIC)
* un tunnel réellement _dynamique_ ? Capable de s'enregister et de créer un tunnel automatiquement ?
cela nécessiterait que les amon soient enregistrés et que le sphynx puisse communiquer avec eux
et surtout leur faire confiance
h2. Conclusion momentanée
Maintenir une cohérence du réseau global (est-ce que ça sera au niveau du sphynx ?
Est-ce que le sphynx a toutes les informations _exactes_, valeurs d'ips, etc...)
Il est clair qu'il doit y avoir un endroit ou toutes les informations doivent
être connues (serait-ce au niveau du sphynx?)
de manière à pouvoir *vraiment* vérifier l'intégrité du réseau