Etude sphynx¶
Voir aussi
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
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)
Nouvelles problématiques¶
Ipsec, StrongSwan¶
- evolution de Strongswan qui nécessite la refonte des fichiers de configurations.
- Prise en compte du nouveau protocole IKEv2 ?
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)
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
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
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.
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 - 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
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é