OpenVPN : la poignée de main TLS a échoué, sur quelle branche êtes-vous ?

La ligne qui indique l'échec de la poignée de main TLS est la fin d'une histoire, pas son début. Ce qui compte, c'est l'événement immédiatement précédent, car il nomme lequel des quatre défauts très différents vous avez. Un délai d'attente, un décalage du canal de contrôle, un certificat refusé et un échec après la négociation produisent tous le même titre. Choisissez la branche d'après les preuves, et la correction cesse d'être une supposition.

Lisez le dernier événement avant l'échec

Remontez au lieu de lire la dernière ligne. L'événement qui précède la déconnexion nomme généralement l'étape : aucune réponse, une erreur lors de l'échange des paquets de contrôle, un résultat de vérification, ou une négociation réussie suivie d'un résultat d'authentification. Chacun appartient à un responsable différent. Cette seule ligne décide quelle section ci-dessous s'applique.

Enregistrez le texte de l'erreur avec la version du client, le point de terminaison et le transport. Gardez les clés, les mots de passe et les profils non expurgés hors de tout ce que vous publiez.

Une première erreur précise vaut mieux qu'un long extrait de journal. Elle nomme l'étape, et l'étape nomme le responsable.

Branche un : rien n'est revenu

Si le client a envoyé son premier paquet et n'a rien reçu d'utilisable, le problème est sur le chemin ou chez l'écouteur. Vérifiez que le profil correspond à une option réellement proposée par l'opérateur : adresse, port et UDP ou TCP. Vérifiez ensuite si le point de terminaison est accessible depuis ce réseau. Notez laquelle des deux vérifications a échoué avant de continuer.

Un navigateur qui charge une page sur le même nom d'hôte prouve seulement qu'un service web a répondu. Même une connexion TCP acceptée ne dit rien sur le point de savoir si OpenVPN a terminé la négociation.

Si le profil fonctionne sur un autre réseau de confiance, conservez cette comparaison. Elle localise la restriction sur un chemin ou un intermédiaire.

Branche deux : le canal de contrôle ne correspond pas

Quand l'échange commence puis se bloque, les réglages du canal de contrôle sont le premier suspect. tls-auth et tls-crypt doivent correspondre au déploiement, et le matériel d'un autre serveur ne produira pas un échange utile. Cette panne survient avant toute connexion de compte. Un profil copié depuis un serveur plus ancien en est la source habituelle.

Une réinitialisation de mot de passe ne remplace pas ces réglages, et emprunter une clé à un autre service n'est pas une correction de compatibilité. Obtenez le profil par le canal vérifié de l'opérateur et notez la version de client qu'il attend.

Notez l'erreur de négociation précise plutôt que d'activer une pile d'algorithmes plus anciens pour voir ce qui tient. C'est un texte d'erreur capturé qui permet à l'opérateur de vérifier son côté.

Branche trois : un certificat a été refusé

Un échec explicite de vérification nomme le certificat qu'il n'aime pas. Vérifiez d'abord l'horloge de l'appareil, puis lisez quel objet a échoué : le certificat du serveur, celui du client, ou un émetteur de la chaîne. L'expiration, un émetteur non fiable et une identité inattendue sont trois messages différents.

Laissez la vérification active pendant que vous obtenez du matériel corrigé. Accepter un certificat sans rapport supprime l'erreur sans prouver que vous avez atteint le serveur prévu.

Notez si la panne suit le réseau ou le profil. Une erreur de certificat qui apparaît partout n'est pas un problème de chemin.

Branche quatre : la négociation s'est terminée et autre chose a échoué

Une fois l'échange d'identité réussi, la panne restante relève de l'authentification ou du routage. Un rejet explicite de compte est une question d'authentification, et un tunnel connecté avec des sites inaccessibles est une question de routage ou de DNS. Continuer à remplacer des options TLS à ce stade endommage une étape qui fonctionnait déjà.

Quand vous signalez le problème, dites si tous les réseaux échouent, si un autre profil fonctionne et si le serveur a enregistré la tentative. Le silence côté serveur et un rejet de sa part se situent à des limites différentes.