Etude sphynx » Historique » Version 8
Version 7 (samuel morin, 15/01/2010 14:10) → Version 8/9 (samuel morin, 15/01/2010 14:14)
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@)
* il y a plusieurs tunnels (multitunnel)
* multitunnel, gestion de tunnel (ajout, suppression...)
* gestion des certificats
* ipsec est intégré maintenant directement dans le noyau
* plusieurs technologies peuvent être utilisées, le choix se porte sur StrongSwan
d'une manière générale, on peut :
* visualiser les différents paramètres (dans la base), 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 ?
* redondance des routeurs sur les amons (agrégation de lien)
* road warrior ?
* autres fonctionnalités StrongSwan
* le multi-sphynx (un amon avec plusieurs sphynx)
h2. Nouvelles problématiques
h3. Ipsec, StrongSwan
* evolution de Strongswan qui nécessite la refonte des fichiers de configurations.
* Prise en compte du nouveau protocole IKEv2 ?
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é à Internet et au RVP au travers de plusieurs routeurs
La configuration ipsec est la même pour les deux routeurs, hormis les adresses ip externes,
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@
* template de tunnel
* modifications groupées (pouvoir modifier un type de tunnel donné dans
plusieurs établissements en même temps)
* ajouts et modifications groupées dans plusieurs établissements
Tous ces paramètres provenant de différentes sources doivent être changés
_sans que la structure du réseau ne soit 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'enregistrer 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
Il est impossible de travailler uniquement depuis des bases StrongSwan car il y a un niveau d'abstraction
nécessaire ("tags" sur les tunnels, données externes dynamiques provenant de créole et autres,
générations d'autres fichiers de route, etc), il faut donc :
* des générateurs (sur l'amon, sur le sphynx...)
* des vérifications de la cohérence et de l'intégrité du réseau global ("compilateur de réseau")
* des outils d'édition et de modification *indépendants* de la génération et de la vérification de l'intégrité
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@)
* il y a plusieurs tunnels (multitunnel)
* multitunnel, gestion de tunnel (ajout, suppression...)
* gestion des certificats
* ipsec est intégré maintenant directement dans le noyau
* plusieurs technologies peuvent être utilisées, le choix se porte sur StrongSwan
d'une manière générale, on peut :
* visualiser les différents paramètres (dans la base), 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 ?
* redondance des routeurs sur les amons (agrégation de lien)
* road warrior ?
* autres fonctionnalités StrongSwan
* le multi-sphynx (un amon avec plusieurs sphynx)
h2. Nouvelles problématiques
h3. Ipsec, StrongSwan
* evolution de Strongswan qui nécessite la refonte des fichiers de configurations.
* Prise en compte du nouveau protocole IKEv2 ?
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é à Internet et au RVP au travers de plusieurs routeurs
La configuration ipsec est la même pour les deux routeurs, hormis les adresses ip externes,
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@
* template de tunnel
* modifications groupées (pouvoir modifier un type de tunnel donné dans
plusieurs établissements en même temps)
* ajouts et modifications groupées dans plusieurs établissements
Tous ces paramètres provenant de différentes sources doivent être changés
_sans que la structure du réseau ne soit 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'enregistrer 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
Il est impossible de travailler uniquement depuis des bases StrongSwan car il y a un niveau d'abstraction
nécessaire ("tags" sur les tunnels, données externes dynamiques provenant de créole et autres,
générations d'autres fichiers de route, etc), il faut donc :
* des générateurs (sur l'amon, sur le sphynx...)
* des vérifications de la cohérence et de l'intégrité du réseau global ("compilateur de réseau")
* des outils d'édition et de modification *indépendants* de la génération et de la vérification de l'intégrité