企业官网建设流程全解析

备考HCIA、HCIP，或者正在啃网络工程教材的朋友，大概率都被这三个缩写折磨过：PAP、CHAP、GRE。它们分别是PPP链路里的两种认证方式，和一个非常常见的隧道封装协议。我当年在eNSP里练第一个串口实验时，PAP配置敲完链路协议死活不起来，后来才发现是认证方的AAA里少建了一条本地用户；练到GRE的时候，隧道接口地址都配好了，又因为目的地址没有路由一直Protocol down。这篇文章我把这三块内容串成一套完整的eNSP练习，从拓扑规划、命令逐条拆解到问题排查都会讲到。按步骤做完，你对PPP认证和GRE隧道就不会停留在“背命令”的水平，而是真正理解数据包是怎么在链路上完成认证、又是怎么被封装穿越中间设备的。

1. 这三个知识点到底是什么，为什么值得练

1.1 一张表看懂PAP、CHAP、GRE

先说清楚这三个东西各自的位置。PPP是数据链路层协议，工作在点对点链路上，它有两个阶段很重要：先是LCP（链路控制协议）协商参数，然后才是NCP（网络控制协议）比如IPCP分配IP。认证就发生在LCP协商阶段。PAP和CHAP都是PPP认证协议，区别在于认证过程和安全性完全不在一个档次。

GRE是三层的隧道协议，它干的事情比较“暴力”：把一个网络层协议的报文直接塞进另一个网络层协议里。最典型的场景是IPv4-in-IPv4，也就是把内层IP报文外面再套一层IP头，看起来就像把一个快递盒装进了另一个更大的快递盒。盒子外面的地址是隧道的物理出入口，盒子里面装的才是真正要送的业务流量。

记住一点：PAP和CHAP是“链路能不能通”的守门员，GRE是“流量怎么绕路过去”的搬运工。三者虽然不是一个层面的东西，但在一套企业网拓扑里经常同时出现，所以放到一起练习特别合适。

1.2 这套练习适合谁，练完能获得什么

如果你是下面这几类人，这套练习建议完整过一遍：

• 备考HCIA、HCIP的人。PPP认证和GRE隧道几乎每个版本考题里都占一席之地，eNSP实验题最喜欢在这两个知识点上挖坑。
• 刚学完计算机网络理论、想在模拟器里验证一遍“链路层认证”和“隧道封装”原理的学生。
• 做企业网运维、偶尔要翻串口链路和隧道配置的工程师，实操里PPP链路故障排查是基本功。
• 准备网络岗面试，被问到“PAP和CHAP区别”“GRE隧道建立条件”这类题的人。

练完这套内容，你的能力变化应该是这样的：能独立在一对串口链路上配置PAP和CHAP认证，并且能清楚说出两种认证握手过程的安全性差异；能独立配置GRE隧道，理解source和destination的含义、隧道建立的前提条件；遇到“Line protocol down”“Tunnel protocol down”这类问题，知道该往哪个方向排查，而不是盲改配置。

1.3 eNSP环境准备与三个新手坑

练习平台就是华为官方的eNSP（Enterprise Network Simulation Platform），免费，模拟AR路由器、交换机等设备。PAP/CHAP和GRE实验用AR1220或AR2220都行，串口数量足够。

先提醒三个新手最容易踩的坑：

第一个是连线选错线缆。eNSP里路由器串口只能接串行线，很多人图方便直接选以太网线，结果两台设备物理层永远是down。连线时接口类型一定要选对，Serial口对Serial口，GE口对GE口。

第二个是设备刚启动时接口默认处于shutdown状态。在eNSP里新加的设备，接口需要手动undo shutdown才能UP。很多教程默认你懂这个，其实新手卡在这里半天很正常。

第三个是接下来的调试环节要用的：如果你敲了debugging命令却看不到任何输出，大概率是没开terminal monitor和terminal debugging。后面第五节会详细讲。

2. 实验拓扑设计与PAP认证配置

2.1 拓扑怎么搭，地址怎么规划

先搭一个最基础的两台路由器串口互联拓扑，专门练PAP和CHAP：

R1 ---(Serial)--- R2

地址规划很简单：

先把两台设备的hostname和串口IP配好。这里有个细节：华为串口上配置IP地址，掩码建议写点分十进制，比如255.255.255.252，别图省事写30，部分版本对简写支持不好。

