ipsec.conf ou swanctl.conf ? Choisissez un frontend strongSwan

Un profil IKEv1 fonctionnel tiré d’un ancien guide atterrit sur Ubuntu 24.04, et la première tentative échoue parce que le démon n’a jamais lu le fichier. La réaction habituelle est de modifier à nouveau le profil. La vraie question est de savoir quel frontend strongSwan est installé et lequel utilise le service en cours d’exécution. Tant que cette question n’est pas résolue, chaque modification vise un chargeur qui n’existe peut-être pas.

Deux fichiers, deux chargeurs, un démon

L’ancienne disposition starter lit ipsec.conf et remet les connexions à charon via son intégration de gestion héritée. Son point d’entrée opérationnel est la commande ipsec.

La disposition swanctl charge les définitions via VICI, lit swanctl.conf et est pilotée par la commande swanctl. Le démon charon natif de systemd s’intègre à cette approche.

Les deux peuvent être installés sur la même machine, et c’est là que la confusion commence. Un fichier sous /etc prouve seulement que quelqu’un l’a écrit, pas que le processus en cours l’a chargé. Installer toutes les alternatives pour voir laquelle fonctionne crée un hôte avec deux chemins de gestion et sans propriétaire clair. Choisissez une disposition et supprimez ou désactivez l’autre.

Lisez les paquets et les unités installés

Commencez en lecture seule. Les noms de paquets sur Ubuntu 24.04 sont distincts : strongswan-starter, strongswan-swanctl et charon-systemd. Un paquet manquant est une information utile, pas une consigne de l’installer.

Inventoriez les paquets et les unités en une seule passe :

dpkg-query -W strongswan-starter strongswan-swanctl charon-systemd
systemctl list-unit-files '*strongswan*'

Inspectez ensuite l’unité active et sa commande de démarrage. Le nom de l’unité indique quel démon possède la configuration, et la ligne de commande confirme quels fichiers il devait lire. Une unité activée mais inactive raconte une autre histoire que celle qui tourne maintenant.

Si l’unité active est strongswan-starter, le fichier qui compte est ipsec.conf. S’il s’agit de charon-systemd avec swanctl, ipsec.conf n’est que décoration.

Utilisez le chemin de contrôle correspondant

Chaque frontend a sa propre vue des connexions et des associations. swanctl --list-conns montre les définitions chargées et swanctl --list-sas les associations actives. L’ancien chemin utilise ipsec statusall.

Les mélanger produit des erreurs trompeuses. Un socket VICI manquant ou une requête de contrôle refusée est un problème de chemin de gestion, pas la preuve que le pair a rejeté l’authentification.

Lisez la vue qui appartient au démon en cours d’exécution, puis interprétez le résultat. Si la connexion est absente de cette vue, le problème vient du chargement, pas de la négociation.

Le format n’est pas la version IKE

Un ancien profil sélectionne IKEv1 avec keyexchange=ikev1. Une connexion swanctl utilise un réglage de version, où 1 sélectionne IKEv1. Ce sont deux vocabulaires pour la même idée, pas une conversion.

Les adresses du pair, les identités locale et distante, les sources d’identifiants, les propositions et les sélecteurs enfant doivent être mappés volontairement. Coller un bloc left/right dans la syntaxe swanctl ne fait rien de tout cela.

Changer seulement la version du protocole est la demi-migration la plus courante. Elle produit un fichier qui se charge puis échoue à l’authentification pour des raisons sans rapport avec la version. IKEv1 lui-même est déprécié par le RFC 9395, donc un pair existant qui l’exige encore mérite une contrainte de compatibilité documentée et un chemin de migration, pas une nouvelle valeur par défaut.

Vérifiez le chargeur avant de toucher au profil

Exécutez d’abord le contrôle du chargeur, puis chargez la connexion voulue, puis évaluez la négociation, puis le chemin du trafic protégé. Chaque étape a une signature d’échec différente.

Les deux chemins de contrôle répondent directement à la question du chargement :

swanctl --list-conns
ipsec statusall

Une seule de ces commandes appartient à votre hôte. Exécuter les deux et comparer la sortie est un moyen de découvrir laquelle vous ment, pas une méthode de diagnostic.

Traitez la propriété des paquets, le chargement de la configuration et la compatibilité du protocole comme trois questions distinctes. Un fichier valide pour un frontend sera sinon modifié encore et encore alors qu’un autre démon est celui qui tourne.