Délai TLS de soixante secondes : quel côté s'est réellement arrêté ?

Le client abandonne au bout de soixante secondes avec un message sur la négociation des clés, et l'ordinateur portable ne donne aucune opinion sur la raison. Cette phrase décrit la patience du client, pas le comportement du serveur. Trois situations très différentes la produisent : le paquet n'a jamais atteint le bon service, le service l'a écarté avant d'enregistrer quoi que ce soit, ou le service l'a refusé et l'a dit quelque part que le client ne peut pas voir. C'est la corrélation d'une seule tentative aux deux extrémités qui les sépare.

Donnez à une tentative une identité que vous pouvez rechercher

Notez l'heure de début avec son fuseau horaire, le nom du profil, la destination que le client a réellement résolue, le port, et si la connexion est en UDP ou en TCP. Si le profil contient plusieurs entrées distantes, notez laquelle cette tentative a choisie, car une nouvelle tentative a pu passer à l'entrée suivante sans modifier le fichier que vous lisez.

Prenez le point de terminaison dans le journal actif, pas dans le téléchargement dont vous vous souvenez. Un profil qui pointe vers une adresse privée est parfaitement valide et totalement inutilisable depuis un réseau qui ne peut pas y router, et ce cas ressemble exactement à un serveur qui est en panne.

Demandez ensuite à l'exploitant la même fenêtre sur l'instance prévue. Le décalage d'horloge est assez courant pour qu'un écart de quelques minutes fasse paraître absent un événement correspondant, alors notez l'écart au lieu de conclure qu'il n'y a eu aucun événement.

Quatre observations, quatre étapes suivantes différentes

Ce que le serveur enregistre décide de la branche. L'absence de toute tentative renvoie à l'adressage, au transport ou au chemin vers le service. Les paquets entrants qui disparaissent avant un échange ordinaire renvoient aux exigences du canal de contrôle du service réel. Un refus nommé renvoie à l'objet qu'il nomme. Les réponses qui quittent le serveur mais n'atteignent jamais le client renvoient au chemin de retour.

Un journal applicatif vide est une preuve plus faible qu'il n'y paraît. La journalisation commence à un certain point de l'échange, et les paquets écartés avant ce point ne laissent aucune trace dans le fichier que vous lisez. Là où c'est autorisé, l'exploitant peut utiliser des observations du service et du réseau pour voir si quelque chose est arrivé.

Gardez les quatre issues séparées dans vos notes. La tentation est de les fusionner en « le serveur ne répond pas », et c'est cette phrase qui pousse les gens à changer de chiffrement quand le vrai problème est une règle de pare-feu. Une note qui n'enregistre que le mot délai a jeté la distinction que vous venez de payer.

Corrigez l'étape que la preuve nomme

Une connexion TCP qui aboutit prouve seulement que quelque chose a accepté une socket. Elle ne prouve pas que l'écouteur est le service OpenVPN que vous avez configuré, et un serveur web sur le même nom d'hôte répond parfaitement à un navigateur tout en étant sans rapport avec le tunnel.

Si le serveur signale une liste de révocation expirée, c'est un fait bien plus précis que le délai final du client, et le correctif relève de l'autorité de certification et non du réseau. Si les deux extrémités ne s'accordent pas sur la protection du canal de contrôle ou sur le matériel partagé, réinitialiser un mot de passe ne change rien, car le rejet se produit avant tout examen d'un identifiant.

Changez une chose que la preuve soutient réellement, puis répétez le même profil contre le même point de terminaison. Conservez le premier nouvel événement si la connexion progresse davantage, car cet événement est l'étape suivante de l'enquête, pas un nouveau problème.

grep -nE 'TLS Error|VERIFY ERROR|CRL|handshake failed' /var/log/openvpn/server.log
date -u; timedatectl | head -3

Ce que l'allongement de la fenêtre change réellement

Soixante secondes, c'est la fenêtre de poignée de main du client, et la référence client de la communauté documente l'option qui la règle. L'augmenter fait attendre le client plus longtemps avant d'abandonner. Cela ne fait pas apparaître un service absent et ne rend pas acceptable un paquet refusé.

Une fenêtre plus longue a un usage légitime sur une liaison lente ou un serveur très chargé, et elle vaut la peine d'être essayée dès que vous avez la preuve que l'échange progresse lentement plutôt qu'il n'a pas lieu. L'essayer d'abord ne fait que retarder le même diagnostic d'une minute de plus et rend la chronologie plus difficile à lire. Si la chronologie montre un échange qui avance puis se bloque, la fenêtre est un symptôme de charge et non d'accessibilité.