<Huawei>system-view [Huawei]sysname R1 [R1]interface Serial 1/0/0 [R1-Serial1/0/0]link-protocol ppp [R1-Serial1/0/0]ip address 13.1.1.1 255.255.255.252 [R1-Serial1/0/0]undo shutdown [R1-Serial1/0/0]quit

R2上同样操作，IP换成本端13.1.1.2。配完后用display ip interface brief确认两个串口物理和协议都是UP。此时还没有配置任何认证，PPP默认是不认证的，所以两边直接就能通。先ping一下，确认底层链路OK，再加认证，这是后面所有排查的基础思路。

2.2 PAP配置命令逐条拆解

设计R1为认证方，R2为被认证方。这是最常规的做法：接入设备或者中心设备认证对端。

R1（认证方）配置如下：

[R1]interface Serial 1/0/0 [R1-Serial1/0/0]link-protocol ppp [R1-Serial1/0/0]ppp authentication-mode pap [R1-Serial1/0/0]quit [R1]aaa [R1-aaa]local-user R2 password simple 123456 [R1-aaa]local-user R2 service-type ppp

逐条说清楚为什么要这么配：

ppp authentication-mode pap的作用是把本端变成认证方。一旦开启，后面LCP协商的时候，本端就会要求对端提交PAP凭据，对端拿不出来或者不对，链路协议直接down。注意这条命令在接口视图下配置，只对这一个串口生效。

local-user R2 password simple 123456在AAA本地用户库里创建了一个用户，用户名是R2，密码是123456。PAP被认证方发送的是“用户名R2+密码123456”的组合，认证方拿着这个用户名去本地用户库里找对应条目标密码，两边一致才放行。这里的用户名为什么叫R2而不是R1？因为这是给对端准备的通行证，对端声称自己是谁，库里就要有谁。

local-user R2 service-type ppp限定了这个用户只能用于PPP服务。不写这条在一些版本里认证会直接失败，或者会有提示服务类型不符，建议养成习惯都写上。

R2（被认证方）配置如下：

[R2]interface Serial 1/0/0 [R2-Serial1/0/0]link-protocol ppp [R2-Serial1/0/0]ppp pap local-user R2 password simple 123456 [R2-Serial1/0/0]quit

ppp pap local-user就是被认证方向对端主动上报自己的身份。它把“用户名R2、密码123456”以明文的形式放进PAP报文发给认证方。这里就能看出PAP的安全问题：抓个包就能看到用户名和密码，跟把银行密码写在纸条上递给柜员没什么区别。

另外提一句：如果想做双向认证，两个接口都开ppp authentication-mode pap，两边都建好对端local-user就行。练完单向认证，建议自己把双向PAP也试一遍，理解会更透。

2.3 验证PAP是否生效

配置完成后，关键看串口状态：

<R1>display interface Serial 1/0/0

重点看Physical layer和Line protocol两行。物理层UP说明线缆连接没问题，协议层UP说明LCP协商完成、认证通过。如果认证配置出错，你会看到Physical layer是up，Line protocol是down（protocol），这就说明卡在LCP认证阶段了。

想看得更细，打开调试信息：

<R1>terminal monitor <R1>terminal debugging <R1>debugging ppp all

然后R2上执行shutdown再undo shutdown，强制链路重新协商一遍，R1上就能看到PAP报文的交互过程。看到认证失败的具体原因后，再对照AAA里的配置去改。

2.4 PAP为什么被CHAP取代

PAP最大的软肋有两个：一是用户名密码明文传输，抓包工具就能直接看到；二是它没有挑战机制，密码一旦泄露就能被重放攻击。而且PAP可以在整个会话过程中反复发送认证请求，相当于给暴力破解留了后门。所以现在真实网络里PAP基本只出现在老式拨号环境或者内部低安全需求的场景中，真正上生产链路建议用CHAP。

3. CHAP认证配置与两种模式的差异

3.1 CHAP配置命令逐条拆解

拓扑不变，还是R1认证R2。先改认证方式：

[R1]interface Serial 1/0/0 [R1-Serial1/0/0]undo ppp authentication-mode pap [R1-Serial1/0/0]ppp authentication-mode chap [R1-Serial1/0/0]quit

