企业官网建设流程全解析

我很久没在模拟器上正经排过这三种协议了，正好最近项目里有人问起 PAP、CHAP，顺带还要把 GRE 隧道也练了，我一口气把 eNSP 里的实验环境搭起来从头跑了一遍。说实话，这几种协议单独看配置都不难，但把它们串在一起练，才是真正理解 PPP 认证和隧道封装逻辑的好路子。这篇文章就把我这次的练习过程完整记录下来，从协议原理到 eNSP 里的详细配置，再到我踩过的几个坑，一次性说清楚。

1. 实验内容设计与整体思路

1.1 为什么把 PAP、CHAP 和 GRE 放在一起练

很多刚接触网络的朋友容易把 PAP、CHAP、GRE 当成三个孤立的知识点，背完命令就完事了。但实际上，它们在企业网络的远程接入场景里经常是前后脚出现的关系。PAP 和 CHAP 是 PPP 协议框架下的两种认证方式，解决的是“链路对端是不是合法设备”的问题；而 GRE 解决的是“在公网或者不相关的网络上，怎么把私网流量安全地封装起来传过去”的问题。两者结合的典型场景就是：分支机构通过运营商线路拨号接入总部，先用 PPP 完成链路认证，再在认证通过的链路上建立 GRE 隧道，跑私网路由。

这样组合练习的价值在于，你可以完整地走一遍“物理链路建立 → 链路层认证 → 网络层隧道 → 路由打通”的全流程。单独练任何一个协议，你只能看到单点配置，合在一起你才能意识到：PPP 认证失败的时候，GRE 隧道根本起不来；GRE 隧道源地址配错，OSPF 邻居也就一直 Down。这些因果关系，是分开练根本体会不到的。

本次实验我用的是华为 eNSP 模拟器，因为它在国内用得最广，而且对 PPP 和 GRE 的支持非常完整，命令行风格也和生产环境保持一致。拓扑结构设计得很简单：三台路由器串联，R1 和 R2 之间跑 PPP 链路，配置 PAP 或者 CHAP 认证；R2 和 R3 之间也通过 PPP 互联，但认证方式做成双向 CHAP。然后 R1 和 R3 之间建立一条 GRE 隧道，隧道源和目的分别指向两台路由器在 PPP 链路上分配的地址，最后在隧道上跑 OSPF，实现两端私网网段互通。

1.2 设备选型与拓扑规划要点

eNSP 里的路由器选型我建议直接用 AR3260，别用 AR201 这种低端型号。原因很简单，AR3260 对 PPP 多链路、GRE 隧道、OSPF 的模拟支持最完整，跑起来也稳定，AR201 在配置 GRE 隧道后偶尔会出现接口 up 但 ping 不通的奇怪现象，排查起来非常浪费时间。

接口规划上，我给三台路由器分配的链路如下：

• R1 的 Serial 接口（S1/0/0）连接到 R2，链路编号为 PPP 链路 A，R1 作为认证方，先练习 PAP，再改成 CHAP。
• R2 的 Serial 接口（S1/0/0）连接到 R1，R2 的 Serial 接口（S1/0/1）连接到 R3 的 Serial 接口（S1/0/0），这两条 PPP 链路独立配置。
• R3 的 Serial 接口（S1/0/0）连接 R2，同时 R3 作为 GRE 隧道的对端，隧道的源地址使用其 PPP 接口地址。

地址规划上，我给 PPP 链路 A 分配了 10.0.12.0/30 网段，R1 是 10.0.12.1，R2 是 10.0.12.2。PPP 链路 B（R2 到 R3）分配了 10.0.23.0/30 网段，R2 是 10.0.23.2，R3 是 10.0.23.3。两个私网网段分别挂在 R1 的 Loopback 0（192.168.1.1/24）和 R3 的 Loopback 1（192.168.3.1/24）上，模拟总部和分支的内部网络。GRE 隧道地址用 172.16.0.0/30 网段，R1 隧道口配 172.16.0.1，R3 隧道口配 172.16.0.2。

有个细节值得提醒：PPP 链路地址不要用 /24 这种大网段，用 /30 是标准做法。因为 PPP 是点对点链路，只有两个设备，/30 完全够用，还能避免路由表里出现不必要的广播网段条目。

2. PAP 和 CHAP 认证机制深度拆解

