加载中...

PPP协议

一、PPP(点对点协议)简介

1.1 PPP使用场景

​ 我们家庭中使用最多的宽带接入方式就是PPPoE(PPP over Ethernet)。这是一种PPP利用以太网(Ethernet)资源,在以太网上运行PPP来对用户进行接入认证的技术,PPP负责在用户端和运营商的接入服务器之间建立通信链路。

二、PPP(点对点协议)结构

2.1 PPP封装过程

image-20250301194242888

同在Ensp抓包只能看到

image-20250301192427005

2.2 PPP报文字段

同样的Flag位和HDLC一样,作为帧定界符

字段 长度 含义
Address 1字节 PPP协议被运用在点对点的链路上,它可唯一标识对方,因此无须知道对方数据链路层地址。所以该字节无任何意义,按协议规定填充为全1广播地址。
Control 1字节 同Address域一样,PPP数据帧的Control域也没有实际意义,规定值为0x03,该域与Address域一起标识了PPP报文,即PPP报文头为FF03。
Protocol 1或2字节 协议域,可用来区分PPP数据帧中信息域所承载的数据报文的内容(Information的内容)

三、PPP(点对点协议)组件

2.1 LCP组件

LCP:link control protocol:链路控制协议,二层链路协商,建立、维护,以及认证

image-20250301195756959

字段 长度 含义
Code 1字节 主要是用来标识LCP数据报文的类型。在链路建立阶段,接收方接收到LCP数据报文。当其Code域的值无效时,就会向对端发送一个LCP的代码拒绝报文(Code-Reject报文)。
Identifier域 1字节 Identifier域为1个字节,用来匹配请求和响应,当Identifier域值为非法时,该报文将被丢弃

​ 携带认证的Options

image-20250301201530117

TLV中携带

MRU == MTU 最大协议单元

Magic Number 每个设备会随机形成魔术字,收到对方的magic number,跟自己的对比,如果不一样,那么回复ack,如果一样回复nak

Authentication Protocol 认证模式

image-20250301201457230

2.2 NCP组件

NCP: network control protocol:网络控制协议

2.3 认证组件

2.3.1 PAP认证

password authentication protocol 密码认证协议(单向认证)

image-20250302004745340

image-20250302004828932

image-20250302004937404

[!NOTE]

  • 被验证方把本地用户名和口令发送到验证方。
  • 验证方根据本地用户表查看是否有被验证方的用户名
    • 若有,则查看口令是否正确,若口令正确,则认证通过;若口令不正确,则认证失败。
    • 若没有,则认证失败。
# AR1
#
interface Serial4/0/0
link-protocol ppp
ppp pap local-user wbc password simple 123
ip address 10.1.12.1 255.255.255.0 

# AR2
#
aaa 
domain default_admin 
local-user wbc password cipher 123
local-user wbc service-type ppp
#
interface Serial4/0/0
link-protocol ppp
ppp authentication-mode pap 
ip address 10.1.1.1 255.255.255.0 

2.3.2 CHAP认证

challenge handshake authentication protocol 挑战握手认证协议

image-20250302005129033

image-20250302005120618

image-20250302005156538

[!NOTE]

  1. 认证方主动发起认证请求,认证方向被认证方发送一些包含随机数的报文(Challenge),并同时将本端的用户名附带上一起发送给被认证方。

    image-20250302013642933

  2. 被认证方接到认证方的认证请求后,先检查本端接口上是否配置了CHAP密码,

    • 若已配置CHAP密码,则被认证方通过哈希算法对报文ID、配置的密码和报文中的随机数计算哈希值,将该哈希值和自己的用户名发回认证方(Response)。
    • 若未配置CHAP密码,则根据此报文中认证方的用户名在本端的用户表查找该用户对应的密码,通过哈希算法对报文ID、此用户的密码和报文中的随机数计算哈希值,将生成的哈希值和被认证方自己的用户名发回认证方(Response)。
  3. 验证方通过哈希算法对报文ID、自己保存的被验证方密码和Challenge报文中的随机数计算哈希值,并与Response报文中的哈希值进行比较,若比较结果一致,认证通过,若比较结果不一致,认证失败。

客户端(wbc)                         认证服务器
---------                           ---------
1. 接收 <-- Challenge
   ├─ ID: 1
   ├─ Random: [128-bit随机数]
   └─ Username: null(暂不指定用户)

2. 计算Hash1: 
   └─ MD5(ID=1 + Random + 客户端密码) → Hash1

3. 发送 Response -->
   ├─ ID: 1
   ├─ Hash: Hash1
   └─ Username: wbc(声明认证用户)

4. 服务器校验:
   ├─ 根据用户名`wbc`查找本地存储的密码(如AAA数据库)
   ├─ 计算Hash2: MD5(ID=1 + Random + 服务器存储的密码)
   └─ 对比Hash1与Hash2

