SSTP 先认证服务器，再认证用户

一个 SSTP 客户端可以完成 TLS，却在一秒后拒绝该用户。这个顺序不是缺陷，而是协议栈的设计：先传输安全，再用户认证。由于两个阶段失败时给出的消息不同，修复方式也不同。读懂错误来自哪个阶段，就是诊断的大部分工作。

受信任的证书证明的是端点；它对账户只字不提。

TLS 握手确立了哪些内容

客户端会拿服务器出示的证书去对照自己的信任存储、所请求的主机名、有效期窗口，以及平台施加的任何附加策略。这保护了通往预期端点的连接。但它不能证明某个账户已启用、未过期或获准使用远程访问。这些是之后由另一个组件提出的独立问题。

正因如此，为了到达登录提示而移除证书检查是错误的修复。你会在一个无法验证的连接上看到登录提示。证书错误属于主机名、时钟、证书链或信任配置的问题。

SSTP 和 PPP 又叠加了什么

SSTP 运行在 HTTPS 之上，内部承载 PPP，并在连接周围有自己的控制交换。随后 PPP 执行其链路和认证阶段，认证方式取决于服务器策略和客户端能力。PAP、CHAP、MS-CHAPv2 和 EAP 都是 PPP 的认证选项，性质差异很大。VPN 的用户检查就是那个 PPP 阶段，而不是其下的 TLS 层。

因此，用户被拒绝可能意味着凭据、账户限制或方法不匹配。

服务器侧的原因远比把配置文件里的每个密钥都重置一遍有用。账户被禁用的事件和方法协商失败在客户端看起来相似，在服务器上却毫无共同之处。

把错误对应到阶段

检查连接是否到达 TLS，然后是 SSTP 的 HTTP 交换，然后是 PPP 阶段。让多次重试之间的日志时间戳保持对齐，以免把较早的失败误当成较晚的成功。否则，在一个窗口里记录两次尝试的客户端会看起来像是在最后到达的阶段失败。请读第一条相关错误，而不是最后一行。

同样的对齐在服务器侧也很重要，因为认证记录和传输日志常常是时钟不同的两个文件。两分钟的偏差就足以让显而易见的原因看起来不可能。

登录之后，授权仍然是独立的

登录成功并不授予所有私有资源。路由决定哪些可达，DNS 决定哪些能解析，而每项服务仍然施加自己的权限。显示为已连接的会话说的是隧道，而不是文件共享。当用户能连接却到不了某台主机时，隧道阶段早已结束。

这正是握手中展示的同一套分层，只是高了一层。

把账户恢复留在运营商支持的流程里，而不是为了回应用户的明确拒绝去改传输设置。为了修好一个被禁用的账户而改动传输，是那种在账户因无关原因被重新启用时看起来奏效的修复。