Linux 上的 SSTP 登录前就失败？检查运行时组件

你装了 SSTP 插件，网络编辑器里出现了单选按钮，你填好网关和用户名，配置文件却在索要密码之前就以一个笼统的错误失败。这个流程本身毫不奇怪，也不能证明隧道软件已经安装。SSTP 连接是由分别发布的部件拼起来的：NetworkManager 能启动的 VPN 插件、负责 TLS 与 PPP 会话的 SSTP 客户端程序、它下面的 PPP 守护进程，以及连接有权读取的秘密存储。

菜单项加了什么，没加什么

插件提供的是一段服务描述，告诉 NetworkManager 如何启动它；在多数发行版里还提供一个小编辑器来绘制表单。菜单项的全部作用范围就这些。客户端程序来自另一个源码包，插件自己的 README 也直说了这种分工：它是插件，不是客户端。

接着客户端需要 PPP，因为 SSTP 在 TLS 连接里承载 PPP 会话。没有 pppd，隧道可以完成 TLS 握手，却仍会在第一个控制帧上死掉，看起来像凭据问题，其实不是。在 Debian 和 Ubuntu 上，这些部件分别叫 network-manager-sstp、sstp-client 和 ppp，只装第一个正是表单能接受每个字段、连接却始终不完成的最常见原因。

桌面选择又增加一层拆分。Plasma 通过 plasma-nm 编辑配置文件，而 plasma-nm 需要自己的 SSTP 组件，并读取同一份服务描述。所以一个没有 SSTP 条目的编辑器和一条能正常创建配置文件的 CLI，说明缺的是编辑器的另一半，而不是运行时坏了。

先读第一个失败的阶段，再考虑重装任何东西

失败的 SSTP 尝试会按固定顺序经过若干阶段，失败的阶段会告诉你该看哪个组件。

启动插件是第一阶段，这里的失败给出的是关于 VPN 服务的消息，而不是关于服务器的。接下来是到 443 端口的 TCP 连接；这里的拒绝或超时是可达性问题，不是 TLS 问题。然后是 TLS 握手与服务器身份检查，接着是 PPP 协商与账户认证，最后是地址分配和路由。在激活一次配置文件时观察 journalctl -f -u NetworkManager，读第一条具体的行，而不是最后一条笼统的行。

这个顺序解释了一种常见的误读。证书报错出现在任何凭据发出之前，所以改密码帮不上忙；PPP 认证拒绝出现在握手成功之后，所以换证书同样帮不上忙。留住第一个错误和它所在的阶段，你得到的是诊断，而不是症状。

证书信任和账户登录是两道独立的关口

握手用你配置的颁发者和名称验证服务器正是你要连的那台。只有在这之后，PPP 层才会把用户名和密码交给网关的认证方式。也就是说两个独立检查按固定顺序评估，各有各的设置。密码框里输入的任何一个字符都影响不了第一个检查。

信任了错误颁发者的配置文件在第一个关口以身份错误失败。信任正确但存了旧密码的配置文件在第二个关口以认证拒绝失败。两者看起来都像连不上的 VPN，而任何一方的补救都治不了另一方。

向管理网关的人索取预期的颁发者和服务器名称，而不是去猜编辑器的默认值，并记下他们要求的认证方式。如果组织需要插件无法表达的认证方式，诚实的答案是换一个能做这件事的获批客户端，而不是关掉校验让错误消失。

让同一个归属者持有配置文件与秘密

配置文件建好之后，用 NetworkManager 激活它，并让这个管理器拥有由此产生的路由和解析器变更。在 NetworkManager 已经掌管连接时再启动第二个独立的 SSTP 客户端，你会得到两套路由、两套 DNS 配置，以及一个没有单一事实来源的调试过程。

秘密也有归属。标记为系统级使用的连接与仅限用户会话的连接，存储凭据的方式不同；在密钥文件里手工创建的配置文件，那个指望交互式提供密码的秘密代理可能读不到。在重新输入一个从来不是问题的密码之前，先确认配置文件期待的是哪种上下文。用 nmcli 从终端激活同一个配置文件是最快的测试，因为一个从不出现的提示说明代理本来就没有东西可提供。

分别检查隧道、路由和解析器

“已连接”指示只说明链路起来了。请逐个检查你真正需要的目标、承载它的路由，以及正在使用的解析器；其中任何一个出错时，另外两个都可能正常。

对于失败的尝试，记录每个组件的版本和脱敏后的错误文本。分享这些，而不是完整配置文件，因为配置文件可能含有预共享秘密和你保存的凭据。

最后，断开再重连，然后重启一次。如果配置文件只在第一次尝试时能用，问题就在秘密处理或路由归属上，而这两样现在修比工作日中途修更便宜。