2.1 PAP 两次握手认证的优缺点

PAP（Password Authentication Protocol）是 PPP 协议族里最早出现的认证方式，它的工作过程可以用四个字概括：明文直传。链路建立起来之后，被认证方直接把用户名和密码以明文形式发送给认证方，认证方检查本地数据库，匹配就给通过，不匹配就拒绝。整个过程只有两次握手：第一次是被认证方发送认证请求，第二次是认证方返回确认或拒绝。

我在 eNSP 里配置 PAP 的时候，命令非常直观。R1 作为认证方，配置如下：

interface Serial1/0/0 link-protocol ppp ppp authentication-mode pap ppp pap local-user huawei password simple 123456

这个配置里有两层含义。第一，ppp authentication-mode pap表示这条链路要求对端通过 PAP 认证；第二，ppp pap local-user huawei password simple 123456是认证方自己作为对端的 PAP 客户端时使用的凭证，但很多人会忽略：华为设备里，认证方也需要配置本地 PAP 用户信息，尤其是在双向认证的拓扑里。如果你只需要单向认证，那么认证方在 AAA 视图里配置本地用户即可：

aaa local-user huawei password cipher 123456 local-user huawei service-type ppp

被认证方 R2 上配置就简单了，只需在接口下声明自己用 PAP 方式发送用户名和密码：

interface Serial1/0/0 link-protocol ppp ppp pap local-user huawei password simple 123456

PAP 最大的问题就是安全级别太低，用户名密码在网络上是裸奔的，抓包工具一抓一个准。而且 PAP 被拒绝后不会自动重试，需要等下一次链路建立才会重新认证。所以现在的生产环境里很少有 PAP 单独出现，基本都是因为老设备兼容性原因才保留着。

但练习 PAP 的意义恰恰在于它的简单性。你可以用 PAP 跑通一遍链路建立流程，理解 PPP 状态机的变化，再切换到 CHAP 就不会被复杂的握手过程搞晕。

2.2 CHAP 三次握手挑战应答机制

CHAP（Challenge Handshake Authentication Protocol）比 PAP 晚出现，设计目标很明确：杜绝密码明文传输。它的核心思想是挑战-应答机制，认证方不主动要求被认证方交出密码，而是发送一个随机生成的挑战值（Challenge），被认证方用这个挑战值加上密码做哈希运算，把结果返回给认证方，认证方用本地存储的密码做同样的运算，一致则通过。

我在设备上配置 CHAP 时，认证方 R1 的接口配置是：

interface Serial1/0/0 link-protocol ppp ppp authentication-mode chap

同时在 AAA 视图下配置对端用户的密码：

aaa local-user huawei password cipher 123456 local-user huawei service-type ppp

被认证方 R2 的配置只需要告知设备自己的用户名和密码：

interface Serial1/0/0 link-protocol ppp ppp chap user huawei ppp chap password cipher 123456

注意，CHAP 中被认证方的命令是ppp chap user，这和 PAP 里的ppp pap local-user明显区分开了。我见过很多新手把这俩命令搞混，导致链路起不来，报错信息显示认证失败。

CHAP 三次握手的细节值得多说一句：Challenge 值是在链路上动态变化的，每次握手都不一样，即使同一个用户名密码，发送出去的哈希结果也每次都不同。这就杜绝了重放攻击。此外，CHAP 还支持在链路建立后的任意时刻再次发起挑战，这就是周期性重认证，能有效防止链路被第三方设备中途接管。

华为设备默认在 PPP 链路建立后，每隔一段时间会重新发起 CHAP 挑战，这个周期可以通过ppp chap challenge-time命令调整，默认值是 30 秒。我做实验的时候故意保留默认值，然后在 R2 上修改了密码，等了不到 30 秒 R1 就检测到哈希不一致，主动断开了链路。这个现象很直观，适合用来给别人演示 CHAP 的动态认证特性。

2.3 PAP 与 CHAP 的选型对比

在实际项目里选 PAP 还是 CHAP，主要看两个维度：安全要求和设备兼容性。下面这个表格是我自己整理的经验参考：

一个容易忽略的点是：CHAP 的密码在认证方设备上虽然是加密存储的，但哈希计算的输入必须是明文密码。如果两边设备的密码不一致，哪怕只差一个字符，也会直接导致认证失败。所以你在配置 CHAP 时，一定要确保两端密码完全一致，不要想当然地以为配置了cipher加密存储就万事大吉。

