PPP 的 CHAP 认证是网络实验里绕不开的一道坎很多人第一次在模拟器里配的时候两边一敲ppp authentication-mode chap链路直接起不来然后就开始抓瞎。我自己当年也是这么过来的明明 PAP 配一次就通换成 CHAP 就各种报错后来把报文一个个拆开看才彻底搞明白。这篇内容就围绕PPP 点对点协议中的 CHAP 认证展开把原理、配置命令、排错思路一次讲透适合刚接触广域网协议的网络方向学习者、准备实验考试的备考人员以及需要在模拟环境里复现认证过程的从业者参考。看完你至少能做到三件事说清楚 CHAP 三次握手的每一步在干什么、独立写出两端认证的完整配置、遇到认证失败时知道从哪几个方向去查。下面全部基于常见模拟器环境下的通用实践来写命令以主流网络设备厂商的通用语法为准具体平台可能有细微差异但思路是通的。1. 先搞清楚 CHAP 到底在解决什么问题1.1 PPP 链路建立的四阶段与认证的位置要理解 CHAP得先知道它在 PPP 整个流程里站在哪个位置。PPP 链路从物理层起来到能传数据中间要经过几个明确的阶段这个顺序不能乱乱了就通不了。第一个阶段是链路建立阶段LCP 协商。两端通过 LCP 报文协商一堆链路层参数比如最大接收单元 MRU、认证协议类型、魔术字、是否压缩等等。这里有个关键点认证协议的选择就是在 LCP 阶段谈定的。也就是说如果一端要求 CHAP另一端必须同意否则 LCP 协商直接失败链路根本进不了后面的认证阶段。很多人配置完发现链路起不来其实卡在 LCP 而不是认证本身这个区分很重要。第二个阶段是认证阶段。LCP 谈好了用 CHAP就进入认证环节。注意认证是可选的如果两端都没配认证LCP 协商完直接跳到网络层协商。但只要有一端要求认证就必须走完这个阶段才能继续。第三个阶段是网络层协议协商阶段NCP。认证通过后才开始协商 IPCP 之类的网络层参数分配 IP 地址、协商 DNS 等。这里能看出一个设计逻辑认证是网络层通信的前置门槛没过认证IP 层的东西一概不谈。第四个阶段是链路终止阶段链路要拆的时候通过 LCP 报文终止。把这四个阶段串起来看CHAP 的位置就很清晰了它夹在 LCP 和 NCP 之间是一道门禁。门禁没通过后面的网络层协商一步都走不了。理解这个层次关系排错时你就知道该看哪一层的日志——如果 LCP 都没起来别去查 CHAP 配置如果 LCP 起来了但认证失败那才是 CHAP 的问题。1.2 PAP 和 CHAP 的本质区别在哪既然讲 CHAP就绕不开和 PAP 的对比因为很多人是先学了 PAP 再学 CHAP容易把两者的行为搞混。我用一句话概括PAP 是明文报口令CHAP 是不传口令只传摘要。PAP 的过程特别简单就是两次握手被认证方直接把用户名和密码明文发给认证方认证方比对数据库对就通过错就拒绝。整个过程密码在链路上是裸奔的抓个包就能看到安全性很差。而且 PAP 只在链路建立时认证一次之后就不再管了属于进门查一次票进去随便逛。CHAP 完全不一样它是三次握手而且核心是不传密码本身。认证方发一个随机挑战值Challenge被认证方用这个挑战值加上自己的密码经过 MD5 哈希算出一个摘要Response发回去认证方自己也算一遍两边对得上就通过。密码从头到尾没在链路上出现过抓包也只能看到一个哈希值而且每次挑战值不同算出来的摘要也不同重放攻击基本没戏。还有一个容易被忽略的差异CHAP 支持周期性重认证。链路建立后认证方可以隔一段时间再发一次挑战重新验证对方身份防止链路被中途劫持。PAP 没有这个机制。这个特性在实际配置里对应一个chap ...相关的定时参数后面会讲到。对比维度PAPCHAP握手次数两次三次密码传输明文不传密码只传 MD5 摘要安全性低可被抓包较高抗重放重认证不支持支持周期性重认证认证方向单向为主可单向可双向配置复杂度简单稍复杂需注意用户名匹配这张表建议记牢考试和实际排错都用得上。尤其是认证方向这一行CHAP 的双向认证是很多实验题的考点也是配置最容易出错的地方。1.3 CHAP 三次握手的报文级拆解光说三次握手太抽象我把每一步的报文交互拆开讲你对着抓包就能一一对应上。第一步Challenge挑战。认证方Authenticator生成一个随机数加上自己的主机名标识封装成 Challenge 报文发给被认证方。这个随机数的长度一般是 16 字节每次认证都重新生成这是抗重放的关键。报文里还带一个 ID 字段用来匹配后续的响应因为可能同时有多个认证在进行。第二步Response响应。被认证方收到 Challenge 后取出随机数找到本地存储的对应认证方用户名的密码把ID 随机数 密码三样东西拼在一起做 MD5 运算得到一个 16 字节的摘要。然后把自己的用户名 这个摘要封装成 Response 报文发回去。注意这里发的是自己的用户名不是密码认证方靠这个用户名去自己的数据库里找对应的密码来验算。第三步Success 或 Failure成功/失败。认证方收到 Response用报文里的用户名查本地配置的密码同样把 ID 随机数 密码做 MD5和自己收到的摘要比对。一致就回 Success链路进入 NCP 阶段不一致就回 Failure链路直接终止而且通常会等一段时间再重试。这里有个特别容易踩的坑被认证方做 MD5 用的密码是认证方用户名对应的密码不是自己的用户名对应的密码。换句话说A 认证 B 的时候B 要用A 的用户名去查密码来做摘要。这个逻辑第一次接触的人几乎都会绕晕配置时用户名对不上就是认证失败的头号原因。我后面在配置章节会专门用例子把这个对应关系讲清楚。2. 配置前的准备工作与关键参数2.1 实验拓扑与地址规划配置之前先把环境搭好我这里用一个最经典的两点直连拓扑来说明这种拓扑在模拟器里搭起来最快也最能说明问题。两台路由器通过串口Serial直连模拟广域网链路。为什么用串口而不是以太网口因为 PPP 本质是广域网协议串口是它最典型的载体虽然现在以太网上也能跑 PPPoE但学原理阶段用串口最纯粹。地址规划上串口链路我习惯用一个独立的网段比如10.1.1.0/30两端分别是10.1.1.1和10.1.1.2。用 /30 是因为点对点链路只需要两个可用地址/30 正好两个不浪费。如果你习惯用 /24 也无所谓实验环境不讲究这个但养成节约地址的习惯没坏处。设备命名上我把认证方叫 R1被认证方叫 R2。这个角色划分很重要因为 CHAP 的配置是不对称的——认证方要配对谁做认证、用什么方式被认证方要配给对方什么用户名密码。角色搞反了命令就全配错了。提示模拟器里串口默认可能是 shutdown 状态配地址前先undo shutdown否则接口起不来你会误以为是 PPP 的问题。这个坑我踩过不止一次。2.2 用户名和密码的对应关系设计这是 CHAP 配置里最烧脑的部分我单独拎出来讲。CHAP 认证涉及两个方向的用户名密码概念必须分清楚本地用户名密码本设备上配置的local-user xxx password ...这是我用来验证别人或者别人用来验证我的凭据。对端用户名在接口上通过ppp chap user xxx指定的告诉对方我是谁。关键规则是认证方验证被认证方时用的是认证方本地数据库里被认证方用户名对应的密码被认证方计算摘要时用的是自己本地数据库里认证方用户名对应的密码。我用具体例子说明。假设 R1 认证 R2约定R2 用自己的用户名r2user向 R1 表明身份R1 本地要有一条r2user的记录密码设为r2passR2 本地要有一条r1user的记录R1 的用户名密码也设为r2pass。看出来了吗两边的密码必须一致但用户名各配各的。R1 存的是R2 的用户名 密码R2 存的是R1 的用户名 密码而这两个密码值是同一个。这就是 CHAP 最容易配错的地方——很多人两边密码配成不一样的或者用户名对不上认证必然失败。为了让你更直观我把这个对应关系做成表设备角色本地需配置的用户密码接口上指定的 chap userR1认证方r2userr2pass可不配认证方主动发挑战R2被认证方r1userr2passr2user注意最后一行R2 接口上要配ppp chap user r2user意思是我向对方报的用户名是 r2user。而 R1 本地存的正是r2user这个用户密码r2pass。R2 本地存的r1user是给如果 R1 也反过来认证 R2或者双向认证时用的。单向认证场景下R2 本地那条r1user其实在计算摘要时用不到——等等这里要纠正一个常见误解。实际上被认证方计算 Response 摘要时用的密码是认证方用户名对应的密码。也就是说 R2 收到 R1 的 Challenge里面带 R1 的主机名R2 要去本地找R1 的用户名对应的密码来做 MD5。所以 R2 本地必须配r1user且密码为r2pass否则 R2 根本算不出正确的摘要。这就是为什么上表里 R2 要配r1user。这个细节很多教程讲得含糊我当年就是卡在这里配了半天发现 R2 本地没配 R1 的用户摘要算出来对不上。2.3 认证方式的选择单向还是双向CHAP 支持单向认证和双向认证选哪个取决于你的安全需求。单向认证只有一端认证另一端比如 R1 认证 R2R2 不认证 R1。配置简单适合中心节点验证接入节点的场景比如总部验证分支机构。双向认证两端互相认证R1 认证 R2 的同时 R2 也认证 R1。安全性更高但配置量翻倍两边都要配本地用户和接口认证。实际项目里如果两端地位对等、都需要确认对方身份就用双向。实验阶段我建议先配单向跑通再改双向。因为单向的变量少出问题好定位一上来就配双向失败了都不知道是哪个方向的问题。这个循序渐进的方法是我调试任何认证类配置的通用套路。3. 完整配置命令逐条拆解3.1 认证方 R1 的配置先配认证方。R1 要做的事开启 CHAP 认证、在本地建好被认证方的用户、在接口上启用 CHAP 认证。第一步进系统视图配本地用户。命令是local-user r2user password cipher r2pass然后local-user r2user service-type ppp。这里service-type ppp不能漏它限定这个用户只能用于 PPP 认证是个安全约束。密码用cipher表示密文存储比simple明文存储安全虽然实验环境无所谓但养成习惯。第二步进串口接口视图配ppp authentication-mode chap。这条命令的意思是本接口用 CHAP 方式认证对端。注意这条命令是认证方才配的被认证方不配这条或者说配了就是要求认证对方角色就变了。第三步可选地配ppp chap hostname r1user指定本端在 CHAP 交互中报的主机名。如果不配默认用设备的主机名。单向认证场景下这条可以不配但双向认证时必须配因为对方要靠这个名字查密码。R1 的完整配置大概长这样system-view sysname R1 local-user r2user password cipher r2pass local-user r2user service-type ppp interface Serial1/0/0 ip address 10.1.1.1 255.255.255.252 ppp authentication-mode chap ppp chap hostname r1user undo shutdown逐条解释一下为什么这么配。local-user两条是给认证方准备验证别人的凭据ppp authentication-mode chap是声明我要认证你ppp chap hostname是告诉对方我叫 r1user方便对方查密码。地址配 /30 前面说过了。undo shutdown是激活接口。注意ppp authentication-mode chap配在接口上后接口会立即开始要求对端认证。如果对端还没配好链路会一直卡在认证阶段日志里能看到 CHAP 认证失败的记录。这是正常现象别慌。3.2 被认证方 R2 的配置R2 要做的事配好认证方的用户用于算摘要、在接口上声明自己报的用户名。第一步同样配本地用户但这次配的是认证方 R1 的用户名local-user r1user password cipher r2passlocal-user r1user service-type ppp。密码还是r2pass和 R1 那边保持一致。第二步进接口配ppp chap user r2user意思是我向对方报的用户名是 r2user。这条命令对应 R1 本地存的r2user用户两边就对上了。第三步配地址10.1.1.2 255.255.255.252undo shutdown。R2 的完整配置system-view sysname R2 local-user r1user password cipher r2pass local-user r1user service-type ppp interface Serial1/0/0 ip address 10.1.1.2 255.255.255.252 ppp chap user r2user undo shutdown对比 R1 和 R2 的配置你会发现一个有意思的对称性R1 配authentication-mode chap但没配chap user单向场景R2 配chap user但没配authentication-mode。这就是单向认证的典型形态——一方要求认证一方表明身份。如果你要配双向认证那就把两边的配置合并R1 也加上ppp chap user r1userR2 也加上ppp authentication-mode chap同时两边本地用户都要配齐R1 配 r2userR2 配 r1user密码一致。这样两端互相认证任何一方验证失败链路都起不来。3.3 验证配置是否生效配完不能光看接口 up 了就完事得确认认证真的过了。几个验证手段第一display interface Serial1/0/0看接口的 Line protocol 状态。如果显示 up说明 LCP 和认证都过了如果显示 down 或 spoofing说明卡在某一层。第二display ppp interface Serial1/0/0看 PPP 的详细状态能看到 LCP 是否 open、认证是否成功、NCP 是否协商完成。这个命令信息量大排错时必看。第三开调试。debugging ppp chap all能看到 CHAP 报文的交互过程Challenge、Response、Success 每一步都有打印。调试完记得undo debugging all关掉否则日志刷屏影响性能。这个手段最直接认证失败时能看到具体是哪一步出的问题。第四ping对端地址。能 ping 通说明整条链路物理层、PPP、IP 层全通了这是最终的验收标准。我一般的验证顺序是先看接口状态再看 PPP 详细状态不通就开 debug最后 ping 验收。这个顺序从粗到细效率最高。4. 认证失败的排查思路与常见坑4.1 从日志和调试信息定位问题CHAP 认证失败日志里通常会有明确的提示关键是会看。常见的几类报错CHAP authentication failed最笼统的失败说明摘要对不上往下查用户名密码。LCP negotiation failed这其实不是 CHAP 的问题是 LCP 阶段就没谈拢可能一端要求 CHAP 另一端不支持或者 MRU 之类的参数不匹配。No response received被认证方没回 Response可能是被认证方没配chap user或者链路物理层有问题。开debugging ppp chap all后正常流程的打印大概是发 Challenge、收 Response、验证通过发 Success。如果卡在发 Challenge 后没收到 Response问题在被认证方如果收到 Response 但验证失败问题在密码或用户名匹配。我排错时有个习惯先确认 LCP 起来了没有。因为如果 LCP 都没起来CHAP 的调试信息根本不会出现你查半天 CHAP 配置是白费功夫。用display ppp interface看 LCP 状态open 了才往下查认证。4.2 用户名密码不匹配的典型场景这是最高频的失败原因我列几个具体的坑坑一两边密码不一致。前面强调过认证方本地存的被认证方用户名的密码和被认证方本地存的认证方用户名的密码必须是同一个值。有人配的时候 R1 存 r2user 密码 123R2 存 r1user 密码 456摘要当然对不上。坑二chap user和本地用户名对不上。R2 接口上配ppp chap user r2user但 R1 本地配的用户是r2名字差一点R1 收到 Response 后拿r2user去查数据库查不到直接失败。坑三忘了配service-type ppp。本地用户配了密码但没指定服务类型PPP 认证时这个用户不可用等于没配。这个错误很隐蔽因为用户确实存在但就是认证不过。坑四被认证方本地没配认证方的用户。前面讲过被认证方算摘要要用认证方用户名对应的密码如果 R2 本地没配r1user它收到 Challenge 后找不到密码算不出正确摘要。这个是最容易忽略的因为直觉上会觉得我被认证配我自己的密码就行了但 CHAP 的逻辑不是这样。4.3 一个高频问题速查表我把实际调试中遇到的典型现象和对应原因整理成表出问题时对着查能省不少时间现象可能原因排查动作接口 Line protocol downLCP 未协商成功查两端 LCP 参数、认证方式是否一致日志报 CHAP authentication failed密码不一致或用户名不匹配核对两端本地用户和 chap user发 Challenge 后无响应被认证方未配 chap user 或链路断查被认证方接口配置和物理链路认证通过但 ping 不通NCP 未协商或地址配错查 IP 地址、IPCP 状态周期性掉线重认证重认证定时器触发且凭据失效查密码是否被改、重认证间隔双向认证只有一向通过某一方向本地用户缺失两端都检查本地用户配置这张表里周期性掉线重认证这一行值得多说一句。CHAP 支持重认证如果配了较短的间隔链路会定期重新验证。如果这期间密码被改了或者用户被删了链路就会周期性断开。实际项目里如果遇到链路每隔一段时间断一次又自动恢复先怀疑重认证相关的配置。4.4 实操心得调试顺序比命令更重要分享一个我调试认证类问题的固定套路屡试不爽第一步物理层先确认。接口物理状态 up 了吗display interface看 Physical 是不是 up。物理层不通上面全是空谈。第二步LCP 层确认。display ppp interface看 LCP 状态。LCP 不通查认证方式是否两端匹配、MRU 等参数。第三步认证层确认。开 debug 看 CHAP 交互定位是没响应还是验证失败。第四步网络层确认。认证过了 ping 不通查 IP 地址和 NCP 协商。这个从下往上的顺序本质上是按 PPP 的协议栈层次来查每一层确认没问题再往上走。很多人一上来就盯着 CHAP 配置看结果发现是物理层接口没undo shutdown白折腾半天。层次化排查是网络排错的基本功比记住多少条命令都重要。5. 进阶双向认证与安全加固5.1 双向认证的配置要点双向认证在实际项目里用得不少尤其是两端都需要确认对方身份的场景。配置上就是把单向的两套配置合并但有几个细节要注意。R1 的配置在单向基础上增加接口加ppp chap user r1user声明自己报的用户名本地用户除了r2user还要确保有r1user吗不需要R1 认证 R2 用r2userR2 认证 R1 时 R1 报r1userR2 本地要有r1user。R1 本地只需要r2user用于认证 R2。等等这里又要理清双向认证时R1 既认证 R2 又被 R2 认证。R1 认证 R2 用本地r2userR1 被 R2 认证时R1 报r1userR2 本地要有r1user且密码一致。所以 R1 本地配r2userR2 本地配r1user密码都是r2pass或者你约定的统一密码。R1 接口配authentication-mode chap和chap user r1userR2 接口配authentication-mode chap和chap user r2user。我把双向认证的完整配置列一下方便对照# R1 双向认证配置 system-view sysname R1 local-user r2user password cipher r2pass local-user r2user service-type ppp interface Serial1/0/0 ip address 10.1.1.1 255.255.255.252 ppp authentication-mode chap ppp chap user r1user undo shutdown # R2 双向认证配置 system-view sysname R2 local-user r1user password cipher r2pass local-user r1user service-type ppp interface Serial1/0/0 ip address 10.1.1.2 255.255.255.252 ppp authentication-mode chap ppp chap user r2user undo shutdown对比单向配置双向就是两边都加了authentication-mode chap和chap user。看起来简单但用户名密码的对应关系一定要按前面讲的规则来否则两个方向总有一个过不了。5.2 重认证定时器与安全参数CHAP 的重认证能力是它比 PAP 强的重要一点。认证方可以配置重认证的间隔定期重新验证对端身份。相关命令通常是ppp chap ...系列里的定时参数具体语法各平台略有差异常见的是在接口下配重认证时间。配重认证的考量间隔太短频繁认证增加开销链路可能因为瞬时问题误断间隔太长安全性下降链路被劫持后长时间发现不了。实际项目里一般设几分钟到几十分钟实验环境可以不配或者设长一点避免调试时被重认证干扰。除了重认证还有几个安全加固点值得注意。一是密码强度虽然实验环境随便设但实际项目里密码要够复杂因为 CHAP 的摘要虽然不直接暴露密码但如果密码太弱理论上存在被暴力破解的风险。二是本地用户的service-type要严格限定为 ppp避免这个账号被用于其他服务。三是定期更换密码配合重认证机制能及时发现凭据失效。5.3 CHAP 与 PAP 的混合使用场景有时候会遇到一端要求 CHAP、另一端只支持 PAP 的情况或者为了兼容老设备需要降级。PPP 允许在 LCP 阶段协商认证协议如果一端配了ppp authentication-mode chap pap意思是优先 CHAP对端不支持就退到 PAP。这种配置在兼容性场景下有用但安全性打了折扣因为一旦退到 PAP密码就明文传输了。我的建议是能 CHAP 就 CHAP不要为了省事配 pap 回退。如果确实要兼容至少确认链路环境是可信的比如专线直连不经过不可控的中间网络。实验环境里可以试试这个回退配置观察 LCP 协商时认证协议是怎么谈的对理解 PPP 的协商机制很有帮助。6. 从实验到实战几个值得记住的经验6.1 模拟器与真实设备的差异模拟器里配通了不代表真实设备上一定没问题有几个差异点要心里有数。模拟器对某些命令的支持可能不完整比如重认证定时器的具体参数模拟器可能不生效或者默认值不同。另外模拟器的串口是虚拟的物理层不会真的出问题所以物理层排错的经验在模拟器里练不到真实环境里线缆、接口、时钟频率这些都可能成为故障点。还有一个差异是性能。模拟器上开 debug 随便开真实设备上 debug 输出过多会占用 CPU可能影响转发甚至导致链路抖动。所以真实环境开 debug 要谨慎最好在业务低峰期并且配好 ACL 限制调试范围调完立刻关。6.2 认证配置的复用与模板化如果项目里有多条 PPP 链路要配 CHAP别一条条手敲容易出错还慢。我的做法是整理一个配置模板把用户名密码、接口地址这些变量抽出来用脚本批量生成。模板的核心就是前面讲的那套对应关系认证方配authentication-mode和本地被认证方用户被认证方配chap user和本地认证方用户密码统一。模板化还有个好处是一致性。手工配多条链路很容易某条链路的密码敲错一个字符排查起来极其痛苦。用模板生成至少保证结构一致出问题也好对比。这个习惯在规模稍大的网络里特别值钱。6.3 排错时最该先看的三样东西最后分享我个人的排错优先级遇到 PPP CHAP 问题我按这个顺序看第一看接口物理状态和协议状态display interface一条命令就能看出物理层和链路层的大致情况。第二看PPP 详细状态display ppp interface能定位到 LCP、认证、NCP 哪一层卡住。第三看调试信息前两步定位到认证层后开debugging ppp chap all看具体报文交互。这三样看完90% 的问题都能定位。剩下 10% 是比较刁钻的比如用户名大小写敏感、特殊字符转义、密码里带了空格之类的这些只能靠仔细核对配置。我遇到过密码末尾多敲一个空格的debug 看摘要就是不对查了半天才发现是空格问题这种坑只能靠细心。CHAP 这套机制设计得其实很优雅用摘要代替明文、用随机挑战抗重放、用重认证防劫持每一步都有明确的安全考量。把三次握手的报文交互和用户名密码的对应关系吃透配置就是照葫芦画瓢的事。真正花时间的从来不是敲命令而是理解为什么这么配——这也是我在带新人时反复强调的一点命令可以查文档但对应关系搞不清出了问题就只能干瞪眼。