SSTP derrière un proxy qui inspecte TLS : où la session casse

Votre navigateur charge l’intranet de l’entreprise, le certificat du proxy est approuvé, et pourtant le client SSTP décroche près de la fin de la connexion. Ce schéma pointe la différence entre une requête web et une session tunnelisée, pas un mot de passe erroné. Parcourez la connexion depuis TCP vers le haut et notez la première étape qui échoue. L’étape, et non le code d’erreur, vous dit si le proxy est la cause.

Commencez là où le client s’arrête

Le client traverse une séquence fixe : connexion TCP au port 443, poignée de main TLS, validation du certificat, l’échange HTTP de SSTP, la négociation et l’authentification PPP, puis la configuration IP. Une défaillance à chaque étape laisse une signature différente, et les confondre vous mène à la mauvaise page de configuration.

Une défaillance TCP est un délai d’attente ou une réinitialisation avant qu’un seul octet TLS n’apparaisse. Une défaillance TLS est une alerte ou un délai de poignée de main. Une défaillance de certificat produit un avertissement sur la chaîne ou le nom. Une défaillance HTTP arrive après une poignée de main réussie, souvent sous forme de code de statut ou de fermeture immédiate. Une défaillance PPP arrive après que le tunnel est techniquement établi, ce qui explique pourquoi elle ressemble à un problème d’authentification.

Lisez le journal du client pour la dernière étape réussie plutôt que la première ligne d’erreur. La ligne d’erreur rapporte généralement la conséquence, tandis que la frontière d’étape nomme le composant qui a refusé.

Ce que SSTP demande au réseau de transporter

SSTP passe par TLS sur TCP 443 puis envoie une requête HTTP appelée SSTP_DUPLEX_POST, définie dans la spécification SSTP, vers un chemin de la forme /sra_{GUID}/. La requête déclare une longueur de contenu pratiquement illimitée et garde le flux ouvert dans les deux sens pendant toute la durée de la session. Les trames PPP circulent à l’intérieur de ce flux.

C’est pourquoi un proxy qui gère la navigation ordinaire peut quand même échouer. Un GET ou un POST à corps fini peut être mis en tampon, inspecté et transmis ; un flux duplex dont le corps ne se termine jamais ne le peut pas. Un proxy qui attend la fin du corps attend indéfiniment, et le client finit par expirer.

Le filtrage des méthodes et l’authentification ajoutent leurs propres modes de défaillance. Si le proxy demande des identifiants pour la requête, le client VPN peut ne pas répondre alors que le navigateur le ferait. S’il supprime ou réécrit la méthode, la passerelle rejette la requête avant que PPP ne commence.

Pourquoi l’inspection change l’identité

Un proxy qui inspecte TLS termine la connexion TLS du client et en ouvre une séparée vers la passerelle. Le client valide donc le certificat du proxy, pas celui de la passerelle, et la passerelle voit le proxy comme son homologue. Quand l’organisation distribue sa propre racine, le navigateur et le client VPN peuvent tous deux accepter cette chaîne, si bien que la poignée de main réussit et que le problème passe à l’étape suivante.

Une validation réussie ne signifie pas que le proxy peut porter la session. Il doit encore relayer un POST bidirectionnel illimité sans mise en tampon et garder les deux connexions vivantes pendant des heures. Beaucoup de produits d’inspection sont conçus pour le trafic requête-réponse et traitent ce cas mal ou pas du tout.

C’est aussi pourquoi ajouter une racine inconnue ou désactiver la vérification est la mauvaise réparation. Cela change le certificat que le client accepte ; cela ne fait rien au traitement du flux qui a réellement cassé la session.

Identifiez l’émetteur avant de changer les réglages

Demandez au point de terminaison quel certificat il présente et qui l’a signé. Les commandes ci-dessous montrent la chaîne et l’émetteur sans démarrer de session VPN :

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

Si l’émetteur est une AC publique, la connexion n’est probablement pas interceptée pour cet hôte et la défaillance est ailleurs. Si l’émetteur est l’AC de l’organisation elle-même, l’inspection est active et la passerelle est atteinte via un proxy. Comparez l’empreinte à celle que l’équipe réseau attend avant de conclure à partir du seul nom.

Un test de navigateur vers le même hôte prouve seulement que le proxy accepte un GET. Il ne dit rien de la méthode SSTP, de l’URI de la requête ni de la durée de vie du corps, alors ne prenez pas une page intranet qui fonctionne pour la preuve que le chemin du tunnel est pris en charge.

Choisissez le chemin pris en charge

Posez au propriétaire du réseau une question concrète : le proxy autorise-t-il un POST duplex non tamponné vers cette passerelle sur le port 443 ? Un oui mène à une exception dans le proxy ou à un contournement documenté pour l’hôte VPN. Un non signifie que le chemin inspecté ne peut pas porter SSTP, et la correction prise en charge est un autre chemin ou protocole, pas un ajustement du client.

Les options comprennent généralement une sortie non inspectée pour la passerelle VPN, une conception en tunnel divisé qui n’envoie que le trafic d’entreprise via le proxy, ou un protocole alternatif que l’organisation prend en charge sur un autre port. Chacune relève de la conception du réseau, et chacune devrait être testée avec le même appareil et le même profil afin que la comparaison isole le chemin.

Documentez le résultat : émetteur, étape défaillante, règle du proxy et chemin choisi. La personne suivante qui voit le même blocage à 98 pour cent pourra vérifier un seul fait au lieu de répéter tout le parcours.