PPP协议
- PPP协议概述
- PPP链路建立过程
- PPP链路接口状态机
- LCP报文格式
- LCP协商过程—正常协商（链路层协商过程）
- LCP协商过程—参数不匹配（链路层协商过程）
- LCP协商过程—参数不识别（链路层协商过程）
- PPP认证模式
- PAP
- CHAP
- NCP协商—静态IP地址协商
- NCP协商—动态IP地址协商
PPP协议概述
- PPP（Point-to-Point Protocol，点到点协议），是一种常见的广域网数据链路层协议，主要用于全双工的链路上用于点到点的数据传输封装。
- PPP提供安全认证协议族PAP（Password Authentication Protocol，密码验证协议）和CHAP（Challenge Handshake Authentication Protocol，挑战握手认证协议）。
- PPP具有良好的扩展性，例如，当需要在以太网链路上承载PPP协议时，PPP可以扩展成为PPPoE。
- PPP协议提供LCP（Link Control Protocol，链路控制协议），用于各种链路层的协商，例如最大传输单元， 最大接受单元，认证模式等等。
- PPP协议提供各种NCP（Network Control Protocol，网络控制协议），如IPCP（IP Control Protocol，IP控制协议），用于网络层参数的协商，更好的支持了网络层协议。
PPP链路建立过程
- PPP链路的建立有三个阶段的协商过程：链路层协商，认证协商（可选）和网络层协商。
- 链路层协商：通过LCP报文进行链路参数协商，建立链路层连接。(MRU，认证模式，聚合等)
- 认证协商（可选）：通过链路建立阶段的认证方式进行链路认证。
- 网络层协商：通过NCP协商来选择和配置一个网络层协议并进行网络层参数协商。
PPP链路接口状态机
- PPP协商由链路两端的接口完成。接口的状态表示了协议的协商字段。
基本顺序就是首先进行链路协商，接着进行认证协商，最后进行网络层协商。其中任何一层协商没有成功都会回到最初的Dead（Down）状态。
LCP报文格式
- PPP报文可以由Protocol字段标识不同类型的PPP报文。例如：当Protocol字段为0XC021时，代表是LCP报文。此时又由于Code字段标识不同类型的LCP报文，如下表所示：
LCP协商过程—正常协商（链路层协商过程）
- LCP协商由不同的LCP报文交互完成。协商由任意一方发送Configura-Request报文发起。如果对端接收此报文且参数匹配，则通过回复Configure-Ack相应成功。
- 首先R1向R2发起协商，接口中包含了MRU（MAX Receive Unit最大接收单元），认证类型，以及魔术字（用于防止环路，当收到与自身相同的魔术字的时候，就认为产生了环路，将报文丢弃）
- R2收到报文之后，进行回复Ack进行确认。（这就是一个正常且没有问题的协商过程）
LCP协商过程—参数不匹配（链路层协商过程）
- 在LCP报文交互中出现LCP参数不匹配时，接收方回复Configure-Nak相应告知对端修改参数，然后重新协商。
- R1首先发起配置请求，并且携带本段的参数。（可以看到现在R1接口和R2接口的参数不一致）
- 然后发送给了R2之后，R2发现跟本端接口参数不一致，于是回复Configure-Nak给R1。
- R1收到之后会修改本端的参数，然后重新发送Configure-Request报文给R2。
- 最后R2发现参数合适，于是回复Configure-Ack报文，协商成功。
LCP协商过程—参数不识别（链路层协商过程）
- 在LCP报文进行交互中出现LCP参数不识别时，接收方回复Configure-Reject相应告知对端删除不识别的参数，然后重新协商。
- 首先R1发送端口的配置请求，并且携带端口的参数。
- R2收到R1发送的端口配置，然后发现里面有自己不认识的字段，于是回复Configure-Reject报文给R1.
- 然后R1收到Reject报文之后重新进行参数配置，然后将调整过后的参数再次发送给R2.
- R2收到与自身匹配的接口参数，然后认为参数合法，于是发送Ack报文给R1，协商完成。
PPP认证模式
链路协商成功之后，进行认证协商（可选）。认证协商有两种模式，PAP和CHAP。
PAP
- PAP认证双方有两次握手。协商的报文以明文的方式在链路上传输。
目前双方已经LCP链路协商成功，底层链路建立完成，并确立认证方式为PAP。在认证方有数据库，其中记录了可以认证成功的用户名和密码。 - 首先被认证方首先发起认证，向认证方发送用于建立链路的PPP帧，其中包括了用户名和密码。
- 然后认证方收到之后，与数据库进行对比，然后发现数据库匹配成功，发送Ack给被认证方。认证结束。
但是PAP认证有一个很大的缺陷，就是用户名和密码在明文中进行传输，不安全。
CHAP
- CHAP认证有三次握手。协商报文被加密之后在链路上进行传输。
现在LCP链路已经协商成功了，底层链路的建立，也确定认证方式为CHAP。认证方这里有数据库，内含可以成功建立的用户名和密码。 - 认证方主动发起验证请求，验证方向被验证方发送一些随机产生的报文（Challenge）。（包括ID和随机数）
- 被认证放收到报文之后，将报文ID，认证密码和随机数进行MD5运算，将生成的密文和自己的用户名一起发送给认证方。
- 认证方收到之后，通过用户名找出相应的密码，然后使用报文ID，随机数和相应的密码进行MD5计算，然后与收到的MD5值进行比对，如果一致，则回复success，如果不一致则回复failed。
（图中是认证方没有配置用户名的过程，就是在发送认证过程中的PPP报文没有配置用户名，但是还有一种配置用户名的CHAP认证过程： - 验证方主动发起验证请求，验证方向被验证方发送一些随机产生的报文（Challenge），并同时将本端的用户名附带上一起发送给被验证方。
- 被验证方接到验证方的验证请求后，先检查本端接口上是否配置了ppp chap password命令，如果配置了该命令，则被验证方用报文ID、命令中配置的用户密码和MD5算法对该随机报文进行加密，将生成的密文和自己的用户名发回验证方（Response）。如果接口上未配置ppp chap password命令，则根据此报文中验证方的用户名在本端的用户表查找该用户对应的密码，用报文ID、此用户的密钥（密码）和MD5算法对该随机报文进行加密，将生成的密文和被验证方自己的用户名发回验证方（Response）。
- 验证方用报文ID和自己保存的被验证方密码和MD5算法对原随机报文加密，比较二者的密文，若比较结果一致，认证通过，若比较结果不一致，认证失败。
NCP协商—静态IP地址协商
- PPP认证协商过后，双方进入NCP阶段，协商在数据链路上所传输的数据包格式与类型。以常见的IPCP协议为例，它分为静态IP地址协商和动态IP地址协商。
- 静态IP地址需要手动在链路两端进行配置IP地址。（要求地址都是使用手工进行配置）
- 首先R1发送配置请求，携带本端配置的IP地址，使用Configure-Request报文。
- 然后R2接收到报文之后，对地址进行检查，只要地址合法不是广播地址或者网络号等都可以，不是一个网段也可以通过，因为PPP链路是一个点到点的链路，通过直连进行通信，然后回复Ack报文。
NCP协商—动态IP地址协商
- 动态IP地址协商支持PPP链路一端为对端配置IP地址。（可以想作R1时客户端，R2时服务器端）
- 现在R1没有配置地址，向R2发送一个Request报文，包含地址0.0.0.0，就是一个空地址。
- R2收到之后发现对端地址不合法，回复一个Nak报文，Nak报文中含有一个IP地址。
- R1收到Nak报文之后重新发送新的配置请求，并且携带Nak报文中的IP地址。
- R2收到新的Request报文之后，确认是合法地址，发送Ack报文。（即使R1的地址跟R2不在一个网段也可以进行通信，因为此时在R2上会产生一条默认路由，指向R1的接口地址，并且下一跳为自身的出口S1/0/0）
- R2再发送自身的配置请求，携带本端IP地址。
- R1收到报文之后确定是合法的，随后回复Ack报文。
