Délai d’attente SSTP ou erreur de certificat : comment les distinguer

Une connexion SSTP échoue de deux manières qui se ressemblent depuis la chaise de l’utilisateur, et la réparation de chacune se situe sur une couche différente. Un délai d’attente signifie qu’un échange requis ne s’est jamais terminé ; une erreur de certificat signifie que le matériel d’identité est arrivé et a été rejeté. Traiter la seconde comme la première vous envoie vers des pare-feu et des mots de passe qui n’ont jamais été le problème. La preuve qui les distingue se trouve dans le journal du client lui-même, si vous le lisez avant de changer quoi que ce soit.

Deux échecs, deux échanges différents

SSTP transporte un tunnel à l’intérieur d’une session en forme de HTTPS, c’est pourquoi il survit aux réseaux qui n’autorisent que le 443. Le client termine une poignée de main TLS, envoie une requête HTTP avec une méthode propre au protocole, puis le tunnel circule dans ce flux. Un échec à l’une de ces étapes arrête la connexion, et seules les suivantes impliquent des identifiants.

Cet ordre est le diagnostic. Si la poignée de main TLS ne se termine jamais, aucun identifiant n’a été envoyé, donc une réinitialisation du mot de passe ne peut pas aider. Si la poignée de main se termine puis se bloque, l’identité a été acceptée et quelque chose dans le chemin de la requête l’a refusée. Si la poignée de main échoue avec un message de validation, le serveur a répondu et le client n’a pas aimé ce qu’il a entendu. Trois issues, trois couches.

La ligne de journal indique généralement dans laquelle des trois vous êtes, c’est pourquoi il vaut la peine de la capturer avant le premier changement.

Un délai d’attente signifie qu’une étape ne s’est jamais terminée

Commencez par la résolution de noms et l’accessibilité TCP, car un délai d’attente à cet endroit ressemble à un délai d’attente plus tard. Un vérificateur de port qui signale le 443 ouvert prouve qu’un écouteur a accepté une connexion, et rien de plus.

Le suspect suivant est le chemin et non l’hôte. Les proxys et les pare-feu conscients des applications refusent parfois la méthode de requête qu’utilise SSTP, ou abandonnent un flux qui reste ouvert pendant des heures, et les deux comportements ressemblent à un délai d’attente côté client. Une page HTTPS ordinaire servie par le même hôte se charge parfaitement alors que la méthode du tunnel est refusée, c’est pourquoi naviguer vers le point de terminaison prouve si peu. Testez depuis un réseau sans le proxy pour séparer ces deux cas.

Test-NetConnection vpn.example.com -Port 443
netsh http show sslcert
Get-WinEvent -LogName 'Microsoft-Windows-RasSstp/Operational' -MaxEvents 20

Un délai d’attente avant toute réponse du pair ne dit rien du compte, et changer le mot de passe à ce moment-là n’ajoute qu’une variable.

Une erreur de certificat signifie que l’identité a été rejetée

Ici le serveur a bien répondu, donc le réseau fonctionne et la question passe à l’identité. Comparez le nom que le client compose avec les noms que le certificat affirme réellement, puis vérifiez les dates de validité et la chaîne d’émission.

Une AC privée à laquelle le client ne fait pas confiance produit la même classe d’erreur qu’un certificat expiré, et une horloge décalée de plusieurs heures aussi. Composer l’adresse brute crée une nouvelle discordance, car un certificat affirme des noms et non des adresses. Dans un déploiement géré, obtenez la configuration de confiance prévue auprès de son administrateur au lieu d’accepter une racine de remplacement proposée par une page d’erreur. La validation reste active pendant que vous corrigez la cause.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
w32tm /query /status

Gardez l’étape TLS réussie intacte une fois qu’elle passe, car l’annuler plus tard masque quel changement a réellement réparé le tunnel.

Là où les deux se confondent

Les deux échecs se présentent comme une connexion qui ne monte pas, et tous deux surviennent après que l’utilisateur a changé quelque chose sans rapport. C’est cette coïncidence qui rend la mauvaise réparation plausible pendant un moment.

Deux habitudes les séparent. Capturez le journal du client avant de toucher à la configuration, afin que le premier état soit conservé. Changez une couche par tentative, afin que le résultat suivant appartienne à une variable connue. Un vérificateur de port et un navigateur sont des observations partielles plutôt que la séquence complète, et ni l’un ni l’autre ne remplace le rapport du client lui-même. Aucune des deux habitudes ne coûte quoi que ce soit, et toutes deux raccourcissent l’enquête.

La question du certificat et celle de l’accessibilité sont documentées séparément pour une raison.

Retestez avec le vrai client, puis avancez vers l’intérieur

Une fois la correction précise en place, réessayez avec le client SSTP réel et le vrai profil, pas avec un onglet de navigateur.

rasdial "Corp SSTP" /disconnect
rasdial "Corp SSTP" user '*'
Get-VpnConnection -Name "Corp SSTP" | Select-Object ServerAddress, TunnelType, AuthenticationMethod

Si la session se connecte et que les ressources échouent encore, le tunnel n’est plus le suspect : passez au routage, au DNS et à l’accès aux services. C’est une autre enquête avec d’autres preuves. Conserver les étapes TLS et d’authentification qui fonctionnent l’empêche de devenir une répétition de la première. Écrivez dans le ticket l’étape qui a échoué, sinon la personne suivante repartira du haut.