我很久没在模拟器上正经排过这三种协议了正好最近项目里有人问起 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 链路 AR1 作为认证方先练习 PAP再改成 CHAP。R2 的 Serial 接口S1/0/0连接到 R1R2 的 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.1R2 是 10.0.12.2。PPP 链路 BR2 到 R3分配了 10.0.23.0/30 网段R2 是 10.0.23.2R3 是 10.0.23.3。两个私网网段分别挂在 R1 的 Loopback 0192.168.1.1/24和 R3 的 Loopback 1192.168.3.1/24上模拟总部和分支的内部网络。GRE 隧道地址用 172.16.0.0/30 网段R1 隧道口配 172.16.0.1R3 隧道口配 172.16.0.2。有个细节值得提醒PPP 链路地址不要用 /24 这种大网段用 /30 是标准做法。因为 PPP 是点对点链路只有两个设备/30 完全够用还能避免路由表里出现不必要的广播网段条目。2. PAP 和 CHAP 认证机制深度拆解2.1 PAP 两次握手认证的优缺点PAPPassword 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 123456PAP 最大的问题就是安全级别太低用户名密码在网络上是裸奔的抓包工具一抓一个准。而且 PAP 被拒绝后不会自动重试需要等下一次链路建立才会重新认证。所以现在的生产环境里很少有 PAP 单独出现基本都是因为老设备兼容性原因才保留着。但练习 PAP 的意义恰恰在于它的简单性。你可以用 PAP 跑通一遍链路建立流程理解 PPP 状态机的变化再切换到 CHAP 就不会被复杂的握手过程搞晕。2.2 CHAP 三次握手挑战应答机制CHAPChallenge 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主要看两个维度安全要求和设备兼容性。下面这个表格是我自己整理的经验参考对比维度PAPCHAP握手次数两次三次密码传输明文MD5 哈希后传输重放攻击防护无有随机挑战值重认证机制无支持周期性挑战配置复杂度低中等老旧设备兼容性高依赖实现适用场景实验室、兼容性要求高的场景生产环境首选一个容易忽略的点是CHAP 的密码在认证方设备上虽然是加密存储的但哈希计算的输入必须是明文密码。如果两边设备的密码不一致哪怕只差一个字符也会直接导致认证失败。所以你在配置 CHAP 时一定要确保两端密码完全一致不要想当然地以为配置了cipher加密存储就万事大吉。3. GRE 隧道原理与配置实现3.1 GRE 封装与解封装的工作机制GREGeneric Routing Encapsulation是一种通用的三层隧道协议它做的事情用一个比喻来说就是把一封本来要寄到本地地址的信装进一个写了公网地址的大信封里通过中间网络送到对端对端拆开大信封再把原信投递给真正想要的目标。这里的“原信”就是私网 IP 报文“大信封”就是 GRE 报文头加上外层公网 IP 头。GRE 报文头的结构不复杂但有几个关键字段值得了解一下。首先是协议类型字段它标识了乘客协议的类型比如 0x0800 表示 IPv40x86DD 表示 IPv6。然后是校验和字段可选开启后会增加 4 字节的头开销最关键的是 Key 字段用于识别同一隧道内的不同流量也可以用来做简单的访问控制。GRE 隧道的建立前提是两端必须能通过原有的 IP 网络互相访问也就是说隧道源和隧道目的地址必须是可达的。在这个实验里R1 的隧道源是 10.0.12.1R3 的隧道源是 10.0.23.3从 R1 到 R3 怎么走中间要经过 R2R2 需要知道怎么转发目的为 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 设置成 1400interface 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/0R2 的 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 并验证私网互通。下面这张表是我在每步操作后必查的关键命令算是我的排障工具速查表验证目标命令期望结果PPP 物理链路状态display interface Serial1/0/0物理层 up、链路层 upPPP 认证状态display ppp link链路协议为 PPP认证通过底层路由可达display ip routing-table存在到隧道目的地址的路由隧道接口状态display interface Tunnel0/0/0协议为 upOSPF 邻居状态display ospf peer状态为 Full私网连通性ping 192.168.3.1丢包率 0%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 常见故障问题速查表实验过程中我把每一步可能遇到的问题都记录下来整理成了下面的故障速查表方便你以后对照排查。现象可能原因排查方法解决方案PPP 链路一直 down线路连接错误或接口没启用display interface Serial检查线缆连接物理接口执行undo shutdownPPP 认证失败反复协商两端用户名或密码不一致display ppp link抓包查看 Failure 报文重新核对 AAA 本地用户和接口下配置的密码CHAP 认证失败但配置看起来正确一端配了ppp chap user另一端没配密码用display current-configuration interface Serial检查被认证方补上ppp chap passwordGRE 隧道接口 up 但 ping 不通对端隧道底层路由缺失display ip routing-table检查隧道目的地址路由补齐静态路由OSPF 邻居卡在 ExStart隧道 MTU 不一致display ospf error统一隧道接口 MTU建议 1400ping 大包不通、小包正常GRE 封装导致 MTU 超限调整隧道接口的mtu配置较小 MTU同时检查两端一致修改认证后隧道中断PPP 链路重启导致底层路由消失查看路由表是否还有条目确认认证配置正确后再启用 VRP 的quit退出检查这里面最常见的是 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 的工程文件多了之后光靠图形界面根本分不清哪个是哪个带版本号的文件名能让你在回看练习记录时节省大量时间。