5. 认证结果:
   ├─ 若一致 → 发送 Success
   ├─ 若不一致 → 发送 Failure(最多允许3次重试)
   └─ 3次失败后终止链路协商

------------------------------------------------------------------------------------------------------------------------------
AR1
#
interface Serial4/0/0
link-protocol ppp
ppp chap user wbc
ppp chap password simple 123
ip address 10.1.12.1 24

AR2
#
aaa 
domain default_admin 
local-user wbc password cipher 123
local-user wbc service-type ppp
#
interface Serial4/0/0
link-protocol ppp
ppp authentication-mode chap 
ip address 10.1.1.1 24

2.4 Magic Number机制

设备AR2                          对端设备
-------                         --------
1. 发送 Config-Request -->
   ├─ ID: 1
   └─ Options:
      └─ Magic-Number: A(初始值)

2. 接收 <-- Config-Nak
   ├─ ID: 1
   └─ Rejected Option:
      └─ Magic-Number: A(检测到冲突,要求修改)

3. 发送 Config-Request -->
   ├─ ID: 2(新会话ID需递增)
   └─ Options:
      └─ Magic-Number: 非A(如B)

4. 接收 <-- Config-Nak
   ├─ ID: 2
   └─ Rejected Option:
      └─ Magic-Number: 非A(仍冲突,协商失败)

三、PPP(点对点协议)流程

3.1 PPP状态机

img

3.1.1 Establish阶段(链路建立阶段)

PPP链路进行LCP协商。协商内容包括工作方式是SP(Single-link PPP)还是MP(Multilink PPP)、最大接收单元MRU(Maximum Receive Unit)、验证方式和魔术字(magic number)等选项。互相发送Configure-Request、Configure-Ack等报文。

# 在双方节点都进行一次Config-Ack确认后进行下一个阶段

设备A                           设备B
------                         ------
1. 发送 Config-Request -->
   ├─ ID: 2
   └─ Options:
      ├─ MRU: 1200
      └─ Magic-Number: A

2. 接收 <-- Config-Ack
   ├─ ID: 2
   └─ Accepted Options:
      ├─ MRU: 1200 (Confirmed)
      └─ Magic-Number: A

3. 接收 <-- Config-Request
   ├─ ID: 4
   └─ Options:
      ├─ MTU: 1300
      └─ Magic-Number: B

4. 发送 Config-Ack -->
   ├─ ID: 4
   └─ Accepted Options:
      ├─ MTU: 1300 (Confirmed)
      └─ Magic-Number: B

3.1.2 Authenticate阶段(验证阶段)

缺省情况下,PPP链路不进行验证。如果要求验证,在链路建立阶段必须指定验证协议。PPP提供密码验证协议PAP(Password Authentication Protocol)和质询握手验证协议CHAP(Challenge-Handshake Authentication Protocol)两种验证方式。

[!NOTE]

如果出现双方协议不同 会发生Nak

image-20250301201327727

如果一方有协议,一方没有会发生Reject TLV填充不匹配

image-20250301201344534

3.1.3 Network阶段(网络层协商阶段)

正常沟通模式

设备A                           设备B
------                         ------
1. 发送 Config-Request -->
   ├─ ID: 1
   └─ Options:
      └─ IP Address: 202.100.23.2

2. 接收 <-- Config-Ack
   ├─ ID: 1
   └─ Accepted Option:
      └─ IP Address: 202.100.23.2
         (设备B将此IP以/32主机路由加入路由表)

3. 接收 <-- Config-Request
   ├─ ID: 5
   └─ Options:
      └─ IP Address: 202.100.33.3

4. 发送 Config-Ack -->
   ├─ ID: 5
   └─ Accepted Option:
      └─ IP Address: 202.100.33.3
         (设备A将此IP以/32主机路由加入路由表)

image-20250301203659615

分配模式

TEXT
客户端(R2)                          服务端(R3)
---------                            ---------
1. 发送 Config-Request -->
   ├─ ID: 1
   └─ Options:
      └─ IP Address: 0.0.0.0 (请求自动分配地址)

2. 接收 <-- Config-Nak
   ├─ ID: 1
   └─ Suggested Option:
      └─ IP Address: 1.2.3.4 (服务端建议分配的地址)

3. 发送 Config-Request -->
   ├─ ID: 5 (新会话ID需递增)
   └─ Options:
      └─ IP Address: 1.2.3.4 (接受建议地址)

4. 接收 <-- Config-Ack
   ├─ ID: 5
   └─ Accepted Option:
      └─ IP Address: 1.2.3.4 (地址分配确认)

(双方将对方的IP地址以/32主机路由加入路由表)

3.1.4 Terminate阶段(网络终止阶段)

image-20250302015113621

服务器或客户端可以定期发送LCP Echo-Request数据包,如果对方在线并且连接正常,则会回复LCP Echo-Reply。如果在多次请求后没有收到响应,则认为对方已下线或连接中断。

posted @ 2025-03-18 19:10  江寒雨  阅读(248)  评论(0)    收藏  举报