PPTP 提示密码错误：先修哪一处

坚称密码错误的 PPTP 配置，其实在说一件比字面更窄的事。密钥的校验发生在一条从能力协商开始的链条最末端，所以链条上更早任何不匹配都会表现为认证失败。因此重置密码、重新输入或重建配置都不会改变任何东西。先读协商，再根据你能控制多少路径来选择修法。

为什么密钥根本没被校验

PPP 认证是协商出来的：服务器提出方法，客户端按自身能力回应，双方在任何凭据交换前先定下一种。当服务器只提供 EAP-PEAP 而客户端 pppd 未实现它时，会话在提议阶段就结束了。服务器记录认证失败，是因为失败就发生在这一阶段，而不是因为密码被比对过并判为不合格。

所以密码错误和方法不匹配的报错完全相同。只有日志能区分两者，而且只有客户端被允许输出详细信息时才区分得出。

读协商，而不是最后一条报错

在前台开启调试运行连接，从上往下读认证行。日志会写明提议的方法、接受的方法，以及交换停在哪里。服务器期待 PEAP 而配置始终停在 CHAP 或 MSCHAPv2，就是方法问题，不是凭据问题。日志最后一行是客户端放弃的位置，不是原因所在。

sudo pppd call provider debug nodetach

把这段输出保存下来。它也是网络负责人修改服务器策略前需要的证据，并且能回答密码究竟有没有参与其中。

第二个原因藏在密钥文件里

如果日志显示方法一致，就看存密钥的文件。密码字段里写进了换行或尾随空格，这些字符会作为密码的一部分发出去，服务器比对到的字符串与你输入的不同。文件在编辑器里看起来是对的，这正是它躲过那么多次重试的原因。

sudo cat -A /etc/ppp/chap-secrets

那段输出里每行末尾由美元符号标出。密码字段里该符号之前还有内容，或字段之间夹着多余空格，都要按工具文档中的引号规则重写。

按服务器归谁所有来选修法

如果服务器是你的，为该账号允许 MSCHAPv2是改动最小的办法，并且应当记下你是有意接受了更弱的方法。如果归别人所有，诚实的修法是换用实现了 EAP-PEAP 的客户端；给 pppd 打补丁会把不兼容变成你的维护负担。如果协议选择还没定，PPTP 是设计中最弱的一环，迁移通常比维持一个打过补丁的客户端更便宜。把这个决定写在配置旁边，免得下一个人再翻出来。

无论走哪条路，之后都换到另一台机器、另一个网络测试。保存的配置可能继续提议旧方法，让修好的服务器看起来是坏的。随后再去掉调试设置，因为在共用工作站上，详细的 PPP 日志会记录下超出你预期的内容。