PPP认证协议

2019-01-01 本文已影响0人点滴技术

写这篇分享文档，是因为在日常工作中，客户反馈了一个故障点，即L2TP一直无法建立，隧道一直UP/DOWN现象。咋这就把来龙去脉一一分析下。

为了能够写好这边文档，我找了官方RFC1334研究了一边，并进行抓包分析，当然这篇官方文档不长，还不能满足我的需求，你觉得呢？哈哈。。

image

PPP的基本原理

1.1 三个主要组成部分

一种通过串行链路封装数据包的方法；
链路控制协议（LCP Link Control Protocol）用于建立、配置和测试数据链路连接；
一系列网络控制协议（NCP Network Control Protocol）用于建立和配置不同网络层协议；

为了在点对点链路上建立通信，在链路建立阶段，PPP链路的每一端必须首先发送LCP包来配置数据连接. 在链路建立之后，PPP在进入网络层协议阶段之前提供可选的认证阶段。

默认情况下并非需强制性认证，如果链路要求认证，在链路建立阶段必须指定认证协议配置选项。

一般会在终端或路由器设备上通过PPPOE或专线连接到PPP网络服务器上，服务器会使用主机或路由器的标识选择网络层协商选项。

image

1.2 ppp两个认证协议

PAP（Password Authentication Protocol）
CHAP（Challenge-Handshake Authentication Protocol）

先来说说 PAP ：
①PAP提供了一种简单的方法让对端使用2次握手来建立自己的身份，这个仅在初始连接建立时完成。
②连接建立后，被认证者反复向认证者发送一对用户名和密码，直到认证被确认或连接中断。
③安全性不高，密码在链路上明文传输，没有重放、反复尝试、错误攻击的保护。

PAP配置选项格式：

image

PAP的报文格式（重点介绍这个）：

image

Code：1个字节，标识PAP报文类型，分3种：
①Authentication-Request
②Authentication-Ack
③Authentication-Nak

Identifier：1个字节，匹配请求和回复（一个Request和Ack报文里的标识是一样的）；
Length：2个字节，标识PAP数据长度，包括code、identifier、length、data字段，其他字段为数据链路层填充，接收时可忽略；
Data：0或多个字节，有Code字段决定；

以上介绍基本的PAP报文格式，那么接下来在剖析下Code里面的3种报文类型，可先消化一下哈！！！
为了给你们增添点动力往下看，配上个小实验，你们就感兴趣了，光理论不行啊，听了我也会困，动动手做个实验：

image

实验环境配置脚本：

#R1路由器配置
#
aaa
 local-user chap password cipher pap
 local-user chap service-type ppp
#
interface Serial0/0/0
 link-protocol ppp
 ppp authentication-mode pap
 ppp pap local-user pap password simple pap
 ip address 12.1.1.2 255.255.255.252
#R2路由器配置：
#
interface Serial0/0/0
 link-protocol ppp
 ppp pap local-user pap password simple pap
 ip address 12.1.1.2 255.255.255.252
#

以下报文均通过Wireshark抓包，如下所示：

Authentication-Request报文：
该报文是由被认证者发起。

image

code置位为1；
标识为5
长度为12比特
data：用户名长度为3，用户名为pap，用户密码长度为3，用户密码为pap

** Authentication-Ack报文：**
该报文是由认证者识别和接收请求报文的用户名和密码而回复的报文，且code置位为2.

image

code置位为2；
标识为5 //说明回复的是request标识为5的
长度为5比特
data：为0比特

** Authentication-Nak报文：**
这个报文我故意配置错误的”用户名“和”密码“来触发Nak报文。

image

code置位为3；
标识为6 //同标识为6的request报文
长度为26比特
data：消息长度为21比特，消息为认证失败；

再接着来说说 CHAP ：

①chap使用3次握手周期性验证对端的身份，这是在链路建立的开始就完成的，在链路建立完成后的任何时间都可以重复发送再验证。
②链路阶段建立完成后，认证者发送一个“质询”给被认证者，被认证者通过一次HASH计算（质询+密码）生成的值发送给认证者，认证者把自己hash出来的值与此对比，如果一致，则接受，否则拒接。
③两端才知道密码，而且密码不会在链路上传输。

CHAP配置选项格式：

image

CHAP比PAP多了“Algorithm”这个字段。

CHAP的报文格式（重点介绍这个）：

image

Code：1个字节，标识CHAP报文类型，分3种：
①Challenge
②Respons
③Success
④Failure

Identifier：1个字节，匹配挑战、响应和回复；
Length：2个字节，标识CHAP数据长度，包括code、identifier、length、data字段，其他字段为数据链路层填充，接收时可忽略；
Data：0或多个字节，有Code字段决定；

以上介绍基本的CHAP报文格式，那么接下来在剖析下Code里面的4种报文类型，可先消化以下哈！！！
实验拓扑图：

<同上，略>

实验环境配置脚本：

#R1路由器配置：
aaa
 local-user chap password cipher chap
 local-user chap service-type ppp
#
interface Serial0/0/0
 link-protocol ppp
 ppp authentication-mode chap
 ppp chap user chap
 ip address 12.1.1.1 255.255.255.252
#
#R2路由器配置：
aaa
 local-user chap password cipher nzNG'RXtq'939O4.`(ZGYrz#
 local-user chap service-type ppp
#
interface Serial0/0/0
 link-protocol ppp
 ppp chap user chap
 ip address 12.1.1.2 255.255.255.252
#

以下报文均通过Wireshark抓包，如下所示：
** Challenge报文：** 该报文是由认证者发起。

image

code置位为1；
标识为1（标识一样代表为同一条交互消息）
长度为25比特
data：hash值大小为16，用户名为chap，hash值。

** Response报文：** 该报文是由被认证者回应。

image

code置位为2；
标识为1
长度为25比特
data：hash值大小为16，用户名为chap，hash值。

Success报文： 该报文是由认证者接收被认证者而回应。

image

code置位为3；
标识为1
长度为20比特
消息：消息描述。

** Failure报文：** 该报文是由认证者不接收被认证者而回应。

image

code置位为4；
标识为3
长度为29比特
消息：消息描述。

为了给下文做铺垫，苦口婆心说了这么多，来来来。。鼓鼓掌吧！哈哈

image

接下来就是介绍下工作上遇到的一个故障点：L2TP隧道无法建立，一直UP/DOWN

网络架构简图

image

基本介绍：

公司局域网的出口防火墙USG需要与腾讯云上的服务器（linxu系统）建立L2TP隧道，局域网内部终端就可以通过隧道访问腾讯云上部署的业务服务了。
局域网出口防火墙USG作为LAC，腾讯云服务器作为LNS
腾讯云上部署l2tp的软件：xl2tpd-1.2.8.tar.gz

网络基本配置

#USG关键配置
#
 l2tp enable
#
l2tp-group lac
 undo tunnel authentication
 start l2tp ip <腾讯云公网IP地址> fullusername huawei
#
interface Virtual-Template0
 ppp authentication-mode chap
 ppp chap user <用户名>
 ppp chap password cipher <用户密码>
 ip address ppp-negotiate
 call-lns local-user huawei binding l2tp-group lac
 undo service-manage enable
#