SSTP échoue là où le HTTPS du navigateur réussit : pourquoi

Le navigateur ouvre le nom d'hôte du VPN en HTTPS sans se plaindre, et le client SSTP refuse toujours de se connecter. Rien dans ce couple n'est contradictoire. SSTP utilise TLS comme transport externe, puis exécute sa propre requête et sa charge PPP à l'intérieur de cette connexion, si bien qu'un chargement de page réussi ne prouve qu'une chose étroite : l'hôte répond à un GET sur le port 443. Le client pose une autre question, et le serveur peut y répondre mal.

La page se charge et le tunnel non

Les gens se tournent vers le test du navigateur parce qu'il est rapide, puis prennent le résultat pour la preuve que le serveur est joignable et configuré. C'est une preuve concernant un GET vers le chemin qu'a ouvert la barre d'adresse, rien de plus. La conversation VPN commence après la même poignée de main TLS, mais envoie une méthode et un chemin qu'une page web n'utilise jamais. Une réponse 200 pour le navigateur ne dit donc rien sur l'existence du point de terminaison SSTP.

Séparez les deux observations et la recherche raccourcit. Le transport et la chaîne de certificats fonctionnent, et quelque chose dans l'échange de protocole au-dessus ne fonctionne pas. C'est une enquête différente de celle d'un port cassé ou d'un certificat expiré, et elle exige des preuves différentes.

Ce que le client SSTP envoie réellement

Le client envoie une requête HTTP avec la méthode SSTP_DUPLEX_POST vers le chemin /sra_{GUID}/, puis maintient le corps de la connexion ouvert comme un flux bidirectionnel transportant des trames PPP. Un serveur conforme répond HTTP/1.1 200 et cesse de se comporter comme un serveur web. Tout autre chose est une signature : 405 ou 404 signifie que le point de terminaison est absent, 301 ou 302 signifie que quelque chose redirige la requête, et un FIN immédiat signifie qu'un proxy ou un serveur a fermé le flux.

C'est pourquoi la cible doit être un serveur SSTP et non un serveur web auquel on a vissé un certificat TLS. La méthode, le chemin et le corps durable sont des exigences du protocole, donc un proxy inverse ne peut pas les ajouter par la seule configuration. Un proxy qui relaie parfaitement du HTTPS ordinaire peut encore refuser une méthode qu'il ne reconnaît pas.

Où un proxy ou un serveur web casse le flux

Un intermédiaire inspecte la ligne de requête HTTP avant de relayer quoi que ce soit, et une méthode personnalisée avec un chemin inhabituel peut échouer à ses règles. Certains appareils servent une page normale tout en rejetant ou en interrompant le tunnel, si bien que le client signale une connexion qui démarre puis meurt plutôt qu'un refus net. D'autres acceptent la requête, puis appliquent un délai d'expiration de corps ou d'inactivité que les keepalives PPP ne survivent pas. Les deux se ressemblent du côté du client, c'est pourquoi l'étape qui a échoué compte plus que le texte de l'erreur.

Partager le port 443 entre un site web et SSTP est un choix de routage, pas la promesse que chaque saut traite les deux conversations de la même manière. Si un répartiteur de charge, un pare-feu ou un terminateur TLS se trouve sur le chemin, ajoutez-le à la liste des suspects avant de toucher à la configuration du VPN.

Testez les étapes séparément

Exécutez les contrôles dans l'ordre et arrêtez-vous à la première défaillance, car chaque étape écarte une couche différente. La sonde TLS ci-dessous sépare l'identité du certificat de tout ce que fait SSTP. Remplacez le nom d'hôte par votre point de terminaison et lisez le sujet et la chaîne qu'elle imprime.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com

Ensuite, rattachez les preuves restantes aux étapes plutôt que de deviner à partir de l'erreur du client. Le tableau ci-dessous est la liste de contrôle à citer dans le ticket, avec la signature qui sépare une défaillance de la suivante.

Consignez dans le ticket la dernière étape qui a réussi au lieu d'écrire « impossible de se connecter ». La spécification MS-SSTP documente la requête et l'échange PPP qui suivent la poignée de main TLS, et c'est la référence pour expliquer pourquoi un test dans le navigateur ne peut remplacer ni l'une ni l'autre.

L'identité d'abord, puis PPP

L'identité TLS et l'authentification PPP sont séquentielles, non alternatives, et les confondre envoie les gens vers le mauvais réglage du serveur. Le client valide d'abord le certificat du serveur et son usage prévu, puis PPP négocie son propre état et authentifie l'utilisateur avec une méthode de défi-réponse ou EAP. Un problème de certificat produit une erreur différente d'un mot de passe rejeté, et aucune des deux erreurs ne décrit l'étape que couvre l'autre.

Remplacer le nom d'hôte par une adresse, ou cliquer au-delà de l'avertissement de certificat, supprime le contrôle qui aurait identifié l'étape défaillante au lieu de la corriger. Gardez l'avertissement et lisez-le. Ne réinitialisez pas non plus un mot de passe PPP quand l'échange HTTP n'a jamais atteint le comportement SSTP, car l'identifiant n'a jamais été demandé.