华为：ppp链路协商抓包分析（详细）

 首先简单说一下ppp配置的流程。

1、在服务端将链路的封装类型设置为ppp，在服务端创建用来验证的本地用户。（还有一些是用别的服务器存用户数据）。

2、在服务端上设置验证协议，比如pap或者chap

3、在客户端上同样将链路的封装类型配置为ppp。然后将向服务端提供用户信息，验证成功即可

简单来说就是上面的步骤

首先我们使用抓包软件先来看以下LCP，是如何建立链路的连接的。

华为的路由器在串线上默认使用的就是PPP协议，所以我们先看一下两台路由器使用串线连接之后，线路上的数据包。

当你连接好两个路由器，点击抓包之后，你是不会看到它们的协议数据包的，因为抓包工具开启之后它们早就协商完了。你看到的是有无穷的request包和reply包，它们用来保证链路之间没有出现故障，也就是链路保活。

于是我们将左端的路由器的端口重新开启，然后继续查看抓包软件。

你会看到这样的数据包，每个request和ack是一对，requese包含着某一端的路由器向对端路由器发送一些了自身的传输因素，让对端了解，其因素是否符合自己。如果符合，那么就会发送ack包，否则就发送nak包，用作否认。

我们来看一下这些数据包的内部

首先就是address和control：它们都是以前用来保留但是却没有用上的位，然后就是后面的protocol位：它指的就是你后面的数据是装的啥，抓包工具其实已经帮我们分析好了，封装的就是LCP的数据。

我们来看一下LCP的协商内容，首先是code位，它代表了LCP的报文类型，其实这玩意wireshark都帮你显示出来了就是configuration reques，配置请求，也就是路由器将自身的配置因素发往对端的数据包。

Identifier：就是一个标识符，在ppp协商过程中，两端都要互相发送reques，然后对端判断这些参数是否OK，所以为了标识请求和回应的数据包，也就是说为了回应与请求一一对应，于是就有力这个标识符。

length：为了从PPP帧中取出这个LCP的数据内容，所以必须标识其长度，其他的数据内容也是一样的。

然后就是LCP的数据内容，也就是option后面的内容。

它其实已经标出了，LCP本次协商的参数就是，MRU（或者较MTU也行，这玩意就是可接收的最大字节。）然后就是后面的magic numbe，这东西我也不太清楚。

然后我们来看一下这个数据包的ack包

其实内容差不多。只不过把code位的数值改为了2，于是就变成了LCP中的configuration ack包

经过以上的协商我们会在路由器上看到链路已经是up的状态。但是此时我们并没有位两端的路由器的端口配置任何用作收发数据的标识（ip地址）以及任何的验证方式.

我们现在给右端的路由器设置验证方式位chap。华为不像思科，如果某端路由器设置了验证方式，另一端的协议状态就会立马down掉，它需要重新的关闭端口在下一次才会显示除效果。

 我们将端口关闭再重启来看一下链路的数据包。

 我们会看到同样是两端发送configuration request包请求对端查看自身的参数是否ok，但是我们只看到一对configuration包和ack包，另一对包变为了configuration包和reject包，也就是说没有配置验证方式的那端路由器杯配置了验证方式的路由器认可了，但是配置了验证方式的路由器并没有被另一端认可。于是它就发送了termination reques，也就是终止请求，进入终止状态。当然以上的数据会持续发送，因为它并不知道，没有配置的那个路由器什么时候会发送用户信息并成功获得认证。

我们现在配置左端的路由器（也就是没有配置验证方式的路由器），提供认证信息。并继续查看链路的数据

 我们看到链路上是两队configuration，ack包。以及chap的验证报文。和成功协商的信息

华为比较让我诧异的一个地方，我在思科配置chap的时候，有这样一个实验就是路由器两端互相做ppp的chap验证。我看书上说chap的验证方会自动地持续地发送挑战报文给对端路由器。然后经过一系列较复杂地流程才决定是否验证成功。但是总的来说只要两端的路由器都配置了以对端机器名为名字的用户，并设置相同的密码就能起到互相验证的效果。但是当我在华为上做同样的操作的时候，发现，它仅仅只会停留并失败在LCP的协商上。换句话来说，如果想要进入到chap的验证阶段就必须在被验证路由器的端口上配置ppp chap user和ppp chap password。（以上只是题外话）

我们在上面的配置基础上，在验证方路由器上配置ip地址，然后关闭接口看一下完整的协商过程

我们看到有两队configuration，ack包，以及chap的验证成功的信息，但是我们观察到后面有一个protocol reject，这个是什么呢？因为我只在一端上配置了ip地址，而另一端没有ip地址。

我们可以看见有一个configuration request包的数据内容不是LCP而是IPCP，IPCP就是协商IP协议所用到的协议。

可以看到配置了ip地址的路由器发出了协商上层协议的配置请求，但是对端路由器并没有ip地址，根本不懂他在说啥，于是就发送了protocol reject。于是链路的状态只有物理上是up的，逻辑上是down的。

我们来看一下IPCP的配置请求数据包的内容

前面是ppp的头部信息，我们主要看IPCP的数据内容。同样是code，identifier，length，这个和上面的LCP功能一致。

后面的option承载的是路由器端口的ip地址，主要就是发过去给对端看一下这个ip是不是正确，是不是和自己ip重复了。

这个IPCP的配置请求包会一直发送直到对端配置好了ip。原因还是一样的，因为不知道对面什么时候配置了ip。也许某一时刻就可以通信了。

当对端配置了ip之后，就会出现与两对configuration，ack包，代表着两端的上层协议都协商完成。

但是此时我们来做这样一个配置，我们不在客户端的接口上配置ip地址，而是在服务端给他提供ip地址，这时我们再看一下链路的数据情况

 

 我们会发现除了两对configuration，ack的LCP包和chap的验证成功信息之外，还多了一些IPCP的配置请求数据包。让我来解释一下。

首先有有ip地址的一端向没有ip地址，但需要从服务端获取的一端，发送IPCP的配置请求数据包，然后它就看了一些它的参数觉得OK，然后就发送ack报文，然后它也发送IPCP配置请求报文给对端看它的参数，以下是它的参数

 我们要关注的地方再IPCP的option，可以看见它发送了一个0.0.0.0 的地址给对端，这当然不行了，于是对端发送了一个nak的报文，标识否绝，然后又给它发送了一个configuration request报文，这个报文里面含有提供给它的ip地址。

以上是提供ip的报文信息。

 顺便一提LCP和IPCP里面的option内容也是协商的参数，不是固定不变的，比如我某端使用了验证，那么这个option字段里面就会包含这个验证方式的信息，IPCP也是类似。