AAA里的本地用户保留，不需要改动，因为CHAP认证同样要拿用户名去库里查密码：

[R1]aaa [R1-aaa]local-user R2 password simple 123456 [R1-aaa]local-user R2 service-type ppp

R2这边配置也很简短：

[R2]interface Serial 1/0/0 [R2-Serial1/0/0]undo ppp pap local-user [R2-Serial1/0/0]ppp chap local-user R2 password simple 123456 [R2-Serial1/0/0]quit

这里有个版本兼容问题：有些VRP版本支持ppp chap local-user R2 password simple 123456这种一行写法，老一点的版本可能要把用户名和密码拆成两条：

[R2-Serial1/0/0]ppp chap user R2 [R2-Serial1/0/0]ppp chap password simple 123456

两种写法含义一样，如果敲第一条提示无法识别，就换第二种。

CHAP有个特别容易忽略的关键点：密码虽然不上链路传输，但两边的密码值必须完全一致。因为后面CHAP计算散列值时用的就是这个共享密码，任何一个字符不匹配，计算结果就对不上，认证必然失败。

3.2 CHAP的握手过程到底发生了什么

CHAP全称里有个“Challenge”，核心就是挑战值。完整过程分四步：

第一步，链路UP进入LCP协商后，认证方R1生成一个随机的挑战值，构造Challenge报文发给R2。报文中还带着R1的用户名。

第二步，R2收到Challenge报文后，用自己的共享密码、接收到的挑战值、自己的用户名一起做MD5计算，把计算结果作为Response报文回给R1。

第三步，R1收到Response后，也拿本地用户库里查到的R2的密码、同一个挑战值、R2的用户名做同样的MD5计算，然后比对两边结果。

第四步，一致就发Success，不一致发Failure。只有认证通过后，LCP才算协商完成，链路协议层才会UP。

这里有个细节值得注意：整个过程中，真正的密码从来不出现在链路上，线上跑的只有挑战值、用户名和散列结果。就算抓包抓到所有交互报文，也无法直接还原出密码。而且CHAP会在认证成功后周期性重新发起挑战，每次挑战值随机，即使抓到了某一次的Response，下一次也用不上，这就杜绝了重放攻击。

用生活类比来解释就是：PAP像你直接把银行卡密码写在纸上递给柜员；CHAP像银行给你发一条随机验证码，你把“验证码+约定的口令”算出一个结果回传，银行自己在后台也算一遍比对。约定口令从头到尾没有出现在对话里，这才是安全的设计。

3.3 PAP和CHAP到底差在哪

把两个协议放在一起对比，你会发现配置上的差异其实不大，本质差异全在流程上：

如果面试或者考试里让你选，现代网络环境默认答案都是CHAP。但如果遇到老设备对接或者特定环境只支持PAP，那也只能用PAP，这种情况下建议配合链路本身的物理安全和访问控制一起考虑。

3.4 双向CHAP认证的小补充

刚才练的是单向认证：R1认证R2。实际专线互联场景中，两边都有确认对端身份的需求，这时可以做双向认证。配置方法很简单：R1和R2的串口都开ppp authentication-mode chap，然后在彼此的AAA里都建好对端用户名和密码，两边都配置ppp chap local-user。

双向CHAP有一个经典坑：两边的ppp chap local-user用户名最好分别命名为对方，但密码要保持一致。比如R1用ppp chap local-user R2，R2用ppp chap local-user R1，R1的AAA里要有用户R1和R2，R2的AAA里也要有用户R1和R2。这种对称配置比较容易乱，建议画一张表格记录清楚再动手。

4. GRE隧道配置与路由联动

4.1 把实验升级到GRE隧道

接下来把拓扑扩成三台路由器，做GRE隧道练习。在刚才R1和R2的基础上，增加一台R3与R2通过以太网互联，再把R1、R3的LoopBack地址用作隧道端点。业务网段分别挂在R1和R3下，模拟两个分部要通过骨干网互联的场景。

完整地址规划：

隧道源和目的为什么选LoopBack地址而不是物理接口地址？因为LoopBack接口永远不会down，设备只要不掉电就一直可用。如果用物理接口作为隧道源，物理接口一旦down，隧道跟着就断了。生产环境的GRE隧道几乎都用LoopBack地址做端点，这是经验之谈。

