Comment vérifier qu'un client VPN prend vraiment en charge SSTP

Qualifier un produit de client VPN ne dit rien sur sa capacité à parler SSTP, et le port 443 dans l'adresse en prouve encore moins. SSTP fait tourner TLS sur TCP 443, puis un échange de contrôle SSTP, puis PPP pour le lien lui-même, avec la validation du certificat et une méthode d'authentification PPP par-dessus. Un client ne prend en charge le protocole que lorsque l'implémentation nommée, dans la version installée, franchit chacune de ces couches selon les exigences de votre serveur. Déroulez les vérifications ci-dessous dans l'ordre et arrêtez-vous à la première qui échoue, car c'est celle qui vaut la peine d'être résolue.

Faites concorder l'implémentation, la version et la plateforme

Commencez par la plateforme, l'application et la version installée, car un même nom d'éditeur peut recouvrir deux implémentations totalement différentes. Les types de VPN intégrés et les clients tiers ne sont pas la même chose, et un greffon peut afficher une étiquette d'adaptateur qui ne décrit pas le protocole en dessous. La documentation de la version courante ne décrit pas la version qui tourne sur la machine devant vous. Lisez la page propre à la version, puis comparez-la à ce que le client rapporte de lui-même.

Sous Windows, le type de tunnel vient de la plateforme et non de l'interface graphique, alors interrogez la plateforme. Get-VpnConnection -Name 'Work' | Select-Object TunnelType, ServerAddress affiche Sstp lorsque le client natif tentera le protocole, et la référence des types de connexion le classe parmi les types de tunnel intégrés. Sous Linux, il n'existe aucun client SSTP natif, la question devient donc de savoir si une implémentation séparée comme sstpc du paquet sstp-client est installée et à jour.

Lisez le format du profil avant l'étiquette

Les profils ne sont pas interchangeables, et le fichier que l'on vous a remis tranche généralement la question plus vite que n'importe quelle liste de fonctions. Les directives OpenVPN, les clés WireGuard et les paramètres de connexion SSTP décrivent trois protocoles sans rapport, et aucune boîte d'importation ne transforme l'un en l'autre. Partager le port TCP 443 ne traduit rien, car SSTP, OpenVPN sur TLS et un service HTTPS ordinaire peuvent occuper le même port sans rien avoir en commun au-dessus.

Si le fichier est un .ovpn ou une configuration WireGuard, la réponse est déjà claire : on ne demande pas à ce client de parler SSTP. L'importer dans un client qui ne fait que SSTP échoue à l'étape du profil, bien avant le début de toute négociation de protocole.

Ce que TLS ne prouve pas sur le déploiement

Une poignée de main TLS aboutie prouve que le serveur possède un certificat, et ne prouve rien sur le fait que votre client fasse confiance à la chaîne émettrice ou que le nom qu'elle contient corresponde. La validation doit réussir contre le serveur prévu, y compris toute autorité de certification privée exploitée par l'organisation, et un client qui propose d'ignorer les erreurs de certificat a supprimé le contrôle au lieu de gagner la prise en charge du protocole. La validation de chaîne et la correspondance du nom sont deux tests distincts, et une pile qui réussit l'un peut échouer à l'autre. Les deux relèvent des critères d'acceptation, pas de l'annexe de dépannage.

Confirmez ensuite la méthode d'authentification PPP, car un déploiement en EAP-TLS exige un client capable de présenter un certificat à l'intérieur de PPP, tandis qu'une méthode par mot de passe exige la prise en charge de cet échange. Une adresse de serveur et un mot de passe ne décrivent pas l'exigence réelle de l'organisation, surtout lorsqu'un second facteur ou un contrôle d'appareil se trouve devant. Demandez quelle méthode le serveur impose avant de supposer que le client peut y répondre.

Suivez la session à travers quatre étapes

Regardez la connexion franchir quatre frontières : TCP et TLS vers le serveur, l'échange de contrôle SSTP, la négociation PPP, puis la ressource dont vous avez réellement besoin. Un journal qui s'arrête après TLS décrit une panne différente de celui qui s'arrête au milieu de PPP, et les deux mènent à des responsables différents. Le chargement de la page web de l'hôte par un navigateur prouve seulement que quelque chose a répondu sur 443, ce qui est le faux positif le plus courant dans ce domaine. Si cette page se charge alors que le client échoue encore, le problème se situe au-dessus de TLS et le serveur web n'est pas le suspect.

Terminez par une vraie ressource privée et une résolution de nom, car une session qui s'établit sans rien transporter ressemble à s'y méprendre à une session fonctionnelle dans la plupart des fenêtres d'état. Une seule requête réussie vers la ressource dont vous avez besoin tranche une question que l'icône ne peut pas.

Quand la prise en charge manque, changez de plan

Si le client ne peut pas parler SSTP, procurez-vous une alternative approuvée ou demandez au propriétaire du serveur un protocole que les deux extrémités prennent en charge. Supprimer les options inconnues jusqu'à ce qu'une importation réussisse produit un profil qui ne se connecte à rien, ce qui est un chemin plus lent vers la même impasse. Un installeur d'origine inconnue qui annonce une compatibilité universelle ajoute un chemin de confiance non approuvé sur la machine et remplace souvent le client de la plateforme par quelque chose que l'organisation ne peut pas mettre à jour. Aucune des deux manœuvres n'est un correctif, et toutes deux sont plus difficiles à défaire que le problème initial.

Traitez la question de la compatibilité séparément de la performance et du choix du point de terminaison, car un serveur proche ne sert à rien quand le client ne peut pas parler son protocole. Le réglage de la latence ne répare pas une étape qui ne se termine jamais.