IKEv2 : renouvellement de clés ou réauthentification — pourquoi la connexion tombe plus tard

Le tunnel monte le matin et fonctionne pendant des heures. Puis il tombe, se reconnecte après une tentative et refait la même chose le lendemain. Rien n’a changé sur le réseau et personne n’a touché à un mot de passe. Les sessions qui échouent à une frontière de renouvellement franchissent en général l’une de deux opérations différentes, et une seule d’entre elles revérifie vos identifiants. Lire laquelle s’est déclenchée, c’est tout le diagnostic.

Deux opérations qui se ressemblent de l’extérieur

Le renouvellement de clés remplace les associations de sécurité ou le matériel de clés dans l’échange défini par le protocole. L’authentification n’est pas répétée, donc l’identité acceptée au début de la session est simplement reportée.

La réauthentification va plus loin : elle établit une relation authentifiée nouvelle, ce qui signifie que les identifiants sont de nouveau évalués. Tout ce qui a expiré, été révoqué ou modifié dans l’annuaire devient visible à ce moment-là.

Ce qu’un renouvellement de clés remplace vraiment

IKEv2 maintient deux types d’association avec des cycles de vie séparés. L’IKE SA protège le canal de contrôle, et les CHILD SA protègent le trafic réel. Renouveler l’une n’est pas synonyme de reconnecter le client.

Cette séparation explique un schéma familier : le trafic circule bien, puis une CHILD SA est renouvelée et la proposition ne correspond plus parce que quelqu’un a modifié la phase 2 d’un côté des semaines plus tôt. Le changement est resté là sans faire de mal jusqu’à ce que le renouvellement l’exerce.

Les désaccords de durée se comportent de la même façon. Le pair qui atteint sa limite en premier lance l’échange, et l’autre doit l’accepter.

Ce que la réauthentification réévalue

Avec la réauthentification, le certificat client qui était valide à la connexion peut être expiré à présent. Un identifiant révoqué, un mot de passe renouvelé ou un second facteur indisponible remontent tous ici, et non au moment du renouvellement.

C’est pourquoi allonger chaque durée ressemble à un correctif et n’en est pas un. Vous avez reporté le contrôle au lieu de le passer. Le prochain renouvellement arrive avec le même défaut et une fenêtre d’interruption plus courte pour le remarquer.

Certaines implémentations chevauchent l’ancien et le nouvel état pendant la réauthentification. D’autres produisent un bref vide. Des réglages identiques chez deux fournisseurs peuvent donc donner des expériences utilisateur différentes. Testez le comportement au lieu de supposer que la norme l’impose.

Lisez les horodatages avant de changer quoi que ce soit

Capturez le moment de la panne avec l’état de l’association avant et après. Si l’ancienne association a été remplacée sans échange d’authentification, vous étiez à une frontière de renouvellement. Si un échange AUTH apparaît juste avant la panne, vous étiez à une réauthentification.

strongSwan expose cela sous forme de réglages distincts : rekey contrôle le renouvellement des clés, reauth contrôle si une nouvelle authentification a lieu, et les valeurs de marge décident à combien de temps avant l’expiration chacune commence. la documentation sur le renouvellement de clés décrit l’interaction, et elle vaut la peine d’être lue avant de copier une durée depuis un message de forum.

Distinguez tout cela d’une simple perte réseau. Un lien coupé produit un événement de détection de pair mort ou une tempête de retransmissions, pas un échange propre avec des propositions concordantes.

Changez ce qui a échoué

Un rejet d’identifiants exige de corriger le problème d’identité : renouvelez le certificat, restaurez le compte, réenrôlez le facteur. Un désaccord de proposition ou de durée exige de comparer les paramètres des deux côtés.

Étirer les durées pour éviter le symptôme est la seule option qui donne toujours l’impression d’avoir marché et ne marche jamais.

Testez un renouvellement contrôlé

Forcez le renouvellement au lieu d’attendre un jour. Puis répétez avec une réauthentification si le déploiement en prend une en charge, et surveillez les deux extrémités.

Une première connexion réussie n’exerce rien de tout cela. Le cycle de vie qui suit est là où ces déploiements cassent réellement.