企业官网建设流程全解析

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协议的设计思路是分层协作，它不像以太网那样一个帧头打天下，而是把链路建立、参数协商、网络层协议接入拆成三个相对独立的部分。

• LCP（Link Control Protocol，链路控制协议）：负责链路的建立、配置、测试和拆除，比如协商MRU（最大接收单元）、链路质量检测、认证协议选择，都在这一层完成。
• NCP（Network Control Protocol，网络控制协议）：负责协商网络层协议参数，最常见的例子是IPCP，它负责给链路对端分配IP地址、协商IP压缩等参数。
• 认证协议（PAP/CHAP）：LCP协商阶段会确定要不要认证、用哪种认证方式，认证通过之后链路才真正进入可用状态。

这个分层设计带来的直接影响是：PPP链路既可以承载IPv4，也可以承载IPv6甚至其他网络层协议，只要对应启用不同的NCP即可，LCP部分完全不用动。理解这一点，对后面排查故障很有帮助——链路拨不上号，先看LCP阶段，再看认证，最后看IPCP，顺序不能乱。

2.2 PPP帧格式与报文交互流程

PPP的数据帧在HDLC-like framing下的结构是：标志字段（0x7E）、地址字段（0xFF）、控制字段（0x03）、协议字段、信息字段、FCS校验。

协议字段是整个帧格式里最关键的部分，它决定了信息字段里装的是什么类型的数据：

• 0xC021：LCP报文
• 0xC023：PAP报文
• 0xC223：CHAP报文
• 0x8021：IPCP报文
• 0x0021：IPv4数据报文

抓包时只要看到协议字段是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 opened：LCP协商已完成
• IPCP opened：IPCP协商已完成

如果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 Huawei@123这类带特殊字符的密码即可。

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-user，AR1配置chap user后协商会失败，需要在AR2上添加如下配置：

aaa local-user huawei password cipher huawei123 local-user huawei service-type ppp quit

也就是说，CHAP认证虽然交互过程不传明文密码，但同样依赖认证端本地用户数据库做校验。

5.2 CHAP的挑战响应过程与安全优势

CHAP的三次握手过程如下：

1. 认证端AR2向被认证端AR1发送一个随机挑战值（Challenge）
2. AR1用自己的密码和挑战值做MD5计算，返回一个响应值（Response）
3. AR2用本地保存的密码和同一个挑战值做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设备，通过物理网卡桥接做外部抓包。前者更简洁，后者更适合多接口并发抓包分析。

无论采用哪种方式，观察的重点都应该是三层数据包的时间顺序：

1. LCP Configure-Request：一方发起链路参数协商
2. LCP Configure-Ack：对方确认参数
3. Auth协议报文（PAP或CHAP）：认证交互
4. IPCP Configure-Request：请求网络层参数
5. 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 all

display 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协商的完整过程，这种直观反馈比任何文档都更有说服力。