OpenKeel : la solution Cloud souveraine, française à portée européenne du groupe inherent Découvrir inherent
Composants · Réseau
VPN IPsec site à site : IKE, policies IPsec, connexions.
OpenKeel implementation in Go of OpenStack neutron-vpnaas on the OVN path, generated from the reverse-specification of branch stable/2026.2 by the generate-go-from-spec skill. neutron-vpnaas-api serves the VPN API (/v2.0/vpn and the agent scheduler) and replaces the ovn-vpnaas service plugin and its driver: same routes, status codes, error bodies and policies, same tables. neutron-vpnaas-agent replaces neutron-ovn-vpn-agent: it runs strongSwan, the original's daemon, in one qvpn-<router> namespace per router. It runs beside openkeel-neutron, on its database and its OVN; clients reach it through a proxy in openkeel-neutron: see docs/NEUTRON-INTEGRATION.md. What is reproduced and what differs is in docs/CONFORMANCE.md; the security checklist is in docs/SECURITY.md.
github.com/openkeel/openkeel-neutron-vpnaasneutron-vpnaas-api (API on port 9696, agent API on 9697, health and metrics on 9090), neutron-vpnaas-agent (health on 9091; needs Linux, root and strongSwan: Dockerfile.agent)Extrait de openkeel-neutron-vpnaas/README.md (en anglais).
35 opérations de l'API REST d'origine (routes et actions de corps), et leur état dans OpenKeel.
Les échanges enregistrés du profil OVN sont rejoués contre le service Go, le rendu de configuration est comparé aux templates d'origine, et de vrais tunnels IPsec sont montés de bout en bout.
Les échanges VPNaaS enregistrés servis par ce service donnent les mêmes réponses ; ceux servis par Neutron sont vérifiés sur la vraie pile.
make e2e-strict, sur go-mysql-server et sur MariaDB 11.4.
Dernier résultat 84 rejoués, 84 réussis (2026-10-31) ; 25 des 108 échanges enregistrés relèvent de Neutron ou ne s'appliquent plus.
Source : openkeel-neutron-vpnaas/docs/CONFORMANCE.md
La configuration strongSwan correspond aux templates jinja2 d'origine pour chaque groupe et algorithme de l'API.
tools/gen_render_vectors.py, 50 vecteurs issus des templates d'origine.
Dernier résultat 50 / 50, aux lignes vides près (2026-10-31).
Source : openkeel-neutron-vpnaas/docs/CONFORMANCE.md
IKEv1 et IKEv2 avec AES-GCM, ping à travers ESP, admin down puis up, démon tué puis redémarré, suppression.
make tunnel-test : strongSwan 5.9.13 des deux côtés, vrai XFRM du noyau.
Dernier résultat Réussi, 2 exécutions sur le code final (2026-10-31).
Source : openkeel-neutron-vpnaas/docs/CONFORMANCE.md
Via le proxy de Neutron, un port de tenant pingue un sous-réseau situé derrière un pair strongSwan, par le routeur OVN et le tunnel.
make stack-test : openkeel-neutron, ovsdb-server, ovn-northd, ovn-controller, OVS, MariaDB, l'image de l'agent.
Dernier résultat Réussi, 2 exécutions sur le code final (2026-10-31).
Source : openkeel-neutron-vpnaas/docs/CONFORMANCE.md
Les opérations VPN restent cohérentes lorsque les requêtes arrivent par trois nœuds Galera.
make galera-test sur un cluster à 3 nœuds.
Dernier résultat 3 tests réussis, 5 exécutions sur 5 (2026-10-31).
Source : openkeel-neutron-vpnaas/docs/CONFORMANCE.md
Les tests d'API et de scénario VPNaaS amont.
Nécessite un cloud déployé.
Dernier résultat Non exécuté.
Source : openkeel-neutron-vpnaas/docs/CONFORMANCE.md
VPNaaS conserve son API avec un seul driver strongSwan sur OVN, sans Libreswan, l'ancien chemin L3, rootwrap ni RabbitMQ.
Ils ne sont pas des cibles de la réécriture ; un seul driver est livré : strongSwan dans un namespace par routeur sur le chassis OVN.
Les connexions IPsec site à site se créent via la même API ; les déploiements qui dépendaient d'un comportement propre à Libreswan ne le retrouvent pas.
Source : openkeel-neutron-vpnaas/config/dropped-options.md
L'agent interroge une API d'agents avec ETag toutes les 5 secondes au lieu de topics RPC ; aucun service OpenKeel ne consommait les notifications vpn_agent.
Aucune mise à jour ne peut être perdue, au prix d'un délai allant jusqu'à 5 s. Les notifications deviennent des lignes de log.
Source : openkeel-neutron-vpnaas/docs/CONFORMANCE.md
Repris par Kubernetes DaemonSet
L'agent pilote OVS lui-même et tourne dans son conteneur avec les privilèges dont il a besoin.
Mêmes namespaces, ports et commandes strongSwan sur le nœud ; aucun filtre rootwrap à maintenir.
Source : openkeel-neutron-vpnaas/config/dropped-options.md
Seul ce qui a été écarté par choix de conception figure ici ; le travail pas encore fait se trouve dans les Known gaps du docs/CONFORMANCE.md du module. Tous les modules
Vue « service » générée par la skill diagramme depuis le modèle d'OpenKeel.
Plein écran| De | Vers | Protocole | Quoi |
|---|---|---|---|
| Neutron server | Neutron VPNaaS | API REST | proxy /v2.0/vpn/*, vpn-agents, same token |
| Neutron VPNaaS | Neutron server | API REST | core and L3 calls: gateway ports, routes |
| Neutron VPNaaS | OVN Southbound DB | OVSDB | lists VPN agents (Chassis_Private) |
| VPNaaS agent | Neutron VPNaaS | API REST | agent API :9697: services (ETag poll), status |
| VPNaaS agent | OVN Southbound DB | OVSDB | registers ovn-vpnagent, acks nb_cfg |
Branche stable-2026.2 · 8 fichiers
Lire la reverse-specRéseaux, sous-réseaux, ports, routeurs et groupes de sécurité écrits dans la base OVN Northbound ; IPv4 et IPv6.
API Octavia v2 servie par neutron-api ; load balancers OVN, actifs par défaut.
Firewall groups, policies et rules (FWaaS v2).
Annonce en BGP les IP de VMs et les IP flottantes joignables par le nœud.