MSCHAPv2 不是 VPN 协议：先问清楚隧道

用户名和密码在某种承载里传输，而 MSCHAPv2 只说明传输所用的方法。选择客户端配置之前，先问清楚是哪条隧道在承载它，因为同一串账号会出现在彼此不共享一行代码的方案里。交给你的每份配置都同时编码了两个决定，哪怕说明书只印出了其中一个。下面的顺序，是运维不靠猜就能回答的部分，也是你不必抓包就能核对的部分。

认证跑在隧道之内

VPN 做出两个看起来像一个的决定：双方如何建立受保护的通道，以及人如何在其中证明身份。后者被印在说明书上，因为那是人手输进去的东西。前者决定了客户端到底能不能用，而人们偏偏跳过它。请运维先说出承载，再说出方法，顺序就是这样。两条连接可以要求同一个账号名和同一个密码，却在登录框之下不共享任何实现。

正因如此，从同事那台能用的手机抄来的设置，在你这里可能失败，哪怕服务端两个凭据都接受。凭据从来不是差别所在；包住它的那份配置才是。 双方都对，却什么都连不上 通常就是这个混淆，而承载一旦被点名，它立刻就散了。

同一方法出现的三个地方

在 PPP 里，认证这一步要等链路建立之后再发生，而 RFC 2759 把 MS-CHAPv2 定义为该步骤，所以这个方法会出现在 L2TP 以及更早的 PPTP 部署里。隧道先终结，PPP 协商发生在它内部，于是一个失败的 PPP 阶段可能让隧道在服务端日志里看起来已经建立。在断定凭据被拒之前，请把这两个阶段分开读。所以，为 L2TP 配好的客户端可能完全正确，却仍然是只讲 IKEv2 的网关的错误客户端。

IKEv2 则把 EAP-MSCHAPv2 放进密钥交换里，于是同一份凭据在另一个时刻失败，表现为认证错误而不是会话错误。Android 平台的 IKEv2 配置就是日常例子，它要的是服务端证书或标识，而不是 PPP 选项。两种方案里账号名一模一样，所以它没法告诉你手里是哪一种。只有运维给出的受支持协议清单能决定这件事。

基于 TLS 的 VPN 又添了第三种方案，它有自己的用户名和密码字段，交换过程中任何地方都没有 MS-CHAPv2。因此看见密码框并不能证明背后的协议是什么，因为这个表单是照着熟悉的样子做的。要依据服务端文档确认协议，而不是依据客户端窗口的形状。

你真正需要的答案

把请求当成清单发出去，因为清单很难只答一半。要问隧道协议、隧道内部的方法，以及运维在你所用平台上支持的客户端。然后再问网关身份与信任设置、账号格式，以及连接建立之后应该能访问什么。

前三个决定你能不能拿到一份能用的配置。后三个决定这份配置能不能满足工作所需。把答复附在工单上，因为下一个人会问同样六个问题。凡是缺答案的地方，把空白当成运维还没做的决定，而不是你可以自行推断的东西。

不要放松网关校验

服务端也要向客户端证明自己的身份，而这半个交换不是装饰。为了让一个倔强的配置连上而关掉证书校验，等于接受任何有应答的端点，包括没人打算抵达的那一个。它还把真正的不匹配藏了起来，而不是解决掉，于是故障被推到更晚、更不显眼的时刻。需要关掉校验的配置，就是在指向它无法验证的东西。

不匹配通常出在名字上，因为为某一个主机名签发的证书，在配置拨号到地址时会失败。请拨名字，而不是关掉校验。私有证书颁发机构会失败，是因为设备从没拿到根证书，修法是通过批准的渠道分发那个根。受管环境期望运维提供身份与信任锚，而配置引用这两者。字段缺失时，去要那份材料，而不是放弃校验。

对齐配置，然后逐段证明

承载一旦明确，就照那份客户端的文档流程走，只填它要求的字段。因为存在就填的额外字段依旧是错误的值，而且比必填项失败得更晚。第一次连上之后，把配置原样保存，好让之后的改动有东西可比。

然后分段验证：隧道建立、用户通过认证、分配到的地址与路由出现、一项被允许的服务有应答。每一段都会在服务端留下自己的日志行，按顺序读它们，就能把含糊的抱怨变成具体的发现。如果平台已不再支持运维描述的那种方案，那是迁移的话题，而不是在设备上把每个旧选项都打开的理由。承载、方法、配置是三个各自独立的答案，能用的连接里这三者彼此一致。