Expiration de la connexion VPN : DNS, transport, négociation ou connexion
Une expiration signifie seulement qu'une échéance est passée. Comparez quatre étapes, résolution de nom, transport, négociation et connexion, pour voir laquelle s'est terminée en dernier.
« La connexion a expiré » est l'erreur la moins précise qu'un client VPN puisse afficher. Elle signifie qu'une opération a manqué son échéance, et chaque étape, de la résolution de nom à la réponse de connexion, a une échéance. Les clients qui n'affichent que le message final font paraître les étapes identiques, alors les gens augmentent le délai, changent le port et réinstallent le profil, dans cet ordre, sans rien apprendre. Comparer les étapes est plus rapide : chacune échoue à un endroit différent, et chaque échec laisse un type de preuve différent.
Quatre étapes, quatre échecs différents
La séquence est fixe même quand le client la masque : le nom doit être résolu, un transport doit être établi vers l'adresse obtenue, le protocole doit négocier ses paramètres et ses clés, et le compte doit être authentifié. Le guide de dépannage de la connectivité d'OpenVPN suit le même ordre pour son propre client, et les autres le suivent de près. Une expiration à la deuxième étape et une à la quatrième n'ont rien en commun sinon le mot à l'écran.
| Stage | Looks like | What it does not prove |
|---|---|---|
| Name resolution | fails in under a second, before any contact | nothing about the server being up |
| Transport | waits the full timeout, then gives up | nothing about the VPN service behind the port |
| Negotiation | connects, then stalls at handshake | nothing about credentials |
| Login | a reply arrives and is rejected or hangs on a prompt | nothing about reachability |
Lisez le journal en cherchant la dernière ligne qui indique un progrès, pas la dernière ligne avant l'erreur. La plupart des clients affichent quelque chose comme une adresse résolue, une socket établie, une poignée de main commencée ou une demande d'authentification, et l'étape qui suit cette ligne est celle qui a expiré.
La résolution de nom échoue avant tout contact
Si le point de terminaison ne se résout jamais, le client n'a rien à quoi se connecter et aucun travail de transport n'a eu lieu. Cet échec est généralement instantané plutôt qu'une expiration complète, ce qui est le moyen le moins coûteux de le distinguer des autres. Testez le nom avec le résolveur du système et avec un second résolveur, et comparez les deux réponses avant de conclure que le serveur est en panne.
Une ancienne adresse copiée d'un message de forum est une cause fréquente d'expiration qui ressemble à un problème de serveur, car l'adresse appartient maintenant à autre chose ou à rien. Utilisez le profil actuel de l'opérateur au lieu de remplacer une adresse qui fonctionnait auparavant. Une réponse de ping absente ne prouve rien dans un sens ou dans l'autre : beaucoup de points de terminaison ignorent ICMP tout en servant parfaitement bien.
La mise en place du transport attend un paquet qui ne viendra pas
Quand le DNS est correct et que le client brûle encore tout le délai, la couche de transport est le suspect. En TCP, vous pouvez tester le port directement ; Test-NetConnection sous Windows ou nc -vz sous Linux vous dit si quelque chose accepte la connexion, et c'est plus utile qu'un ping. En UDP, vous ne pouvez pas tester de la même façon, car il n'y a pas de poignée de main à terminer à cette couche, et cette asymétrie provoque beaucoup de conclusions erronées.
Ce qu'un test TCP prouve est limité : un service qui accepte le port 443 n'est pas forcément l'écouteur VPN, et un point de terminaison uniquement UDP n'a aucun port TCP pour accepter quoi que ce soit. Réécrire un profil d'UDP vers TCP ne crée pas d'écouteur de l'autre côté ; cela change seulement ce que votre client attend. Si le réseau filtre le protocole, le changement produit une expiration différente à la même étape.
Les portails captifs méritent leur propre vérification à cette étape. Tant que le portail n'a pas autorisé l'appareil, le trafic sortant va au portail et la tentative de tunnel reste simplement suspendue. Terminez d'abord le portail dans un navigateur, réessayez ensuite, et ne changez pas le profil tant que le portail est encore en attente.
Négociation et connexion signifient que le serveur a répondu
Une fois que le tunnel atteint le serveur, le client démarre une poignée de main et l'erreur change de nature. Un blocage ici relève de la compatibilité, pas de l'accessibilité : versions de protocole incompatibles, un réglage de chiffrement ou de canal de données que l'autre côté n'acceptera pas, ou un profil qui attend une fonction que le serveur n'offre pas. OpenVPN a déplacé ses valeurs par défaut de négociation entre versions majeures assez souvent pour qu'un profil écrit pour une génération puisse atteindre le serveur et malgré tout ne pas monter.
L'authentification est la dernière étape et la plus facile à mal lire. Un rejet explicite est une réponse, ce qui signifie que le chemin fonctionne et que le problème vient de l'identité, du certificat ou de l'état du compte. Un flux d'authentification unique par navigateur est un troisième cas : le client attend une action que vous n'avez pas faite, ou un navigateur qu'il ne peut pas lancer, et rien n'arrivera avant que vous terminiez cette étape.
Comparez les preuves avant de changer la nouvelle tentative
Gardez l'appareil et le profil fixes et changez une chose à la fois, en commençant par le réseau. Si le même profil se connecte sur un partage de connexion téléphonique et expire sur le Wi-Fi de l'hôtel, la variable est le chemin, pas le serveur. S'il échoue partout, la variable est le profil ou le point de terminaison. S'il n'échoue qu'à une heure de la journée, relevez l'horodatage et comparez-le aux événements côté serveur avant de supposer quoi que ce soit sur la charge.
Pour un service que vous administrez, la comparaison décisive est de savoir si la tentative arrive. Une connexion qui atteint l'écouteur puis se bloque relève de l'étape de négociation ; celle qui n'apparaît jamais dans la vue de l'écouteur est un problème de transport ou de résolution, et aucun réglage des nouvelles tentatives ne la déplacera. Les journaux du serveur séparent aussi une connexion refusée d'une chute silencieuse, ce qui est la différence entre une correction d'identité et une correction de pare-feu.
Notez la version du client, le nom du profil, l'heure de la tentative avec son fuseau horaire et la première erreur utile plutôt que la dernière ligne de déconnexion. Retirez les clés et le matériel porteur d'identifiants avant de partager l'extrait. Faites ensuite une correction significative et réessayez, car un délai plus long n'aide que l'opération lente documentée et ne fait rien pour une adresse erronée ou un port bloqué.