3. GRE 隧道原理与配置实现

3.1 GRE 封装与解封装的工作机制

GRE（Generic Routing Encapsulation）是一种通用的三层隧道协议，它做的事情用一个比喻来说就是：把一封本来要寄到本地地址的信，装进一个写了公网地址的大信封里，通过中间网络送到对端，对端拆开大信封再把原信投递给真正想要的目标。这里的“原信”就是私网 IP 报文，“大信封”就是 GRE 报文头加上外层公网 IP 头。

GRE 报文头的结构不复杂，但有几个关键字段值得了解一下。首先是协议类型字段，它标识了乘客协议的类型，比如 0x0800 表示 IPv4，0x86DD 表示 IPv6。然后是校验和字段，可选，开启后会增加 4 字节的头开销；最关键的是 Key 字段，用于识别同一隧道内的不同流量，也可以用来做简单的访问控制。

GRE 隧道的建立前提是两端必须能通过原有的 IP 网络互相访问，也就是说隧道源和隧道目的地址必须是可达的。在这个实验里，R1 的隧道源是 10.0.12.1，R3 的隧道源是 10.0.23.3，从 R1 到 R3 怎么走？中间要经过 R2，R2 需要知道怎么转发目的为 10.0.23.3 的报文。所以路由表的设计是 GRE 配置里必须同步完成的事情。

3.2 eNSP 中 GRE 隧道的完整配置步骤

我在 eNSP 里的配置流程分成四步走。

第一步，把 PPP 链路的认证全部调通。R1 和 R2 之间的链路用一条静态路由打通，R2 和 R3 之间的链路同样处理。具体命令是：

R1: ip route-static 10.0.23.0 255.255.255.252 10.0.12.2 R2: ip route-static 10.0.12.0 255.255.255.252 10.0.23.3 R3: ip route-static 10.0.12.0 255.255.255.252 10.0.23.2

注意，这三条静态路由是保证隧道底层可达的关键。你可以用 VRP 系统自带的命令检查一下：display ip routing-table，确认每个路由器都有到达对端隧道目的地址的路由条目。如果缺了这一步，后面配置隧道后接口状态是 up 的，但 ping 隧道对端地址永远不通。

第二步，在 R1 和 R3 上创建 Tunnel 接口并指定封装协议：

R1: interface Tunnel0/0/0 tunnel-protocol gre ip address 172.16.0.1 255.255.255.252 tunnel source 10.0.12.1 tunnel destination 10.0.23.3 R3: interface Tunnel0/0/0 tunnel-protocol gre ip address 172.16.0.2 255.255.255.252 tunnel source 10.0.23.3 tunnel destination 10.0.12.1

第三步，校准隧道口的 MTU。GRE 封装会使原始报文额外增加至少 24 字节（20 字节外层 IP 头 + 4 字节 GRE 头），如果不调整隧道接口的 MTU，会导致大报文在穿越隧道时被丢弃，ping 小包正常、大包不通是 GRE 隧道最经典的故障现象。我在实验里把隧道口的 MTU 设置成 1400：

interface Tunnel0/0/0 mtu 1400

第四步，在 GRE 隧道上运行动态路由协议。我选择了 OSPF，因为配置简单、收敛快，也方便观察隧道链路状态。宣告方式如下：

R1: ospf 1 area 0.0.0.0 network 192.168.1.1 0.0.0.0 network 172.16.0.1 0.0.0.0 R3: ospf 1 area 0.0.0.0 network 192.168.3.1 0.0.0.0 network 172.16.0.2 0.0.0.0

配置完成后，我用display ospf peer确认邻居状态，看到 Full 的那一瞬间，整个实验就打通了。在 R1 上 ping R3 的 Loopback 地址 192.168.3.1，能通就说明私网路由已经通过隧道正常传递。

3.3 认证方式切换时 GRE 配置的联动调整

这里有一个我自己踩过的坑，特别拿出来说一下。我在做实验时，先把 R1 和 R2 之间的 PAP 认证改成了 CHAP，然后发现 GRE 隧道对端 R3 的隧道目的地址配置没变，但隧道 ping 不通了。排查半天才发现，问题根本不在 GRE，而是 R1 到 R2 的 PPP 链路因为 CHAP 配置问题短暂断开，导致底层路由消失，GRE 隧道自然也就断了。

