Etude sphynx » Historique » Version 7
Version 6 (Gwenael Remond, 15/01/2010 11:31) → Version 7/9 (samuel morin, 15/01/2010 14:10)
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
* 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), 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 ?
* redondance des routeurs route sur les amons (agrégation de lien) amon (multi-routage)
* road warrior ? warrior, tagger des adresses ip pour savoir si elles sont autorisées
(des ips sont attribués dynamiquement)
* autres fonctionnalités StrongSwan StrongSwann
* 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. ipsec est intégré maintenant directement dans le noyau
* Prise en compte du nouveau protocole IKEv2 ? 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é à Internet _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 au RVP au travers de plusieurs routeurs
La configuration ipsec est la même pour les deux routeurs, hormis les adresses ip externes,
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@
* template de tunnel
* modifications groupées grouppé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 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'enregistrer 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
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@)
* 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
* 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), 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 ?
* redondance des routeurs route sur les amons (agrégation de lien) amon (multi-routage)
* road warrior ? warrior, tagger des adresses ip pour savoir si elles sont autorisées
(des ips sont attribués dynamiquement)
* autres fonctionnalités StrongSwan StrongSwann
* 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. ipsec est intégré maintenant directement dans le noyau
* Prise en compte du nouveau protocole IKEv2 ? 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é à Internet _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 au RVP au travers de plusieurs routeurs
La configuration ipsec est la même pour les deux routeurs, hormis les adresses ip externes,
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@
* template de tunnel
* modifications groupées grouppé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 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'enregistrer 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
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é