Pourquoi votre VPN tombe à chaque rotation des clés

La connexion fonctionne une heure puis meurt, et le client ne rapporte rien de plus utile que disconnected. Cette période est l’indice, car quelque chose dans l’échange de renouvellement diffère de la poignée de main initiale. Le minuteur décide seulement quand vous le rencontrez. Conservez les messages de cet échange plutôt que l’étiquette finale.

Lisez l’étape, pas l’étiquette

Dans IKEv2, l’association IKE et l’association CHILD se renouvellent selon des calendriers distincts. Une proposition acceptable pour la première négociation ne l’est pas automatiquement pour la seconde. L’une peut aboutir pendant que l’autre est rejetée, ce qui produit un tunnel à moitié existant. Capturez l’échange avec l’outil qui le possède plutôt qu’avec une ligne de journal du client :

swanctl --list-sas
swanctl --log --level 2
ip xfrm state list

Pour OpenVPN, l’événement équivalent est une renégociation régie par la version et les paramètres de déploiement. Son comportement d’authentification a ses propres modes d’échec. Le message qui compte nomme l’étape en échec, et vous devez l’enregistrer mot pour mot plutôt que de le paraphraser dans un ticket.

Notez aussi les horodatages. Une coupure à intervalle fixe après la dernière négociation réussie est une constatation très différente d’une coupure qui survient au hasard pendant l’usage, et l’intervalle est souvent la seule preuve qui survit.

Comparez la proposition qui échoue

Une proposition rejetée produit un message clair chez le répondeur. La cause habituelle est une différence entre les deux extrémités sur l’algorithme, la longueur de clé, le groupe ou la durée de vie. La négociation CHILD initiale a pu réussir parce que l’autre côté l’a initiée, ce qui signifie qu’elle a utilisé la liste de propositions de l’autre côté. Regardez les deux extrémités avant de changer quoi que ce soit.

Les écarts de durée de vie méritent une attention particulière, car une valeur qui semblait généreuse à une extrémité peut pousser l’autre à lancer un renouvellement qu’elle ne peut pas terminer. La documentation sur le comportement de rekeying décrit comment le renouvellement d’association est déclenché et comment les deux extrémités peuvent différer dans leurs attentes temporelles. Comparez ce que chaque extrémité prétend prendre en charge plutôt que ce que suggère le fichier de configuration.

Un profil ancien ou un modèle de fournisseur peut figer une proposition que la version actuelle n’offre plus. L’écart ne se manifeste que lorsqu’une nouvelle négociation est forcée.

Séparez un problème d’identifiants d’un pair injoignable

Un renouvellement qui échoue à l’authentification se ressemble dans le client et diffère totalement sur le serveur. Si un identifiant est revérifié lors de la renégociation, un certificat expiré, un compte révoqué ou un mot de passe modifié produiront une coupure exactement à l’intervalle de renouvellement, alors que toutes les connexions précédentes ont réussi. Un pair injoignable est la troisième possibilité, et il ne produit aucun rejet : les paquets partent et rien ne répond. Ce cas suit généralement un changement de réseau plutôt qu’un minuteur, alors vérifiez si l’échec suit une itinérance, une période d’inactivité ou un changement de route.

Distinguez les trois par ce que l’extrémité distante a journalisé. Un rejet avec motif, un échec d’authentification et le silence sont trois corrections différentes. Redémarrer le client les réduit à une observation inutile.

Vérifiez les dates du certificat et l’état du compte avant de blâmer le réseau. Les deux sont bon marché à inspecter et les deux sont invisibles dans le message du client lui-même.

Forcez un renouvellement et lisez le résultat

Forcez un renouvellement via la méthode prise en charge par l’opérateur plutôt que d’attendre une heure le suivant. Gardez la politique d’échec requise intacte pendant ce temps. Désactiver la vérification ou étirer les durées de vie à un jour fait disparaître le symptôme de vos journaux sans rien corriger. Cela laisse aussi une panne plus longue en attente pour la personne suivante.

Une fois le correctif en place, vérifiez le tunnel renouvelé puis émettez une nouvelle requête depuis l’application. Une session applicative qui était vivante au moment du changement d’association peut avoir besoin de sa propre reprise même si le tunnel est redevenu sain. Les utilisateurs le signaleront comme un VPN toujours en panne.

Enregistrez les versions publiées, les minuteurs négociés et l’étape qui a échoué. La prochaine récidive pourra alors être comparée à celle-ci au lieu d’être décrite de nouveau de mémoire.