这个现象说明一个很重要的联动逻辑：GRE 隧道是建立在底层 IP 网络之上的，底层链路的可用性直接决定隧道状态。当你修改 PPP 认证方式时，一定要同步检查底层链路的路由是否依然有效，不要只盯着隧道的接口状态。我在配置 CHAP 时，R1 和 R2 之间的认证凭证配置不一致，导致链路 down，路由表里到 10.0.23.3 的条目消失，但 Tunnel 接口不会立刻自动 down，它处于 up 但无法转发流量的假死状态。排查时用display ip routing-table一眼就能看出问题：路由条目消失了。

4. 实操过程全纪录与排查工具梳理

4.1 完整的实验操作顺序

我这次练习的操作顺序严格按照“先链路、再认证、后隧道、终路由”的流程执行，每一步都验证通过后再进入下一步。

第一步，启动 eNSP，添加三台 AR3260，用串行线缆连接。连接的时候要注意接口编号，R1 的 S1/0/0 连 R2 的 S1/0/0，R2 的 S1/0/1 连 R3 的 S1/0/0，不要交叉连错。启动设备后，用display interface Serial1/0/0检查链路状态，确保物理层和数据链路层都是 up 的。

第二步，配置接口 IP 地址并启用 PPP 协议。华为串行接口默认封装就是 PPP，但为了明确起见，我仍显式配置了link-protocol ppp。配置 IP 后，立即用ping测试对端地址，确认 PPP 链路在没有认证时已经能通。这一步的意义是隔离问题：如果连没认证都不通，说明物理链路或配置有问题。

第三步，配置认证。先在 R1 上配置 PAP 认证并验证通过，然后把 R1 和 R2 的认证方式改成 CHAP，再次验证互通。这个过程里需要反复使用display ppp link查看链路状态。

第四步，配置 GRE 隧道。先在 R1 和 R2、R2 和 R3 之间写好静态路由，确定隧道底层可达，再创建 Tunnel 接口。

第五步，在隧道上跑 OSPF 并验证私网互通。

下面这张表是我在每步操作后必查的关键命令，算是我的排障工具速查表：

4.2 抓包观察 PAP、CHAP 和 GRE 报文特征

如果你想更深刻地理解这三种协议的差异，用 eNSP 自带的抓包工具是最直观的方式。我这次实验里分别抓取了 PAP 认证过程和 CHAP 认证过程中链路上的报文。

PAP 的抓包里，你能直接看到 Authenticate-Request 报文里有明文用户名（huawei）和明文密码（123456）。这个画面非常直观，也是为什么 PAP 只能用在信任网络里的最好佐证。

CHAP 的抓包里，你看到的是三组报文：Challenge（挑战值）、Response（响应值）、Success/Failure。Challenge 报文里的 Value 字段是一串十六进制随机数，Response 报文里的 Value 字段是哈希运算结果。你把两台设备上的密码改成不一致，再重新协商一次链路，就能看到 Failure 报文。

GRE 报文的抓包则需要你把过滤条件设置为gre或者ip proto 47。你会清晰地看到报文外层是标准的 IP 头（源地址为隧道源、目的地址为隧道目的），紧接着是 GRE 头，再往里面才是真正的内层 IP 包，它的源和目的才是私网地址。这个“套娃”结构看一眼比背十遍定义都管用。

4.3 常见故障问题速查表

实验过程中我把每一步可能遇到的问题都记录下来，整理成了下面的故障速查表，方便你以后对照排查。

这里面最常见的是 CHAP 密码不一致。因为我习惯在 AAA 视图里配置密码时用cipher方式存储，回到接口配置时容易把明文密码敲错一两位，导致两端哈希结果对不上。后来我养成了一个习惯：所有认证配置完成后，在两台设备上分别执行display current-configuration对照检查密码部分，确认无误再测试。

踩坑最多的小细节是 GRE 搭配 OSPF 时 DR 选举问题。GRE 隧道默认是广播型网络，OSPF 在广播型网络上会选举 DR/BDR。如果只有两台路由器，DR 选举本身没什么问题，但如果你在实验里加了一台路由器进隧道，就可能出现路由学习不完整的情况。最简单的办法是给 Tunnel 接口手动指定网络类型为点对点：

