Un profil strongSwan chargé n’est pas un tunnel actif

Lister une connexion dans la configuration strongSwan prouve seulement qu’une définition a été chargée. Cela ne signifie pas que le pair a été contacté, qu’une SA IKE existe ou qu’un trafic est protégé. Le démon traite les définitions et les associations actives comme des objets distincts, et l’écart entre les deux est un choix de conception délibéré. Savoir quel objet vous inspectez transforme une panne vague en une commande suivante précise.

Charger n’est pas connecter

Une connexion chargée est un énoncé de ce qui pourra être négocié plus tard : adresses des pairs, identifiants, propositions et sélecteurs de trafic. Rien dans cet énoncé n’oblige le démon à avoir appelé qui que ce soit. Une passerelle peut attendre l’autre côté, initier au démarrage ou attendre qu’un trafic correspondant la réveille. Les trois sont valables, et les trois sont identiques dans le fichier de configuration tant que vous n’avez pas lu la politique de démarrage.

Les exploitants se mettent en difficulté en lisant la liste des définitions comme une liste d’états. Le profil est là, donc le tunnel est supposé actif, et l’heure suivante passe à déboguer des routes pour une association qui n’a jamais été construite.

L’erreur inverse est tout aussi courante. Un profil manquant envoie les gens chercher une panne réseau alors que la configuration n’a jamais été chargée. Nommez l’objet, puis exécutez la commande qui l’observe.

Trois objets, trois observations

strongSwan conserve une définition chargée, une SA IKE et une SA CHILD. La première est de la configuration, la deuxième une relation de contrôle authentifiée, et la troisième une protection négociée pour un trafic donné. Ils ont même des noms distincts, si bien qu’un profil nommé hq peut posséder un child nommé hq-lan.

Le tableau associe chaque couche à la commande qui l’affiche. Lisez la ligne avant de lire le journal.

Demander l’enfant construit d’abord sa SA IKE parente quand il n’en existe aucune. Demander seulement la SA IKE est un autre appel. Un canal de contrôle qui s’authentifie correctement ne garantit pas l’enfant demandé.

Cette différence compte lors d’une défaillance partielle. Une SA IKE peut être saine tandis que l’enfant échoue sur une divergence de sélecteur ou une proposition que le pair n’accepte pas. Les deux objets échouent pour des raisons différentes, ils méritent donc des observations séparées.

Choisissez l’action de démarrage délibérément

Dans swanctl.conf, le start_action d’un enfant décide du comportement après le chargement. La valeur par défaut none laisse la définition à une initiation manuelle ou à un usage en répondant. start le compose, tandis que trap laisse une politique qui négocie dès qu’un trafic correspondant se présente.

Ainsi, « le chargement ne démarre jamais un tunnel » et « le chargement en démarre toujours un » sont tous deux faux. L’action fait partie du profil et doit correspondre au rôle du pair. Deux passerelles qui attendent chacune l’autre côté produisent du silence, pas un tunnel.

Avec trap, le trafic doit correspondre aux sélecteurs, donc un ping sans rapport ne réveillera rien. Avec start, l’adresse du pair doit être utilisable et les deux côtés doivent s’accorder sur l’authentification et les propositions. Aucune des deux actions ne remplace la vérification de ces conditions.

La reprise est une politique distincte

Le démarrage n’est pas un keepalive. La détection de pair mort, la fermeture explicite par le pair, le renouvellement de clés et le redémarrage du processus sont des événements de cycle de vie différents avec leurs propres réglages. Configurez chacun délibérément au lieu d’attendre d’un démarrage initial qu’il les couvre tous.

Un tunnel qui monte au démarrage et meurt une heure plus tard relève de la reprise. La politique de démarrage a fait son travail puis a cessé d’importer. Regardez les réglages DPD et de renouvellement de clés avant d’accuser la négociation initiale.

Remplacer des définitions chargées est une opération à part. Les politiques de démarrage non par défaut ont des actions inverses documentées, et un rechargement est un changement d’exploitation plutôt qu’une supposition que chaque association a été mise à jour sur place. Faites les rechargements par étapes, là où une reconnexion est acceptable. Gardez l’ancienne configuration jusqu’à ce que la nouvelle soit prouvée.

Vérifiez ce qui existe avant de déboguer le routage

Passez les trois observations dans l’ordre : définitions chargées, SA IKE actives et entrées enfant. Chaque réponse resserre la question suivante. Sautez une étape et vous finissez par déboguer une couche qui n’a jamais été construite.

Commencez par ce qui est chargé et par ce qui est réellement établi :

swanctl --list-conns
swanctl --list-sas

Si l’enfant manque alors que le profil est correct, lancez-le par son nom et observez ce qui se passe. La sortie indique généralement si le parent est monté d’abord.

swanctl --initiate --child hq-lan

Une SA CHILD active n’est pas la ligne d’arrivée. Les règles de transfert, les routes et l’autorisation propre à l’application doivent encore concorder. Le cycle de vie répond à ce qui a été négocié ; il ne peut pas décider qui a le droit d’utiliser le service.