HCIA-Datacom——————PPP链接篇

本文最后更新于396 天前，其中的信息可能已经过时，如有错误请发送邮件到xg20001215@126.com

串行端口通信

在一台路由器中只有网口，还有一种有将近50年历史的接口RS-232，这个接口也被大家称为串口。

PPP协议

Point-to-Point Protocol
点对点协议

PPP链路建立过程

想要配置PPP链路协议，其实只需要在

LCP———-链路控制协议
- 链路建立与维护
- 参数协商
  - MRU（Maximum Receive Unit）：类似MTU，但属于PPP层的概念（默认1500字节）。
    - 注意：MRU是对方能接收的最大报文大小，而MTU是本端发送的限制。
  - 认证协议（PAP/CHAP）的选择。
  - 压缩、多链路等可选功能的协商。
- 链路监控与终止
  - 通过定期发送Echo-Request/Echo-Reply检测链路存活。
  - 优雅关闭连接（Terminate-Request/Terminate-Ack）。

测试：

R2和R3的串口配置协议为PPP

R2：

Interface s1/0/1

Link-protocol ppp

Ip add 202.100.23.2 24

R3：

Interface s1/0/0

Link-protocol ppp

Ip add 202.100.33.3 24
mtu 1500

R2———> config-request

可以看到R2接口发出了连接请求，其中Protocol为0x021表示为LCP报文，报文的内容十分简单：
主要内容为表面自己的MRU和一个随机的magic Number。

MRU：自己最大能接收的数据的量，当对方的MRU大于或者小于自己的MRU时，传输的文件会使用最小的MRU来进行传输
Magic Number:魔术字，作用是为了防止环路，当对方的魔术字和自己的一样时，会认为发生了环路无法进行下一阶段，表现为双方持续交换Configure-Request，但无法收到Configure-Ack。

Config-ack<—————-R3

当R3收到了R2发出的报文，并且完全接受报文中的内容MRU、认证方式、魔术字，将会把报文内容原封不动重新发出，表示已经接收到报文。
当R2不接受R3发出的某些参数（如 MRU 太大），会回复 Configure-Nak（携带建议值）。如果 R3 完全不支持某些选项（如不认识的认证方式），会回复 Configure-Reject。

Config-request<————R3

和R2的一样R3会发出自己的认证方式等等。。

R2———> config-ack

与R3一样当R2收到了R3发出的报文，并且完全接受报文中的内容MRU、认证方式、魔术字，将会把报文内容原封不动重新发出，表示已经接收到报文。这里注意的是此时并不会修改报文中MRU的内容，但是实际上已经知道应该使用最小的MRU也就是1200进行传输。

PAP认证

+---------+                     +---------+
| Client  |                     | Server  |
+---------+                     +---------+
     |                                |
     |--- LCP Configure-Request ----->| (携带Auth-Protocol: PAP)
     |<-- LCP Configure-Ack ----------| (同意使用PAP)
     |                                |
     |--- PAP Authenticate-Request -->| (明文发送用户名/密码)
     |<-- PAP Authenticate-Ack ------| (认证成功)
     |                                |
     |--- IPCP/NCP协商 ------------->| (进入网络层配置)

认证过程：

PAP: password authentication protocol
R2：（被认证方）
Interface s1/0/1
Ppp pap local-user hw password simple/cipher 123
R3（认证方）
Interface s1/0/0
Ppp authentication-mode pap
Aaa
Local-user hw password cipher 123
Local-user hw service-type ppp

R2—————————————————————————————————————R3

LCP阶段

——————————————>config-request

可以看到R2接口发出了连接请求，其中Protocol为0x021表示为LCP报文，报文的内容十分简单：
主要内容为表面自己的MRU和一个随机的magic Number。

Config-ack<———————————————————————————–

当R3收到了R2发出的报文，并且完全接受报文中的内容MRU、认证方式、魔术字，将会把报文内容原封不动重新发出，表示已经接收到报文。

Config-request<—————————————————————-

R2向R3发出了连接请求，我们可以看到在除去之前的MRU和Magic Number之外，还出现了一个叫Authentic Protocol的认证方式。
Authentic Protocol：认证协议表面我使用了如下的加密协议（如 PAP 0xC023 或 CHAP 0xC223）

Mru/mn B/auth-pro pap

———>config-ack

当R3收到了R2发出的报文，并且完全接受报文中的内容MRU、认证方式、魔术字，将会把报文内容原封不动重新发出，表示已经接收到报文。并且准备进行下一步pap认证。

Mru/mn B/auth-pro pap

Pap协商

———> authentication-request

我们可以看到进入了pap协商阶段，R2在包里用明文显示了账号密码。

Username + password

Authentication-ack<————————————————————

成功案例：当被认证方的账号密码与自己aaa中的账号密码一样时，发出ack
Code: Authenticate-Ack (2) # 成功

Authentication-nak<————————————————————

拒绝了连接并且关闭了这次认证。

CHAP认证

+---------+                      +---------+
| Client  |                      | Server  |
+---------+                      +---------+
     |                                 |
     |--- LCP Configure-Request ------>| (协商使用CHAP)
     |<-- LCP Configure-Ack -----------| (同意CHAP)
     |                                 |
     |<-- CHAP Challenge -------------| (Server发送随机数)
     |--- CHAP Response ------------->| (Client计算哈希并返回)
     |<-- CHAP Success/Nak ----------| (Server验证结果)
     |                                 |
     |--- IPCP/NCP协商 -------------->| (进入网络层配置)