1. 从一道综合实验题说起为什么非要用PPP做网络工程这一行绕不开一个东西广域网封装。早期在思科设备上串行链路默认封装是HDLC但HDLC是各家私有实现不同厂商设备对接时经常协商不上。后来出现了PPP也就是点对点协议它把链路层封装、网络层协商、认证鉴权做成了一个完整体系成为运营商接入和企业专线场景里的标准选择。华为eNSP模拟器是学习这套体系成本最低的环境不需要真机、不需要租专线只要电脑装好eNSP拖两台AR路由器就能把PPP的完整交互流程跑一遍。这次我写的综合实验核心目标有三个第一在eNSP里搭建双路由串行链路让PPP封装生效第二配置PAP和CHAP两种认证理解它们的区别和适用场景第三通过抓包和日志把LCP协商、IPCP交互这些“看不见的过程”变成肉眼可见的数据包把协议原理真正吃透。适合看这篇文章的人主要是正在备考华为HCIA/HCIP、刚接触广域网协议的网络新人以及工作里遇到专线对接、拨号场景但一直没时间系统整理PPP知识点的运维工程师。实验全部基于eNSP完成不需要额外硬件跟着配置即可完整复现。2. PPP协议核心机制拆解2.1 PPP的分层结构LCP、NCP在干什么PPP协议的设计思路是分层协作它不像以太网那样一个帧头打天下而是把链路建立、参数协商、网络层协议接入拆成三个相对独立的部分。LCPLink Control Protocol链路控制协议负责链路的建立、配置、测试和拆除比如协商MRU最大接收单元、链路质量检测、认证协议选择都在这一层完成。NCPNetwork Control Protocol网络控制协议负责协商网络层协议参数最常见的例子是IPCP它负责给链路对端分配IP地址、协商IP压缩等参数。认证协议PAP/CHAPLCP协商阶段会确定要不要认证、用哪种认证方式认证通过之后链路才真正进入可用状态。这个分层设计带来的直接影响是PPP链路既可以承载IPv4也可以承载IPv6甚至其他网络层协议只要对应启用不同的NCP即可LCP部分完全不用动。理解这一点对后面排查故障很有帮助——链路拨不上号先看LCP阶段再看认证最后看IPCP顺序不能乱。2.2 PPP帧格式与报文交互流程PPP的数据帧在HDLC-like framing下的结构是标志字段0x7E、地址字段0xFF、控制字段0x03、协议字段、信息字段、FCS校验。协议字段是整个帧格式里最关键的部分它决定了信息字段里装的是什么类型的数据0xC021LCP报文0xC023PAP报文0xC223CHAP报文0x8021IPCP报文0x0021IPv4数据报文抓包时只要看到协议字段是0xC021就知道这是LCP协商包不需要再一个个字节去猜。这种通过协议字段区分类别的方式和以太网里用EtherType区分IP/ARP的思路完全一致。LCP协商的核心交互是Configure-Request和Configure-Ack。一端发出配置请求对端检查参数可以接受就回复Ack如果参数不能接受则回复Nak参数值不可接受或者Reject参数类型不认识双方根据回复调整参数后重新协商直到达成一致。这个过程看起来简单实际上状态机里有好几种状态切换对应链路从“不可用”到“认证”再到“网络层协商”的完整流程。2.3 PAP与CHAP两种认证的本质区别PAP是明文密码认证协议它的工作方式简单粗暴客户端把用户名和密码以明文形式发给服务器端服务器端比对成功后回复Ack。整个过程只有一次握手认证失败也不会自动重试需要用户手动重新发起。适合实验室和低安全性环境但在真实生产环境中基本被淘汰因为抓包就等于泄露密码。CHAP是挑战握手认证协议它使用三次握手过程是服务器端先发送一个随机挑战值Challenge客户端用自己的密码和这个挑战值做MD5哈希计算把计算结果返回给服务器端服务器端做同样计算后比对结果。因为密码本身不出现在线路上而且挑战值每次随机生成所以可以有效防止重放攻击。配置时两端需要使用相同的用户名和密码但传输过程中不会出现明文密码。我的建议是所有生产环境一律用CHAP实验室里可以PAP和CHAP各做一遍重点理解两种方式的原理差异。3. 实验环境搭建与基本PPP配置3.1 eNSP环境准备与设备选型要点eNSP的最新版本中AR系列路由器默认支持PPP封装不需要额外添加模块。启动eNSP后从设备列表里拖两台AR2220路由器到拓扑区然后使用串行接口互联。有一点需要提前说明eNSP里的AR2220默认自带的串行接口类型是同/异步串口S接口可以直接支持PPP。拖出设备后右键启动等设备状态变为绿色即可继续配置。如果启动过程提示“错误代码40”或者设备一直处于灰色状态多半是VirtualBox版本兼容性问题建议先把eNSP自带的VirtualBox彻底卸载干净再重装或者以管理员身份运行eNSP。尺寸方面两台设备两对接口连线就能完成实验一台做认证端一台做被认证端拓扑规模其实很小。实际操作时我会额外加一台Cloud设备用来抓包但如果没有抓包需求两台路由器完全够了。3.2 接口IP地址配置与PPP链路状态验证准备工作完成后先做最基本的PPP配置。# 设备AR1被认证端 system-view sysname AR1 interface Serial 1/0/0 ip address 12.1.1.1 24 quit # 设备AR2认证端 system-view sysname AR2 interface Serial 1/0/0 ip address 12.1.1.2 24 quit在eNSP中AR路由器的串行接口默认封装就是PPP所以这里不需要显式执行link-protocol ppp命令但为了配置清晰我建议加上这条命令尤其在初始化配置或排障时能一眼确认接口封装状态。配置完成后在AR1上执行display interface Serial 1/0/0如果看到Physical line protocol is up说明链路已经协商成功。关键输出项包括Link layer protocol is PPP确认封装类型LCP openedLCP协商已完成IPCP openedIPCP协商已完成如果LCP没有打开需要优先排查物理接口状态和两端IP地址是否在同一网段如果LCP已打开但IPCP没打开需要检查接口下IP地址配置以及是否有认证不通过导致链路被挂起。3.3 为综合实验设计合理的场景纯双路由直连验证PPP两种认证方式是最基本的用法。但如果只做到这一层实验价值有限。我在这个综合实验中加了两个真实场景里的细节一是将认证端的用户名密码改用AAA域本地认证来配置模拟设备统一管理账号的场景二是链路建立后在AR1上配置一个Loopback地址用两种认证方式分别验证端到端通信确认PPP链路不仅协商成功还能正常承载业务流量。场景设计的原则是把每个配置点都对应到一个真实网络需求上而不是为敲命令而敲命令。这样实验做完你才能解释清楚“PPP能解决什么问题、认证配置到底在防什么”。4. PAP认证配置案例4.1 认证端完整配置流程与原理说明PAP认证的实验拓扑是AR1作为被认证端主动发送密码AR2作为认证端验证密码。认证端AR2的配置分为两大块aaa模块和接口认证。# AR2认证端 system-view sysname AR2 aaa local-user huawei password cipher huawei123 local-user huawei service-type ppp quit interface Serial 1/0/0 link-protocol ppp ip address 12.1.1.2 24 ppp authentication-mode pap quit配置了ppp authentication-mode pap之后AR2会要求对端在链路建立时提供用户名和密码。创建本地用户时service-type ppp是必选项如果不指定对端认证时会被拒绝。这里有一个细节值得注意在较老版本的eNSP中local-user命令默认不校验密码复杂度但在新版本中密码强度规则可能已经生效。如果配置时提示密码太简单使用password cipher Huawei123这类带特殊字符的密码即可。4.2 被认证端配置与PAP交互过程分析# AR1被认证端 system-view sysname AR1 interface Serial 1/0/0 link-protocol ppp ip address 12.1.1.1 24 ppp pap local-user huawei password cipher huawei123 quit关键命令是ppp pap local-user它告诉AR1在发起PPP连接时主动发送用户名和密码。这条命令必须在接口视图下配置而且用户名和密码必须和认证端的local-user配置完全一致否则认证端会回复认证失败链路无法进入IPCP阶段。配置完成后需要重置链路才能看到完整的认证过程。操作方式是在接口视图下执行shutdown然后undo shutdown重启PPP协商流程。验证结果时在AR2上执行display ppp重点关注一下内容PPP connection state: Up Authentication protocol: PAP LCP opened, IPCP opened如果认证失败LCP会保持open但IPCP不会打开物理层状态显示up但链路层协议状态会变为down此时抓包能看到PAP层的Nak报文。4.3 PAP明文传输的抓包验证如果条件允许可以在AR2的串行接口上配置流量镜像或者把链路接到交换机的镜像端口上抓包这样能直观看到PPP报文内容。用Wireshark抓取PPP协商过程的报文时过滤表达式可以用ppp然后重点观察协议类型为0xC023的PAP报文。展开报文内容用户名和密码字段都是明文可见的这就是我强调PAP不能用于生产环境的原因。Wireshark对PPP协议有比较完善的解析器帧里的地址字段0xFF、控制字段0x03、协议字段0xC023都会直接标注出来非常适合做协议学习。5. CHAP认证配置案例5.1 认证端开启CHAP认证的完整配置CHAP认证在eNSP上的配置形式和PAP类似但认证交互逻辑有本质区别。# AR2认证端 system-view sysname AR2 interface Serial 1/0/0 link-protocol ppp ip address 12.1.1.2 24 ppp authentication-mode chap quit # AR1被认证端 system-view sysname AR1 interface Serial 1/0/0 link-protocol ppp ip address 12.1.1.1 24 ppp chap user huawei ppp chap password cipher huawei123 quit注意配置差异认证端AR2只需要在接口下配置ppp authentication-mode chap不需要额外的local-user配置因为CHAP认证默认使用设备上配置的本地用户名和密码。被认证端AR1需要配置ppp chap user和ppp chap password。这里的用户名要和认证端本地用户一致如果认证端没有配置任何本地用户默认情况下CHAP认证会因为找不到可验证的用户名而失败。实际测试中如果AR2没有创建local-userAR1配置chap user后协商会失败需要在AR2上添加如下配置aaa local-user huawei password cipher huawei123 local-user huawei service-type ppp quit也就是说CHAP认证虽然交互过程不传明文密码但同样依赖认证端本地用户数据库做校验。5.2 CHAP的挑战响应过程与安全优势CHAP的三次握手过程如下认证端AR2向被认证端AR1发送一个随机挑战值ChallengeAR1用自己的密码和挑战值做MD5计算返回一个响应值ResponseAR2用本地保存的密码和同一个挑战值做MD5计算与收到的响应比对一致则认证成功这个过程里最关键的点在于密码始终不以明文形式在线路上传输挑战值又不是固定的所以同一份响应数据不能在另一条链路上重放。实际抓包时你会看到CHAP报文被封装在协议类型0xC223的帧中。第一帧Challenge里能直接看到挑战值和ID第二帧Response里看到的是一串哈希值密码本身不可见。这就是工程上推荐使用CHAP的原因。5.3 场景延伸PPP认证在专线对接中的应用配置层面CHAP只比PAP多了一步“挑战值”的计算与比对但安全等级完全不同。在真实专线对接场景中运营商侧如果是华为设备企业侧是其他厂商设备CHAP的兼容性通常也优于PAP。很多老工程师一看到串口链路起不来第一反应就是检查认证模式的配置尤其是两端设备是否都配了相同的CHAP用户名和密码。这个基本功在做跨厂商设备对接时非常有价值。有一种常见的误区认为CHAP配置后密码就不会以任何形式出现在设备配置里。实际上在eNSP中执行display current-configuration时本地用户的密码仍然会以密文形式显示但接口下的ppp chap password cipher同样是密文存储这是设备安全配置的基本要求和密码是否明文传输不是同一个层面的问题。6. 综合实验中的故障排查与抓包验证6.1 链路协商不上的常见原因分析做这个实验时我总结出几个高频故障点每个都和PPP协议的某一层机制相关。第一类物理链路状态是up但链路层协议状态是down。最常见的配置问题是两端IP地址不在同一网段这种情况LCP可以协商成功但IPCP会因为地址冲突或不可达而失败。排查命令是display ip interface brief先确认两端接口地址是否在同一子网。第二类接口下配置了PAP认证但被认证端没有配置PAP用户名密码。这时链路LCP协商会显示Ack但验证阶段会收到认证失败的Nak接口输出里会看到PAP authentication failed提示。排查时用display ppp查看协商状态重点看Authentication protocol字段。第三类CHAP认证的用户名或者密码不一致。这类问题最隐蔽因为LCP依然是开着的IPCP却一直不动如果经验不够很容易误判为IP地址配置问题。排查时使用debugging ppp chap打开调试开关可以看到完整的Challenge、Response交互过程问题立刻定位。6.2 抓包验证PPP协商过程的操作方法在eNSP环境中最方便的抓包方式有两种。一种是右键设备接口选择“开启抓包”直接在eNSP内部启动Wireshark另一种是在拓扑中增加Cloud设备通过物理网卡桥接做外部抓包。前者更简洁后者更适合多接口并发抓包分析。无论采用哪种方式观察的重点都应该是三层数据包的时间顺序LCP Configure-Request一方发起链路参数协商LCP Configure-Ack对方确认参数Auth协议报文PAP或CHAP认证交互IPCP Configure-Request请求网络层参数IPCP Configure-Ack对方确认IP参数如果认证失败第3步后面会直接出现Terminate-Request不会有第4步。这个顺序是排查PPP链路故障的黄金路径。6.3 常用排查命令与日志速查表为了效率这里总结了几个常用排查命令和对应的判断结果实际工作时可以直接对照使用。display interface Serial 1/0/0 display ppp display ip interface brief display current-configuration interface Serial 1/0/0 debugging ppp alldisplay interface Serial 1/0/0输出项 排查意义 Physical layer is up 物理链路正常 Line protocol is down LCP或IPCP未协商成功 LCP opened LCP协商完成 IPCP opened IPCP协商完成这些命令是实验和工作中反复要用到的建议把每一步的配置过程都养成习惯出现问题时按“物理层→LCP→认证→IPCP→业务连通性”的顺序逐层排查效率最高。7. 从实验到实战PPP配置中的避坑心得实验做完一轮之后有几点体会比较深。第一eNSP的模拟链路毕竟和真实设备存在差异。比如真实设备的串口需要配置时钟频率eNSP里不需要但这个差异不影响协议行为的学习。做实验时不需要过分纠结这些细节重点是理解协议本身的报文交互流程。第二认证配置里最容易出问题的是用户名不匹配而不是密码不匹配。不少初学者会把注意力放在密码上但实际报错往往是找不到对应的本地用户。配置时建议先在认证端用display local-user确认用户存在再检查被认证端的用户名拼写。第三所有认证配置修改后一定要shutdown再undo shutdown让链路重新协商否则你可能在确认旧状态而不是新配置的结果。这一点我在实际工作中帮同事排查时经常发现。第四如果打算做更复杂的综合实验可以考虑在双路由中间插入一台交换机做二层透传验证PPP链路跨越二层网络时的表现。这个场景在真实专线中非常常见但很多教程都没有覆盖值得自己动手试一下。关于后续扩展还有一个方向可以玩用eNSP的帧中继接口模拟多链路PPP或者把PPP链路的一端换成USG防火墙验证防火墙和路由器之间的PPP对接。这些实验都能强化对广域网协议栈的理解。最后分享一个小技巧在eNSP里做PPP实验时把日志同步功能打开设备的每个协议状态变化都会实时显示在控制台对理解协商过程很有帮助。配置完成后按term monitor开启实时日志再重置链路你就能在屏幕上看到LCP从request到ack再到IPCP协商的完整过程这种直观反馈比任何文档都更有说服力。