4.2 隧道接口配置逐条拆解

先配R1：

[R1]interface LoopBack0 [R1-LoopBack0]ip address 1.1.1.1 255.255.255.255 [R1-LoopBack0]quit [R1]interface GigabitEthernet0/0/1 [R1-GigabitEthernet0/0/1]ip address 192.168.1.1 255.255.255.0 [R1-GigabitEthernet0/0/1]quit [R1]interface Tunnel0/0/0 [R1-Tunnel0/0/0]ip address 10.0.13.1 255.255.255.252 [R1-Tunnel0/0/0]tunnel-protocol gre [R1-Tunnel0/0/0]source 1.1.1.1 [R1-Tunnel0/0/0]destination 3.3.3.3 [R1-Tunnel0/0/0]quit

R3这边对称配置：

[R3]interface LoopBack0 [R3-LoopBack0]ip address 3.3.3.3 255.255.255.255 [R3-LoopBack0]quit [R3]interface GigabitEthernet0/0/1 [R3-GigabitEthernet0/0/1]ip address 192.168.3.1 255.255.255.0 [R3-GigabitEthernet0/0/1]quit [R3]interface Tunnel0/0/0 [R3-Tunnel0/0/0]ip address 10.0.13.2 255.255.255.252 [R3-Tunnel0/0/0]tunnel-protocol gre [R3-Tunnel0/0/0]source 3.3.3.3 [R3-Tunnel0/0/0]destination 1.1.1.1 [R3-Tunnel0/0/0]quit

重点解释两条命令：

tunnel-protocol gre指定隧道封装协议。华为路由器Tunnel接口支持多种协议，GRE是通用性最强的一种，把这条显式写出来可以避免踩到某些版本默认值不同的坑。

source和destination分别指定隧道外层IP头的源地址和目的地址。source可以写接口名，比如LoopBack0，也可以直接写IP；destination必须写IP。隧道建立的前提条件就是：从source到destination的路由必须存在且可达。这句话是判断隧道故障的最重要的原则，隧道起不来，九成是底层路由问题，先别怀疑隧道配置本身。

4.3 隧道建起来之前，先让底层路由通

在配置隧道之前，R1根本没有去往3.3.3.3的路由，所以隧道肯定起不来。先配好底层路由。

方法一，最简单的静态路由：

[R1]ip route-static 23.1.1.0 255.255.255.0 13.1.1.2 [R1]ip route-static 3.3.3.3 255.255.255.255 23.1.1.3 [R3]ip route-static 13.1.1.0 255.255.255.0 23.1.1.2 [R3]ip route-static 1.1.1.1 255.255.255.255 23.1.1.2

注意R1去3.3.3.3的路由不能只写一条跳到23.1.1.3就完事。R1到23.1.1.3还有一跳要到13.1.1.2，所以23.1.1.0网段的路由也要有。路由是逐跳的，一个中间网段断了，后面的目标地址都到不了。

方法二，在底层链路上跑OSPF，让LoopBack地址自动互通：

[R1]ospf 1 [R1-ospf-1]area 0 [R1-ospf-1-area-0.0.0.0]network 13.1.1.0 0.0.0.3 [R1-ospf-1-area-0.0.0.0]network 1.1.1.1 0.0.0.0 [R2]ospf 1 [R2-ospf-1]area 0 [R2-ospf-1-area-0.0.0.0]network 13.1.1.0 0.0.0.3 [R2-ospf-1-area-0.0.0.0]network 23.1.1.0 0.0.0.3 [R3]ospf 1 [R3-ospf-1]area 0 [R3-ospf-1-area-0.0.0.0]network 23.1.1.0 0.0.0.3 [R3-ospf-1-area-0.0.0.0]network 3.3.3.3 0.0.0.0

配完之后先验证：在R1上ping 3.3.3.3，通了再看隧道。隧道接口状态怎么看？display interface Tunnel 0/0/0，Physical层UP说明隧道接口存在且本端配置完整，Line protocol层UP才说明隧道真正建立起来了，也就是说源到目的的路由没问题、封装对端能正常响应。

4.4 在GRE隧道上跑OSPF联通业务网段

隧道建立起来之后，接下来要做的就是把A网段和B网段通过隧道接通。

最简单的方式是用静态路由指向隧道：

