找不到 pppd 二进制文件：修运行时，别修认证

没有任何东西到达网关，因为客户端先找不到它需要的二进制文件。报错信息点名的是运行时辅助程序，而人的自然反应是以为远端拒绝了什么。远端并没有拒绝。基于 PPP 的集成需要本地机器上有那个辅助程序，而它缺失了、不可读，或者不在调用方查找的位置。

菜单和守护进程是两回事

桌面编辑器能保存配置文件，即便真正负责建立连接的辅助程序并不存在，因为 保存只校验字段，不校验能力。两个组件由不同的软件包提供，失败的时刻也不同。配置文件保存得干干净净，而连接立刻失败，这两件事完全一致。

反过来的错误同样常见：磁盘某处有一个可执行文件，并不能证明所选集成找到的是受支持的那一个。主目录里的副本可能让 shell 满意，却仍然对服务不可见。

读软件包，而不是读文件

在动手之前，先检查已安装软件包的状态、它声明的依赖以及预期的文件清单。发行版的打包对此有明确记录，Debian 的 NetworkManager PPTP 软件包 就是一个有用的例子，因为它分别依赖 PPP 守护进程包和 PPTP 客户端。这是遗留集成，不是今天部署 PPTP 的建议。它说明了辅助程序是作为独立依赖进来的，而不是打包在客户端里。

分清三种失败形态：安装失败的软件包、不提供候选版本的仓库，以及包管理器所有权之外手工安装的二进制文件。它们需要不同的修复方式，只有第一种能靠重装同一个包解决。

在 shell 里检查可执行文件，只能说明那个 shell 的搜索路径，别的什么也说明不了。管理器的辅助程序可能用另一条路径、另一个环境，或一个显式配置的可执行文件位置。

dpkg -s network-manager-pptp | grep -E "Status|Depends"
dpkg -L ppp | grep -E "bin/pppd$"
command -v pppd; ls -l /usr/sbin/pppd

修运行时，别弄坏别的

当运行时确实不完整时，使用发行版经过审核的软件包操作，并先读清楚它会改动什么。PPP 被多个接入网络集成共用，删除或重装可能连带拿走正常工作的使用者。为了修一个坏掉的而清掉所有相关软件包，正是一台笔记本丢掉两个可用连接的方式。

装另一个 VPN 客户端同样不是修复。它制造了新的兼容性要求，却让原来的配置文件依旧没有解释。

如果组织已经决定协议本身应当淘汰，那是有负责人的迁移决策。它不是排障步骤，也不该在连接失败的那一刻做出。

把下一个报错当成新阶段

辅助程序一旦启动，就要预期下一次失败是另一回事。PPP 链路协商、用户认证、地址分配、路由和名称解析都可能各自失败，每一种都有自己的证据。

不要用撤销依赖修复、或在配置文件里打开所有旧的认证与压缩选项来回应之后的拒绝。那会把一个可诊断的问题变成几个相互影响的问题。一次只改一个设置，并记录它改动了什么。

记录软件包版本和你看到的准确报错。说出缺失的二进制文件以及本应提供它的软件包的报告，才具有一般性 VPN 抱怨所没有的可操作性。