interface Tunnel0/0/0 ospf network-type p2p

这样能避免 DR 选举带来的收敛延迟，也能防止意外出现的问题。不过点对点网络类型下 OSPF 不会发送 Hello 到组播地址 224.0.0.5，而是单播发送，所以两端接口 IP 必须能直接互通，这个在隧道场景下是满足的。

5. 从练习到生产的经验迁移与坑点复盘

5.1 配置顺序对问题定位的影响

我这次练习有一个很深的体会：配置的顺序其实决定了你排障的难度。我在前几轮自己练的时候，喜欢先把所有配置一次性敲完，包括认证、路由、隧道、OSPF，然后发现链路起不来，瞬间陷入多变量同时出错的混沌状态，排查起来非常吃力。

后来我调整策略，把整个配置过程拆成四步，每步完成后立即验证效果，再进入下一步。这里有个实用小技巧：在用 eNSP 练习时，可以开启设备配置的自动保存功能，但更重要的是在每一步关键配置完成后，用save命令保存配置，同时导出一份配置文件作为备份。这样如果哪一步改坏了，可以直接回退到上一个正常点，不用全部重新来。

另外，如果把 PAP 和 CHAP 的练习分别做在两台不同的路由器对上，可以避免反复修改认证方式时把配置搞乱。我在 R1-R2 之间先练 PAP，验证通过后保存配置，再直接在接口下改成 CHAP。如果你只有两台设备练习，建议在修改前把原配置截图或者复制到记事本留存，方便回退。

5.2 模拟器和真实设备的差异意识

用 eNSP 练习有一个必须时刻提醒自己的点：模拟器简化了很多真实设备的物理层细节。比如，真实串行线路上你还需要考虑时钟频率（DTE/DCE）的问题，但在 eNSP 里完全不需要；真实设备上 PPP 认证失败会有 Syslog 日志记录，eNSP 里也可能没有明确的日志输出，只能靠抓包和接口状态判断。

所以你在模拟器里练熟之后，去真实设备上操作时，还需要额外关注几个真实环境特有的问题：接口的 DCE/DTE 时钟配置、线缆类型、接口卡驱动版本与 PPP 协议的兼容性、以及运营商链路中间设备的透传行为。模拟器里的边界是“点到点直连”，真实场景里中间可能隔着运营商的传输设备，认证报文在透传过程中要保证不被篡改，这也是 CHAP 比 PAP 更适合生产环境的另一个原因。

5.3 后续扩展练习的思路参考

练完这个实验后，我建议你按下面的思路继续扩展，让整个知识体系更完整：

第一，把 GRE 隧道改成 IPsec over GRE。在隧道接口外面套一层 IPsec 保护，这样不仅能练 GRE，还能理解加密封装与隧道封装共存时的报文结构。这个扩展非常实用，因为真实项目里很少只跑裸 GRE。

第二，在三台路由器之间跑 RIP 而不是 OSPF，对比两种动态路由协议在隧道环境下的行为差异。你会发现 RIP 的跳数限制在 GRE 隧道场景下很有讲究，因为隧道在逻辑上是一跳，但在物理上跨越了多个设备。

第三，把 PPP 链路改成 PPPoE 拨号接入，在 eNSP 里用路由器模拟宽带拨号场景，然后把 GRE 隧道建立在拨号获得的动态地址之上，理解动态隧道源地址的处理方式。这一步会用到 Dialer 接口和 Dialer 路由，难度会比今天这套实验高一个台阶。

这些扩展练习做完后，你对企业远程接入网络的理解会非常扎实。目前我自己的规划是下一步把 PPPoE 和 GRE 隧道结合起来，研究一下在动态 IP 地址环境下隧道源地址怎么通过路由策略自动匹配，等实验跑通了再来写一篇新文章。

最后再分享一个我在反复练习中养成的小习惯：每个实验拓扑命名时就把用途写清楚，比如“PPP_CHAP_GRE_OSPF_v2”，配置文件导出时也保持同名。这个习惯在实验多了以后非常有用，因为 eNSP 的工程文件多了之后，光靠图形界面根本分不清哪个是哪个，带版本号的文件名能让你在回看练习记录时节省大量时间。