strongSwan reste à terre après un redémarrage du peer : récupérer un tunnel

Abandonnez le redémarrage du démon. Placez l’initialisation et le DPD sur la connexion qui doit revenir, puis vérifiez par nom et prouvez le service, pas le démon.

La passerelle distante redémarre, revient en une minute, et le démon strongSwan local continue de tourner avec le tunnel toujours à terre. Une tâche cron qui grep ESTABLISHED et redémarre le démon finira par masquer cela, et elle interrompra aussi chaque tunnel sans rapport sur la machine tout en manquant peut-être celui qui a échoué. La récupération appartient à la connexion qui doit revenir, exprimée dans des réglages qui survivent à un rechargement. Ce runbook met cela en place pour une seule connexion et prouve le résultat par nom.

Retirez le redémarrage global, gardez ses preuves

Un redémarrage du démon a deux défauts précis : il détruit l’état de chaque connexion et il ne vous dit rien sur l’événement qui a réellement échoué. Le texte d’état que vous avez grepé peut venir d’une autre connexion, tandis que le child requis restait inactif parce que rien ne l’avait déclenché.

Lisez les connexions chargées et les associations actives avant de changer quoi que ce soit, afin de disposer d’une image d’avant à comparer au retour du peer.

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

Placez l’initialisation et les nouvelles tentatives sur la connexion qui revient

Dans un déploiement swanctl.conf, ces réglages vivent au niveau de la connexion et du child plutôt que dans une politique globale. Le fragment ci-dessous est un exemple côté initiateur qui suppose que les propositions, l’authentification et les sélecteurs sont déjà corrects.

connections {
    branch {
        keyingtries = 0
        dpd_delay = 30s
        children {
            private-lan {
                start_action = trap|start
                dpd_action = restart
            }
        }
    }
}

start_action décide de ce qui se passe au chargement du child : start initie immédiatement, tandis que trap installe une politique qui déclenche l’initialisation quand un trafic correspondant apparaît. Écrire trap|start exige strongSwan 5.9.6 ou ultérieur, vérifiez donc la version avant de copier la ligne. dpd_action=restart demande une nouvelle négociation dès que le peer est déclaré mort, et keyingtries=0 au niveau de la connexion autorise d’autres tentatives jusqu’au succès ou à une erreur permanente. Sous IKEv2, dpd_timeout n’a aucun effet, car la retransmission ordinaire décide quand le peer ne répond pas.

Le délai de cet exemple est un point de départ, pas une échéance universelle. Choisissez-le selon la durée du redémarrage du peer et la quantité de retransmission que vous acceptez de supporter.

Sachez de quel événement vous récupérez

Trois défaillances se ressemblent sur un tableau de bord et demandent des réglages différents. Une connexion initiale qui n’a jamais monté est un problème de configuration ou d’accessibilité. Un peer qui a cessé de répondre est le cas DPD. Un child que le peer a fermé explicitement est un événement de politique avec son propre close_action, que le DPD n’observe jamais. Lire le journal autour de la coupure vous dit laquelle des trois vous avez, et la réponse change le correctif.

N’ajoutez pas de ré-initialisation agressive à une connexion que les opérateurs ferment volontairement pour maintenance, sinon le tunnel réapparaît au milieu de la fenêtre. Pour les conceptions à la demande, un trap conservé suffit, car le trafic correspondant rétablit le child sans aucun minuteur.

Vérifiez par nom, pas par l’état du démon

Lisez la connexion et son child par nom pendant que le peer est encore à terre, puis de nouveau à son retour ; la différence entre ces deux sorties est la preuve.

swanctl --initiate --child private-lan
swanctl --terminate --ike branch

Confirmez ensuite le service plutôt que l’association. Une association de sécurité child fraîche plus une requête réussie vers la destination privée derrière elle sont la paire de faits qui compte, et un démon en cours d’exécution avec un tunnel sans rapport en bonne santé ne prouve ni l’un ni l’autre.

Si le child ne s’initialise jamais, vérifiez que le trafic de test correspond exactement aux sélecteurs configurés, protocole et port compris. S’il s’initialise et échoue, lisez l’erreur d’authentification ou de proposition au lieu de la cacher derrière une boucle sans fin, car keyingtries=0 répétera volontiers un rejet permanent pour toujours.

Chargez la modification dans une fenêtre et retestez

Recharger est plus sûr que redémarrer le démon, et ce n’est toujours pas gratuit : remplacer ou décharger un child peut fermer une association démarrée ou faire tomber son trap.

Chargez pendant une fenêtre de maintenance, conservez le fichier précédent et confirmez que la connexion apparaît avec les réglages voulus plutôt qu’avec les valeurs par défaut.

swanctl --load-conns
swanctl --list-conns

Revenez en arrière en restaurant le fichier précédent et en le rechargeant, puis répétez les deux mêmes commandes. Un tunnel qui ne revient qu’après un redémarrage du démon n’est pas réparé, il est réinitialisé.

Articles similaires