SSTP est du PPP sur HTTPS, pas une page web sur le port 443
TLS et une requête HTTP ouvrent le canal, puis les messages de contrôle et PPP font le reste. Parcourez les étapes et voyez pourquoi un test dans le navigateur prouve si peu.
SSTP transporte PPP dans une connexion HTTPS, c’est pourquoi il ressemble à du trafic web pour tout ce qui se trouve au milieu. TLS et HTTP établissent le canal extérieur, puis les messages de contrôle SSTP préparent le tunnel et PPP fournit le comportement de la session. Un navigateur qui charge une page à la même adresse n’a accompli qu’une partie de la première étape. Le considérer comme un test VPN, c’est la façon dont un proxy qui fonctionne se voit reprocher une incompatibilité de protocole.
Parcourez les quatre étapes dans l’ordre, et la panne que vous voyez tombera dans l’une d’elles.
Étape 1 : TCP et TLS
Le client ouvre une connexion TCP vers le port 443 et effectue une poignée de main TLS. La chaîne de certificats doit correspondre au nom d’hôte avec lequel le client a été configuré. Une divergence de nom ici produit une panne avant qu’aucun message SSTP ne soit échangé, et la spécification SSTP suppose que ce canal HTTPS extérieur existe déjà. Rien dans les étapes suivantes ne peut compenser une panne de confiance ici.
Un serveur web ordinaire peut parfaitement terminer cette étape et échouer à la suivante. Le succès de TLS est une preuve sur le certificat, pas sur le protocole derrière lui.
Étape 2 : la requête HTTPS
SSTP formule sa requête avec une méthode spécifique, SSTP_DUPLEX_POST, et garde l’échange ouvert au lieu de renvoyer un document. Un serveur ou un proxy configuré pour des requêtes de page ordinaires peut accepter la connexion puis refuser la méthode. Ce refus est le problème de compatibilité que les gens décrivent habituellement comme un port 443 bloqué.
Lisez le code de réponse et la méthode dans le journal du serveur. Un refus à cette étape est un problème différent d’un délai d’attente TCP, et les deux mènent à des corrections différentes.
Étape 3 : les messages de contrôle
Une fois la requête acceptée, SSTP échange des messages de contrôle qui négocient et préparent le tunnel. Ce sont des messages de protocole à l’intérieur du corps HTTPS, et non des requêtes HTTP, donc un proxy qui inspecte et réécrit les corps peut les casser tout en laissant les requêtes de page intactes.
C’est ici qu’un équipement d’inspection approfondie gagne sa réputation. Si les pages se chargent et que le VPN échoue, vérifiez si le corps est modifié plutôt que si le port est ouvert.
Étape 4 : PPP prend le relais
PPP fournit ensuite le comportement de la session : négociation de la liaison, authentification et la configuration de la couche réseau qui suit. L’authentification PPP est distincte de la vérification TLS que le client a déjà passée. Un certificat de serveur que le client accepte ne dit rien sur la validité des identifiants de l’utilisateur ni sur l’autorisation du compte.
Un certificat accepté et une connexion refusée ne sont pas contradictoires. Ce sont des étapes successives aux résultats indépendants.
L’authentification a plusieurs rôles
Le client valide l’identité du serveur TLS par rapport à son magasin de confiance et au nom configuré. PPP authentifie ensuite l’utilisateur ou la machine, selon le déploiement. Le serveur peut ajouter sa propre politique sur qui peut se connecter et à quoi il peut accéder. Gardez le nom d’hôte cohérent avec l’identité du certificat, car le remplacer par une adresse brute transforme une configuration qui fonctionne en échec de vérification du nom.
Notez quelle étape a signalé la panne. Certificat, méthode, message de contrôle, authentification PPP, puis routes : cinq endroits, cinq réparations.
Ce qu’un test dans le navigateur peut et ne peut pas montrer
Charger une page à l’adresse prouve la résolution DNS, l’accessibilité TCP et que quelque chose écoute et parle HTTP. Cela ne prouve pas que la méthode est acceptée, que l’échange de contrôle survit ou que l’authentification PPP est configurée. Utilisez un client qui implémente SSTP plutôt que de convertir un autre profil en changeant le port.
Une fois la session établie, les routes, le DNS et le transfert côté serveur décident encore de ce que l’utilisateur peut atteindre. Le tunnel est un chemin, pas une autorisation.