Terminer une poignée de main TCP vers le port 443 alors que le tunnel ne se construit jamais prouve une chose, et c’est une petite chose. Quelque chose écoute et accepte volontiers une connexion à cette adresse. Cela n’identifie pas le service, le certificat qu’il présentera, ni ce qui se passe après les premiers octets.

Quatre étapes séparent cette poignée de main d’un tunnel fonctionnel, et chacune produit une erreur différente.

Un port ouvert ne décrit qu’une seule couche

Accepter une connexion TCP signifie qu’un processus possède la socket et que le chemin autorise la poignée de main. Cela ne dit rien sur le fait que ce processus soit un serveur SSTP, qu’il détienne un certificat valable pour le nom de votre profil, ou qu’il autorise votre compte. Un serveur web à la même adresse répond parfaitement à la poignée de main puis répond à votre requête SSTP par une erreur HTTP. Tout ce qui se trouve au-dessus de cette poignée de main reste non testé.

Traitez le test de port comme le filtre le moins coûteux possible et non comme un verdict. Sa valeur est d’éliminer toute une catégorie de pannes, non de confirmer tout ce qui se trouve au-dessus.

Confondre les deux est la raison pour laquelle les gens réinstallent des clients après un test qui n’a jamais examiné le vrai problème du client.

Séparez les quatre étapes par des preuves

Les étapes sont l’accessibilité du transport, la validation TLS, l’échange SSTP sur HTTPS et l’authentification PPP à l’intérieur du tunnel. Un chemin qui passe la première et échoue à la quatrième exige une correction des identifiants ; celui qui échoue à la seconde exige une correction de certificat ou de nom. Ces réparations n’ont rien en commun, et choisir la mauvaise gaspille la panne.

nc -vz vpn.example.net 443
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief
curl -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/

La troisième commande mérite une lecture attentive. Un 200 d’une page web ordinaire vous dit qu’un service web est présent ; il ne vous dit pas que la requête SSTP sera comprise. Un 404 depuis la même adresse est tout aussi peu informatif sur le VPN. Seul le journal du client vous dit laquelle des quatre étapes a été atteinte.

Notez quel nom chaque commande a utilisé. Le certificat est choisi selon le nom que vous envoyez, donc une incohérence entre le profil et le test est une incohérence que vous avez introduite. Écrire ce nom à côté du résultat évite la confusion plus tard.

Lisez le succès partiel dans la bonne direction

Un intermédiaire peut autoriser la navigation ordinaire et refuser l’échange ultérieur, c’est pourquoi un proxy qui fonctionne pour les sites web peut encore échouer pour un tunnel. Le même schéma apparaît lorsqu’un certificat est valable pour un nom de navigateur mais pas pour le nom configuré dans le profil : le navigateur est satisfait et le client ne l’est pas, et les deux ont raison sur ce qu’ils ont vérifié.

Gardez la validation du serveur activée pendant ce diagnostic. La désactiver transforme une incohérence de certificat en poignée de main réussie et cache la seule preuve qui aurait expliqué la panne.

Si le même profil fonctionne depuis un autre réseau, la différence dépend du chemin. Cela restreint la recherche aux intermédiaires sans dire lequel, et c’est encore un pas utile. Notez le réseau utilisé, car la comparaison ne vaut rien sans lui.

Testez ensuite l’application, pas seulement la session

Une fois qu’une session existe, vérifiez la route prévue, la résolution de noms et l’autorisation de service depuis le client qui en a besoin. Un tunnel connecté peut encore avoir un transfert manquant de l’autre côté ou une route de retour qui n’a jamais existé, et ces pannes ressemblent exactement à un problème d’application pour la personne qui attend.

Gardez chaque conclusion attachée à l’étape qui l’a produite. Appeler un port ouvert un VPN fonctionnel, c’est ainsi qu’une vérification de certificat de cinq minutes devient une journée de réinstallation de logiciels.

Articles similaires