Quels protocoles ce nœud VPN public propose-t-il vraiment ?
Ce n’est pas parce que le logiciel serveur prend en charge un protocole que ce nœud l’a activé. Vérifiez le point de terminaison, le profil et l’étape qui échoue réellement.
Le logiciel le prend en charge, donc le nœud le propose. Cette déduction est fausse assez souvent pour être une règle : un déploiement SoftEther peut activer n’importe quel sous-ensemble de ses méthodes de connexion compatibles, et un nœud public est un déploiement avec un propriétaire et une configuration. Ce à quoi vous pouvez vous connecter dépend de ce nœud, pas de la liste de fonctionnalités du projet qu’il exécute. C’est dans l’écart entre les deux que vivent réellement la plupart des tickets « le protocole est cassé ».
Ce que la liste du projet promet réellement
Les fonctions de protocole du projet décrivent ce dont le serveur est capable. Un nœud donné active certains de ces écouteurs et pas d’autres, et l’opérateur peut modifier cet ensemble sans toucher à la version du logiciel. Deux nœuds de la même compilation se comportent donc différemment, et un profil qui fonctionne contre l’un ne prouve rien sur la cible suivante. La liste du nœud lui-même prime sur la page du projet lorsque vous choisissez où vous connecter.
Lisez la liste comme cinq champs, pas comme un menu : point de terminaison, port, transport, famille de protocoles et méthode d’authentification. Un nœud public qui annonce SSTP vous a parlé d’un écouteur sur un port ; il ne vous a pas dit quel certificat il présente ni si votre compte y fonctionne. Comparer ces cinq champs à votre profil est plus rapide que n’importe quelle quantité de réinstallation du client, et cela produit une attente écrite que vous pourrez tester plus tard.
Faites correspondre le profil au point de terminaison qu’il nomme
Une entrée SoftEther native n’est pas automatiquement une configuration OpenVPN, même lorsque les deux apparaissent sur une page de fournisseur sous un même titre. Lorsqu’un nœud publie à la fois un écouteur TCP et un écouteur UDP pour OpenVPN, traitez-les comme deux points de terminaison : un profil modifié de l’un à l’autre pointe vers un écouteur que personne n’a activé. L’étiquette de transport du fichier fait partie de l’adresse, ce n’est pas un réglage cosmétique.
Qu’un client accepte un fichier importé établit que le fichier s’analyse. Cela ne dit rien de la présence d’un écouteur distant à l’autre bout, et c’est pourquoi la première tentative de connexion est le véritable test. Comparez la ligne distante du profil à l’hôte et au port annoncés du nœud avant d’accuser le protocole.
Sondez l’étape qui échoue
Un hôte qui répond au trafic web peut toujours manquer le service VPN prévu, et un hôte qui refuse un protocole n’est pas nécessairement en panne pour tous. Ces deux erreurs envoient les gens dans des directions opposées le même après-midi. L’un poursuit un pare-feu qui va bien ; l’autre réinstalle un client qui n’a jamais été le problème. Sondez chaque chemin séparément pour que la réponse décrive un écouteur plutôt que tout l’hôte.
Ces cinq contrôles couvrent les méthodes courantes des nœuds publics. Exécutez-les depuis le même réseau que celui qu’utilise le client, car un port filtré est identique à un écouteur absent vu de loin.
nc -vz node.example 1194
nc -vz node.example 443
openvpn --config client.ovpn --verb 4
nmap -sU -p 500,4500 node.example
openssl s_client -connect node.example:443 -servername node.example| Résultat | Étape | Ce que cela écarte |
|---|---|---|
| Connexion refusée ou délai dépassé | Transport | Écouteur absent, filtré ou mauvais port |
| Erreur de poignée de main TLS ou d’identité | Certificat | Disponibilité du protocole ; l’écouteur a répondu |
| AUTH_FAILED ou rejet du compte | Authentification | Le point de terminaison ; le problème vient des identifiants |
| UDP 500 et 4500 silencieux | Négociation IPsec | ESP et L2TP sont bloqués avant l’authentification |
Rattachez chaque erreur observée à sa ligne avant de changer quoi que ce soit. Un échec d’identité TLS prouve que l’écouteur existe, donc réécrire le profil vers un autre protocole jetterait une preuve qui fonctionne. Une connexion refusée prouve seulement que ce port n’a pas répondu, ce qui est une affirmation bien plus étroite que « le nœud ne prend pas en charge OpenVPN ».
Conservez l’erreur avant de changer quoi que ce soit
Notez le résultat exact : un délai dépassé, un échec d’identité de certificat, un rejet de compte et un refus au niveau applicatif sont quatre issues différentes. Seule la première concerne un protocole indisponible, et seule la dernière concerne une autorisation après une connexion réussie. Réinitialiser le client ou changer de protocole détruit cette distinction, car l’échec suivant arrive avec un autre historique et sans référence pour comparer.
N’affaiblissez pas la vérification pour faire semblant qu’un profil incompatible fonctionne. Un contrôle de certificat désactivé transforme un échec d’identité clair en connexion vers quelque chose que vous ne vouliez pas atteindre, et le succès obtenu est pire que l’erreur d’origine parce qu’il cache quelle étape était fausse.
Revérifiez pour chaque nœud, à chaque fois
Les options natives SSL, OpenVPN, L2TP/IPsec et SSTP d’une liste de nœuds publics décrivent la configuration de ce nœud à cet instant. Le même logiciel ailleurs peut présenter un ensemble différent, et un fournisseur peut retirer un écouteur entre votre signet et votre prochaine tentative. Les vieilles notes décrivent de vieux déploiements.
Consignez le profil vérifié avec son point de terminaison et sa méthode, puis répétez la sonde lorsque le nœud change ou que la connexion commence à échouer. La spécification du protocole SoftEther est la référence de ce que le logiciel peut faire ; la liste du nœud lui-même est la référence de ce qu’il fait. Gardez les deux documents séparés et le diagnostic devient plus court.