[R1]ip route-static 192.168.3.0 255.255.255.0 Tunnel0/0/0 [R3]ip route-static 192.168.1.0 255.255.255.0 Tunnel0/0/0

但更推荐练一下在隧道上跑OSPF，因为这里能体现出GRE的一个重要特性：GRE可以封装组播报文。OSPF建立邻居关系需要发送组播Hello报文，普通IP-in-IP隧道不支持组播，而GRE支持，所以OSPF能直接在隧道上正常建邻。

在R1和R3上把隧道网段和业务网段都宣告进OSPF：

[R1]ospf 1 [R1-ospf-1]area 0 [R1-ospf-1-area-0.0.0.0]network 10.0.13.0 0.0.0.3 [R1-ospf-1-area-0.0.0.0]network 192.168.1.0 0.0.0.255 [R3]ospf 1 [R3-ospf-1]area 0 [R3-ospf-1-area-0.0.0.0]network 10.0.13.0 0.0.0.3 [R3-ospf-1-area-0.0.0.0]network 192.168.3.0 0.0.0.255

然后验证：

<R1>display ospf peer brief <R1>display ip routing-table 192.168.3.0 <R1>ping -a 192.168.1.1 192.168.3.1

看到192.168.3.0/24的路由下一跳指向Tunnel0/0/0、ping能通，这套GRE练习就算真正闭环了。此时可以做一个抓包或者debug，看数据包在R1出接口上是被多套了一层IP头的。理解这一点，比记住所有命令都重要。

4.5 GRE封装开销与MTU问题

GRE封装会给原始报文增加多少字节？标准GRE头是4字节，再套一层IPv4头是20字节，总共24字节。如果还开启了checksum、key等可选字段，开销更大。

这意味着什么？假如R1和R2之间的物理链路MTU是1500字节，那隧道内层IP报文的最大尺寸实际只有1476字节，因为还要给外层IP头和GRE头留位置。练习时如果你直接ping大包，比如ping -s 1500 192.168.3.1，大概率会失败或者出现分片。这不是隧道配置错了，是MTU的问题。

生产环境遇到这种情况，要么调低隧道接口的MTU，要么在主机侧调整TCP MSS。但在eNSP里，重点不是把MTU调好，而是理解封装开销这个概念。知道GRE多了24字节，你就知道为什么同样一条链路，跑隧道和跑裸流量在MTU上的表现不一样。这个知识点面试也常问。

5. 常见问题与排查技巧实录

5.1 问题速查表

把练习里最容易踩的坑整理成一张表，遇到对应现象直接对照：

5.2 PAP认证失败的排查实录

一个典型场景：R1配了ppp authentication-mode pap和AAA用户，R2配了ppp pap local-user R1 password simple 123456，但链路协议层就是起不来。

排查第一步，看串口状态确定问题阶段：display interface Serial 1/0/0，物理UP、协议DOWN，锁定是LCP认证阶段挂了。

第二步，删掉AAA里的用户，重新精确配置一遍，特别注意用户名大小写和密码是否带空格。PAP认证比对的是完整凭据，一个字符不对都会失败。

第三步，开debug看细节：

<R1>terminal monitor <R1>terminal debugging <R1>debugging ppp all

然后在R2上shutdown再undo shutdown串口，R1上就能看到认证失败的具体交互。多数时候原因就那么几种：用户不存在、密码不匹配、service-type不对。改完再触发一次链路协商，基本就能解决。

这里有个我踩过的坑：早期练习图省事，把R2的ppp pap local-user用户名写成了自己设备名R2，但R1的AAA用户建的是R1，两边永远对不上。记住，被认证方发送的用户名必须和认证方AAA里创建的用户名一致，跟设备本身叫什么没关系。

5.3 CHAP认证失败的排查实录

CHAP最常见的问题是“密码明明设置的一样，却认证失败”。这里大概率是调整配置后没有触发重新协商。CHAP只有在链路重新协商时才会重新认证，你改了配置，但接口还是原来的会话状态，自然不会生效。解法很简单：把串口shutdown再undo shutdown，强制LCP重新协商。

第二个常见原因是密码模式问题。练习时图方便用password simple，配置看起来清清楚楚。但如果你用了password cipher，保存后的配置会显示成密文串。这时候把配置导出来复制到另一台设备比对，看似一样的密文可能因为算法和随机因子不同，实际对应的明文并不一致。练习阶段我建议一律用simple，等理解了原理再试cipher。

