PPP 的 PAP 认证是很多刚接触企业级网络设备的朋友绕不开的一道坎。标题里这个场景说白了就是在模拟器里把两台路由器用串口线连起来让其中一台在建立链路之前先报上名来另一台核对身份对上了才放行。它解决的是点对点链路里最基础的身份核验问题——谁都能插上线但不是谁都能通。这套东西适合正在备考网络方向认证的学员、刚入行的网络运维以及需要在实验环境里复现广域网拨号场景的工程师。我见过太多人配置命令敲得飞快一问为什么这么配就卡壳所以这篇我打算把 PAP 的原理、报文交互、配置命令和踩坑经验一次讲透让你不光能配通还能讲明白。1. 先搞清楚 PAP 到底在链路建立里扮演什么角色1.1 从 PPP 的分层结构说起要理解 PAP得先知道它站在 PPP 的哪一层。PPP 本身不是一个单一协议而是一套协议族官方定义里把它拆成了三个组件一个用来封装上层数据的方法、一个链路控制协议 LCP、一组网络控制协议 NCP。很多人配 PPP 的时候只盯着 IP 地址其实链路能不能起来关键在 LCP 这一层。LCP 负责的是链路建立、配置和测试它要协商一堆参数最大接收单元 MRU、认证协议、魔术字、链路质量报告等等。PAP 和 CHAP 就是 LCP 协商阶段要确定下来的认证方式。换句话说链路刚起来的时候双方先通过 LCP 报文互相打招呼其中一方会说我要求你认证用 PAP 或者 CHAP另一方回应行用 PAP。协商定了之后才进入认证阶段PAP 的报文就是在这个阶段跑的。这里有个容易混淆的点PAP 的报文虽然是在 LCP 协商之后发的但它本身并不属于 LCP 报文而是独立的协议报文封装在 PPP 帧里协议字段是 0xC023。你在抓包的时候会看到 LCP 的 Configure-Request、Configure-Ack 走完紧接着才是 PAP 的 Authenticate-Request。理解这个顺序后面排查问题的时候你就知道该看哪一段了。我个人的经验是把 PPP 的建立过程想象成进小区LCP 协商相当于在门口跟保安确认我要进来咱们用什么方式验证身份认证阶段才是真正掏证件NCP 阶段则是进了小区之后分配门牌号IP 地址。PAP 就是掏证件这个动作里最简单粗暴的一种——明文报名字和密码。1.2 PAP 的两次握手为什么不安全却依然常见PAP 的全称是 Password Authentication Protocol密码认证协议。它的交互极其简单就两个报文认证请求和认证响应。被认证方把用户名和密码用明文塞进 Authenticate-Request 报文里发过去认证方查自己的本地用户表对上了回一个 Authenticate-Ack对不上回 Authenticate-Nak。正因为密码是明文传输的PAP 在安全性上一直被诟病。链路上如果有人抓包用户名密码一览无余。那为什么它还没被淘汰原因很现实一是兼容性好很多老设备和某些特定场景比如某些拨号接入、部分厂商的专线对接只支持 PAP二是配置简单排查直观实验和教学场景里用它来理解认证流程再合适不过三是 PAP 支持重传认证失败后可以反复尝试不像 CHAP 那样一次定生死。注意PAP 的密码在链路上是明文生产环境里但凡链路经过不可信区域优先考虑 CHAP。PAP 更适合实验、教学、以及明确知道对端只支持 PAP 的对接场景。在模拟器里做实验PAP 的价值不在于安全而在于让你把认证协商—认证请求—认证响应这条链路走通理解 PPP 的状态机。你把 PAP 配通了再去看 CHAP 的三次握手和哈希挑战理解起来会顺很多。1.3 认证方与被认证方的角色划分PAP 里两个角色必须分清认证方Authenticator是掌握用户表、负责核对身份的那一端被认证方Authenticated Peer是主动报名字密码的那一端。这个角色不是按谁是主叫来分的而是按配置来定的。在设备配置里通常是在某一端的接口上敲ppp authentication-mode pap这一端就成了认证方它会要求对端认证。对端则需要在接口上配置ppp pap local-user 用户名 password 密码把自己要报的凭据准备好。同时认证方本地必须存在对应的用户名和密码通常用local-user命令在 AAA 视图下创建。这里最常见的翻车点就是角色搞反了两端都配了ppp authentication-mode pap结果双方都要求对方认证但谁也没准备报自己的凭据链路就一直卡在认证阶段。或者一端配了认证模式另一端忘了配ppp pap local-user被认证方没东西可报同样起不来。所以配之前先在纸上画清楚A 要求 B 认证A 是认证方A 上要有 B 的用户名密码B 是被认证方B 上要配自己的 local-user 和 password。2. 实验环境搭建与接口基础配置2.1 拓扑设计与地址规划模拟器里做 PAP 实验最省事的拓扑就是两台路由器背靠背用 Serial 接口直连。选 Serial 而不是以太网是因为 PPP 本来就是为串行链路设计的虽然现在以太网上也能跑 PPPoE但纯 PPP 的认证实验用 Serial 最贴近原理也最不容易被二层协议干扰。地址规划上我习惯给两端各配一个同网段的 IP比如一端 10.1.1.1/24另一端 10.1.1.2/24。虽然 PPP 是点对点链路理论上可以用 31 位掩码甚至不配地址靠协商但实验阶段用 24 位掩码最直观ping 起来也方便验证。Serial 接口的时钟频率需要在一端配置DCE 端敲clock rate 64000另一端起不来很多时候就是忘了这个。具体规划我列个表照着配不容易乱设备角色接口IP 地址认证角色关键配置路由器 ASerial 1/0/010.1.1.1/24认证方authentication-mode pap本地用户表路由器 BSerial 1/0/010.1.1.2/24被认证方ppp pap local-user这个表看着简单但它把谁认证谁这件事钉死了。你在配置的时候每敲一条命令回头看一眼这张表就知道自己有没有配错方向。2.2 接口封装与时钟配置进入接口之后第一件事是改封装。设备默认的 Serial 接口封装可能是 HDLC 或者 PPP不同版本默认值不一样稳妥起见手动敲一条link-protocol ppp明确告诉接口用 PPP 封装。这条命令不敲后面所有 PPP 相关的认证配置都是白搭因为认证是 PPP 的特性HDLC 下根本没有这个概念。时钟这块背靠背直连时一端是 DCE需要提供时钟。模拟器里有时候不敲 clock rate 也能起来但真实设备上不敲就是不通。我的习惯是两端都看一眼display interface Serial 1/0/0输出里会标明 DCE 还是 DTEDCE 端补上clock rate 64000。64000 是个保守值实验够用真实专线按运营商给的带宽来。配置完封装和时钟先别急着上认证先ping一下对端地址确认三层能通。这一步是基线验证——如果裸 PPP 都不通加了认证只会更乱。我见过有人一上来就配认证结果不通分不清是认证配错了还是底层链路有问题白白浪费半小时。2.3 认证前的连通性基线验证基线验证这一步值得单独强调。裸 PPP 配好 IP 之后ping 10.1.1.2应该能通display interface Serial 1/0/0应该看到 Line protocol current state 是 UP。如果这时候就不通先查物理层模拟器里看接口有没有起来、查时钟、查 IP 是否同网段、查封装是否都是 PPP。这个基线还有个作用等你配完 PAP 认证之后如果 ping 不通了你就能确定问题出在认证环节而不是底层。排查范围一下子缩小了。我一般会在配认证前把ping结果截图或者记一下配完再对比心里有底。提示模拟器里 Serial 接口有时需要先shutdown再undo shutdown才能正常起来遇到接口状态异常可以先试这一下。3. PAP 认证的核心配置命令逐条拆解3.1 认证方开启 PAP 认证与本地用户表认证方的配置分两块接口上开启认证模式AAA 里建用户。先看接口侧interface Serial 1/0/0 link-protocol ppp ppp authentication-mode papppp authentication-mode pap这条命令的含义是本端作为认证方要求对端用 PAP 方式认证。敲完之后本端在 LCP 协商阶段就会带上要求 PAP 认证的选项。然后是用户表在系统视图下aaa local-user userb password cipher Huawei123 local-user userb service-type ppp这里有两个细节必须注意。第一service-type ppp不能漏用户建了但服务类型没给 PPP认证的时候照样失败因为设备不知道该用户能用于哪种接入。第二密码建议用cipher关键字存密文虽然实验里用simple明文也能配但养成存密文的习惯没坏处。用户名和密码要对上被认证方要报的值。比如被认证方准备报userb / Huawei123那认证方本地就得有userb这个用户密码一致。两边对不上认证必失败而且报错信息往往只说认证失败不会告诉你具体是用户名错还是密码错排查时容易懵。3.2 被认证方准备上报的凭据被认证方的配置相对简单接口上一条命令搞定interface Serial 1/0/0 link-protocol ppp ppp pap local-user userb password cipher Huawei123ppp pap local-user这条命令定义的是我在 PAP 认证时要报的用户名和密码。注意它和认证方的local-user是两回事认证方的local-user是本地用户数据库被认证方的ppp pap local-user是我要报出去的凭据。名字像作用完全不同这是新手最容易混的地方。被认证方不需要配ppp authentication-mode pap因为它不要求对方认证。如果两端都配了认证模式就变成了双向认证双方都要报凭据配置量翻倍实验阶段没必要先把单向认证搞明白再说。3.3 命令对照表与常见误配把两端的命令放一起对照误配点一目了然配置项认证方 A被认证方 B封装link-protocol ppplink-protocol ppp认证模式ppp authentication-mode pap不配上报凭据不配ppp pap local-user userb password ...本地用户local-user userb ... service-type ppp不配最常见的三种误配一是被认证方也敲了ppp authentication-mode pap变成双向认证二是认证方忘了service-type ppp三是两端用户名密码对不上。这三种情况链路都起不来但现象略有差别后面排查章节细说。注意ppp pap local-user里的密码和认证方local-user里的密码必须完全一致包括大小写。PAP 是明文比对一个字符不对就失败。4. 认证过程抓包分析与状态机观察4.1 从 LCP 协商到 PAP 报文的完整时序配完之后ping一下触发链路重新协商这时候如果能在模拟器里抓包会看到一段很有规律的报文序列。先是 LCP 的 Configure-Request 和 Configure-Ack 来回其中认证方发出的 Configure-Request 里会带 Authentication-Protocol 选项值为 PAP0xC023。双方 LCP 协商完成后被认证方发出 PAP 的 Authenticate-Request里面明文带着用户名和密码认证方核对通过后回 Authenticate-Ack链路进入 UP。这个时序理解透了排查就有方向如果卡在 LCP 阶段说明封装或认证模式协商有问题如果 LCP 过了但 PAP 报文没发出来说明被认证方没配ppp pap local-user如果 PAP 请求发了但收到 Nak说明用户名密码对不上。4.2 用 display 命令确认认证状态抓包不是随时都有条件更多时候靠display命令看状态。几个常用的display interface Serial 1/0/0 display ppp interface Serial 1/0/0display interface看 Line protocol 是否 UPdisplay ppp interface能看到 LCP 和认证的协商结果。认证失败时接口的 Line protocol 会保持 DOWN物理层可能还是 UP这个物理 UP、协议 DOWN的组合基本就是认证没过或者 NCP 没协商成。我习惯在认证失败时先看display interface确认是物理层问题还是协议层问题再看display ppp interface确认认证阶段卡在哪。两步下来问题范围基本就锁定了。4.3 认证成功与失败的日志差异设备日志里认证成功和失败的记录不一样。成功时通常能看到 PPP 链路建立、认证通过的提示失败时会明确写 authentication failed有时候还会带上是哪个用户认证失败。开terminal monitor和terminal debugging能看到更详细的协商过程但调试信息量大实验时开一下看看可以别长期开着。日志里如果反复出现认证请求和失败说明被认证方在不停重试。PAP 支持重传默认会试几次全失败才彻底放弃。看到这种反复重试的日志直接去核对用户名密码八成是对不上。5. 认证失败的排查思路与速查表5.1 分层排查从物理层到认证层排查 PAP 认证失败我习惯按层往下走不跳步。第一层看物理层接口是不是 UP时钟有没有配线缆模拟器里是链路通不通。第二层看链路层两端封装是不是都 PPPLCP 能不能协商起来。第三层才是认证层认证模式、用户名、密码、服务类型。这个顺序的好处是不会冤枉人。很多人一不通就去改认证配置结果折腾半天发现是时钟没配。按层排查每层确认没问题再往下效率高得多。5.2 常见问题速查表把实际踩过的坑整理成表遇到问题对着查现象可能原因排查命令/动作物理层 DOWN接口未开启、时钟缺失display interface检查 clock rate物理 UP 协议 DOWN封装不一致、认证失败display interface确认 link-protocol pppLCP 协商不过认证模式配置冲突display ppp interface检查两端认证模式PAP 请求未发出被认证方缺 local-user 配置检查 ppp pap local-user收到 Authenticate-Nak用户名或密码不匹配核对两端凭据注意大小写认证通过但 ping 不通NCP 阶段 IP 未协商或路由问题检查 IP 配置、display ip interface brief这张表覆盖了八成以上的实验故障。剩下两成往往是模拟器本身的玄学问题比如接口状态卡住shutdown再undo shutdown通常能解决。5.3 三个高频踩坑的实录第一个坑认证方建了用户但忘了service-type ppp。现象是 PAP 请求发过去了认证方也收到了但就是回 Nak。查用户名密码都对最后发现是服务类型没给。这个坑很隐蔽因为用户确实存在只是不能用于 PPP。第二个坑被认证方密码用了simple明文配认证方用cipher配两边看起来密码一样实际存储形式不同导致比对失败。稳妥做法是两端都用cipher或者干脆都用simple实验别混着来。第三个坑两端都配了ppp authentication-mode pap变成双向认证但只有一端配了ppp pap local-user。现象是链路反复协商起不来日志里能看到双方都在要求对方认证。解决方法是明确单向认证把不需要认证的那端的认证模式去掉。提示实验时养成配完一端立刻验证一端的习惯别两端一起配完再测。一端配完先看状态确认这端没问题再配另一端出问题时排查范围小一半。6. 从 PAP 延伸到 CHAP 的平滑过渡PAP 配通之后很多人会顺势学 CHAP。这里给个平滑过渡的思路CHAP 的配置框架和 PAP 几乎一样认证方还是ppp authentication-mode chap被认证方还是配凭据区别在于 CHAP 是三次握手、密码不明文传输、用哈希挑战。你把 PAP 的角色划分、用户表、服务类型这些搞明白了换到 CHAP 只需要改认证模式关键字和被认证方的命令形式。我建议的学习路径是先用 PAP 把认证方—被认证方—用户表—凭据这套关系吃透再上 CHAP 理解挑战应答机制。反过来先学 CHAP容易被哈希、随机数、挑战值这些概念绕晕反而忽略了认证的本质就是证明你是谁。实际项目里选哪种看对端支持和对安全的要求。链路可信、对端只支持 PAP那就 PAP链路不可信、两端都支持优先 CHAP。实验环境里两种都配一遍对比抓包理解会深很多。我个人在实际操作中的体会是PAP 这种明文报名字密码的机制最大的教学价值在于它把认证流程剥得干干净净没有哈希和随机数的干扰让你能专注理解 PPP 状态机里协商—认证—网络层这三段式结构。把这个结构刻在脑子里后面不管是配 CHAP、配 PPPoE还是排查广域网拨号问题思路都是通的。最后再分享一个小技巧实验做完别急着删配置把display current-configuration导出来存一份下次配类似场景直接对照改比从头敲快得多也不容易漏命令。