L’annuaire public VPN dit en ligne ; votre client dit non
Un annuaire affiche un contrôle d’il y a quelques minutes, pas une promesse pour votre prochaine tentative. Parcourez les étapes de la connexion dans l’ordre et voyez où le nœud échoue réellement.
Vous ouvrez l’annuaire, triez par vitesse, choisissez un nœud marqué en ligne, et le client abandonne avant d’avoir terminé la connexion. La liste ne mentait pas, à proprement parler. Elle rapportait le résultat de la sonde de quelqu’un d’autre, depuis un autre réseau, à un moment antérieur, contre un service qu’un bénévole peut éteindre à tout moment. Comprendre cet écart transforme une chasse frustrante en une courte suite de contrôles que vous pouvez exécuter sur n’importe quel candidat.
Ce que la liste a réellement mesuré
Un annuaire public conserve des champs comme l’heure du dernier contrôle, une valeur observée de temps aller-retour, un nombre de sessions et parfois une liste de protocoles. Chacun d’eux décrit la dernière observation réussie du point de vue du projet lui-même, pas l’état du nœud au moment où votre paquet arrive.
La fraîcheur compte plus que le nombre. Un nœud contrôlé il y a quatre minutes et un nœud contrôlé il y a quatre heures peuvent afficher le même marqueur vert, et un seul des deux ressemble encore à l’état enregistré. Cherchez l’horodatage, pas la couleur.
L’exploitation bénévole ajoute une seconde source de changement qu’aucun moniteur ne peut corriger. L’opérateur redémarre peut-être un portable, manque de bande passante, change de fournisseur ou ferme simplement le capot. Une entrée de liste est un candidat, et la traiter comme un accord de niveau de service est une erreur de catégorie.
Surveillez les étapes du client, pas l’indicateur qui tourne
Chaque client VPN traverse la même large séquence : résoudre le nom, ouvrir une connexion de transport, négocier la sécurité, s’authentifier, puis configurer le tunnel et transmettre des données. Un échec à chaque étape laisse des preuves différentes, et l’indicateur qui tourne n’en montre aucune.
Commencez par la résolution de nom. Si le nom d’hôte ne se résout pas, rien n’a été testé sur la disponibilité du nœud, car la connexion n’a jamais quitté votre machine. Ensuite, le transport : un échange TCP ou UDP refusé ou expiré vous dit que le point de terminaison ne répond pas sur ce port, ce qui est un constat réel sur le nœud. Puis la négociation et l’authentification, où un mauvais certificat, un profil expiré ou un chiffrement incompatible échouent alors que le nœud est parfaitement sain. Ce n’est qu’une fois le tunnel configuré qu’une panne de routage ou de DNS peut expliquer la dernière étape.
Lisez le journal du client avec la verbosité la plus élevée qui tient encore à l’écran, et notez la dernière ligne qui a réussi. Cette ligne est là où le diagnostic commence, et elle est généralement plus instructive que tout ce que l’annuaire affiche.
Une variable par tentative
Comparez des candidats avec le même client, le même réseau d’accès et le même format de profil, en ne changeant que le point de terminaison. Sinon, un échec pourrait être le vôtre et vous l’attribueriez au nœud.
Deux tentatives suffisent à établir un schéma, et une troisième le confirme. Si le nœud A échoue à l’étape de transport et le nœud B à l’authentification, vous avez deux problèmes sans rapport plutôt qu’une liste périmée.
Quand chaque nœud échoue de la même façon
Un échec universel à la première étape pointe vers votre côté : un résolveur qui ne peut pas répondre, un pare-feu local qui bloque le protocole ou un réseau qui n’autorise que le trafic web. L’annuaire ne peut pas le signaler, car ses sondes ne partent pas de votre siège.
Testez délibérément le cas du réseau façonné. Certains réseaux d’accès autorisent HTTPS vers le web et suppriment d’autres protocoles, ce qui fait paraître chaque candidat mort alors que la liste est exacte. Comparer le chargement d’une page dans un navigateur à une tentative de connexion brute sépare ces deux situations en moins d’une minute.
Lisez l’échec à l’étape où il s’est produit
Reproduisez la tentative depuis un terminal pour que les étapes soient visibles. Les trois commandes ci-dessous résolvent le nom, testent si le port répond et affichent les lignes de négociation d’un profil OpenVPN :
dig +short node.example.net
curl -s --max-time 5 telnet://node.example.net:443
openvpn --config node.ovpn --verb 4 2>&1 | grep -iE "TLS|AUTH|PUSH"Si le port répond et que la ligne de négociation signale un problème de certificat, le nœud est actif et votre profil est périmé. Si le port ne répond pas du tout, l’entrée est un candidat qui a échoué, et passer au suivant est la bonne réponse plutôt que de déboguer votre client. Notez l’étape sur une ligne courte, et la prochaine tentative part de la connaissance plutôt que de l’espoir.