Pourquoi un tunnel Azure OpenVPN tombe environ toutes les soixante secondes

Le tunnel termine sa poignée de main, transporte du trafic pendant environ une minute, puis se reconnecte. Cette séquence écarte le suspect habituel, car un pare-feu qui bloquerait le port aurait arrêté la poignée de main et non la session. Ce que vous avez est un désaccord sur la vitalité : un côté a décidé que l'autre s'était tu et a abattu un tunnel qui fonctionnait. La ligne du journal indique de quel côté, et c'est elle qui choisit le correctif.

Lisez cette ligne avant de toucher au moindre temporisateur.

Le mythe : quelque chose sur le chemin bloque le tunnel

Si un port était bloqué, la connexion échouerait au départ et resterait en échec. Un cycle qui se répète signifie que les messages de contrôle circulent, que les sessions s'établissent et que quelque chose plus loin dans la conversation ne cesse d'expirer. Le blocage produit du silence, et ceci produit un rythme.

Le rythme est l'indice utile. Les temporisateurs le produisent ; la perte de paquets rarement.

Lisez la raison de la déconnexion avant le temporisateur

OpenVPN nomme sa raison, et chaque nom renvoie à un sous-système différent. Session invalidated: KEEPALIVE_TIMEOUT est un temporisateur qui expire, alors comparez les valeurs de ping et de ping-restart aux deux extrémités. AUTH_FAILED est un état d'identifiants ou de certificat, et aucun changement de temporisateur n'aidera. Une erreur TLS signifie que les pairs n'ont jamais atteint l'étape keepalive.

Notez l'heure de connexion, l'heure de déconnexion et si l'intervalle est stable à la seconde près. Cette seule mesure sépare un horaire configuré d'une coïncidence.

Un intervalle stable est un temporisateur. Un intervalle qui dérive est plus probablement un problème de chemin ou une session déplacée.

Deux temporisateurs keepalive qui ne se sont jamais accordés

Les profils exportés depuis le portail portent parfois encore des lignes comme keepalive ou ping-restart copiées d'un modèle de serveur communautaire. La passerelle exécute sa propre détection de pair mort et impose ses propres attentes, et les deux horaires n'ont pas à correspondre. Quand ils divergent, le client redémarre selon un horaire que la passerelle n'a jamais accepté.

Les deux valeurs ne sont pas le même contrôle. ping est la fréquence à laquelle le client envoie un écho, et ping-restart est le temps qu'il attend sans rien entendre avant d'abattre le tunnel. Un profil avec un ping-restart court et une passerelle qui répond lentement redémarreront à chaque période de silence, ce qui est exactement la forme d'un cycle d'une minute.

Le changement minimal côté client est de neutraliser les temporisateurs au niveau supérieur du profil, en dehors de chaque bloc intégré :

keepalive 0 0

Enregistrez, rechargez le profil, reconnectez-vous. Une session déjà en mémoire conserve les anciennes valeurs, ce qui explique pourquoi la modification semble parfois n'avoir rien fait.

Le nom du certificat peut bouger sous vos pieds

L'authentification par certificat Azure dépend du fait que le client fasse confiance au nom que la passerelle présente aujourd'hui. Une ligne verify-x509-name dans un téléchargement plus ancien peut épingler un nom qu'une reconstruction de la passerelle ou un renouvellement de certificat a changé depuis, et le décalage se manifeste comme une boucle de reconnexion plutôt que comme une erreur claire. Supprimer la ligne rétablit la connectivité, ce qui en fait un bon diagnostic et un mauvais correctif permanent, car cela supprime aussi la vérification. Une fois le tunnel stable, rétablissez la ligne avec le nom que la passerelle présente réellement.

Testez une deuxième génération de client sur la même machine avant de modifier la passerelle. Si un client boucle et que l'autre tient, le profil n'est pas le problème.

Quoi changer, et dans quel ordre

Vérifiez ensuite une session déplacée. Deux appareils qui partagent un certificat peuvent s'expulser mutuellement, et le résultat semble périodique parce que les deux côtés n'arrêtent pas de se reconnecter. Comparez les enregistrements de session point à site pour la même identité qui apparaît encore et encore.

Testez ensuite le chemin inactif en faisant circuler du trafic en continu pendant plusieurs minutes. Si les chutes s'arrêtent pendant que le trafic circule, le temporisateur qui compte appartient à un dispositif NAT ou à un répartiteur de charge sur le chemin, et non à OpenVPN.

Les réglages de la passerelle ne devraient changer qu'après ces quatre tests.