第三个原因是用户名的方向性。CHAP认证时，被认证方用ppp chap local-user声明的用户名，必须和认证方AAA里的用户名完全一致。如果你两边都开了认证，每个设备需要同时拥有本端用户和对端用户两条记录，少一条、名字错一个字母，都会协商失败。

5.4 GRE隧道起不来的排查实录

隧道接口物理UP、协议DOWN，先别动隧道配置，按这个顺序排查：

第一步，ping隧道目的地址。在R1上ping 3.3.3.3。这个地址是R3的LoopBack，ping不通说明底层路由有问题，隧道必然起不来。

第二步，查路由表。display ip routing-table 3.3.3.3，看看有没有这条路由、下一跳是谁。没有就往底层路由方向查，有但下一跳错误就改路由。

第三步，核对隧道本端配置。display current-configuration interface Tunnel 0/0/0，确认source和destination没写反，IP地址没配错网段。

第四步，检查源接口状态。source用的是LoopBack0，看看这个接口是不是被shutdown了。LoopBack地址不存在，隧道也就没有源地址可用。

还有一种情况：隧道配置没问题、路由也通，但协议层就是不起来。检查一下两端Tunnel接口的IP地址是不是同一个网段。GRE隧道是两个虚拟接口之间通信，两端地址不在同一网段，OSPF什么的一起也会受影响。

5.5 eNSP特有的坑

除了协议本身的问题，eNSP还有一些特性会让新手抓狂。

设备刚添加进拓扑，接口默认shutdown。每台路由器的每个接口都要手动undo shutdown，只有LoopBack接口天然可用。

串口连线必须选串行线，接口类型选错物理层永远起不来。这个前面说过，但值得再强调一次，因为这是所有串口实验失败的第一大原因。

eNSP的调试输出需要同时开terminal monitor和terminal debugging，光开一个会看不到信息。另外调试功能用完记得关掉，undo debugging ppp all，不然eNSP会变得越来越卡，甚至日志刷屏。

交换机的Tunnel支持问题：普通二层交换机没有Tunnel接口，如果想做三层隧道实验，必须用路由器或者三层交换机。eNSP里默认的S5700是三层交换机，但S3700这种老型号可能不支持，选设备时看清楚。

6. 最后再补充几个实操细节

这套练习做完之后，说几个我在实际操作中总结的细节，能帮你少走很多弯路。

第一个是“先通后认证”的配置顺序。无论PAP还是CHAP，先把链路在不加认证的情况下配到能ping通，再加认证，每次改动后触发重新协商去验证。这样一旦出问题，你能立刻判断是基础配置的问题还是认证本身的问题。不要一上来就把所有配置全敲完，出问题都不知道从哪查。

第二个是修改认证方式后一定要强制重新协商。最可靠的办法是把串口shutdown再undo shutdown，或者直接重启接口。只改配置不重新协商，新配置可能不会立即生效，会让你误以为配置写错了。

第三个是每一阶段完成后保存配置。eNSP里执行save，把配置文件备份出来。这样练到后面改坏了，可以快速恢复上一阶段的基线，不用一台一台重新敲。这也是真实网络运维的习惯，配置变更前先留基线。

如果想继续深入，这套实验还有几个很好的扩展方向：把PAP和CHAP改成双向认证，观察两种协议在双向模式下的报文交互；在R1和R2的PPP链路上再建一个GRE隧道，源和目的直接使用串口IP，观察GRE报文是如何被PPP帧封装的，这个练习对理解“封装套封装”非常有帮助；给隧道接口加上keepalive，比如keepalive 10 3，然后把中间链路断开，观察隧道协议层多久变为DOWN。这些扩展做完，你对PPP认证和GRE隧道这几块内容的理解会再上一个台阶，碰到相关面试题基本可以从容应对。

我个人练下来的感受是，PAP、CHAP、GRE这几个知识点，最难的不是命令，而是脑子里要有一张图：链路层认证卡在LCP协商阶段，隧道封装发生在网络层，两者一上一下，共同保证数据能在复杂的网络环境里安全、灵活地传输。把这张图刻在脑子里，配置和排错就都有方向了。