所选语种没有对应资源,请选择:

本站点使用Cookies,继续浏览表示您同意我们使用Cookies。Cookies和隐私政策>

提示

尊敬的用户,您的IE浏览器版本过低,为获取更好的浏览体验,请升级您的IE浏览器。

升级

S12700 V200R010C00 配置指南-用户接入与认证

本文档介绍了用户接入与认证的相关特性,主要包括AAA、DAA、NAC、PPPoE、策略联动、IP Session。分别从特性原理、配置过程和配置举例等方面进行介绍。

评分并提供意见反馈 :
华为采用机器翻译与人工审校相结合的方式将此文档翻译成不同语言,希望能帮助您更容易理解此文档的内容。 请注意:即使是最好的机器翻译,其准确度也不及专业翻译人员的水平。 华为对于翻译的准确性不承担任何责任,并建议您参考英文文档(已提供链接)。
原理描述

原理描述

PPPoE协议采用Client/Server方式,它将PPP报文封装在以太网帧之内,在以太网上提供点对点的连接。

PPPoE可分为三个阶段,即Discovery阶段Session阶段Terminate阶段

PPPoE会话建立过程如图7-1所示。

图7-1  PPPoE会话建立过程

Discovery阶段

图7-2所示,Discovery阶段为PPPoE认证的PPPoE协商阶段,由四个过程组成。
图7-2  PPPoE协商过程

  1. PPPoE Client广播发送一个PADI(PPPoE Active Discovery Initial)报文,在此报文中包含PPPoE Client想要得到的服务类型信息。

  2. 所有的PPPoE Server收到PADI报文之后,将其中请求的服务与自己能够提供的服务进行比较,如果可以提供,则单播回复一个PADO(PPPoE Active Discovery Offer)报文。

  3. 根据网络的拓扑结构,PPPoE Client可能收到多个PPPoE Server发送的PADO报文,PPPoE Client选择最先收到的PADO报文对应的PPPoE Server做为自己的PPPoE Server,并单播发送一个PADR(PPPoE Active Discovery Request)报文。

  4. PPPoE Server产生一个唯一的会话ID(Session ID),标识和PPPoE Client的这个会话,通过发送一个PADS(PPPoE Active Discovery Session-confirmation)报文把会话ID发送给PPPoE Client,会话建立成功后便进入PPPoE Session阶段。

完成之后通信双方都会知道PPPoE的Session_ID以及对方以太网地址,它们共同确定了唯一的PPPoE Session。

Session阶段

PPPoE Discovery阶段的工作为PPPoE Client和PPPoE Server之间建立了Session,之后PPPoE便进入到Session阶段,Session阶段可划分为两部分,一是PPPoE认证的PPP协商阶段,二是PPP报文传输阶段。

PPPoE认证过程中的PPP协商和普通的PPP协商方式一致,分为LCP、认证、NCP三个阶段。

  • LCP协商

    LCP协商阶段主要完成建立、配置和检测数据链路连接。LCP协商的过程如下:协商双方互相发送一个Config-Request报文,确认收到的Config-Request报文中的协商选项,根据这些选项的支持与接受情况,做出适当的回应。若两端都回应了Config-ACK,则标志LCP链路建立成功,否则双方会继续发送Config-Request报文,直到对端回应了Config-ACK报文为止。
    图7-3  LCP协商的基本过程

  • 认证阶段

    LCP协商成功后,开始进行认证工作,认证协议类型由LCP协商结果(CHAP或者PAP)决定。

    PAP验证过程

    PAP验证协议为两次握手验证,口令为明文。

    PAP验证的过程如图7-4所示。

    图7-4  PAP认证过程

    • PPPoE Client把本地用户名和口令发送到PPPoE Server。

    • PPPoE Server根据本地用户表查看是否有PPPoE Client的用户名
      • 若有,则查看口令是否正确,若口令正确,则认证通过;若口令不正确,则认证失败。
      • 若没有,则认证失败。

    CHAP验证过程

    CHAP验证协议为三次握手验证协议,它在网络上采用加密形式传输用户密码,因此安全性要比PAP高。

    CHAP的验证过程如图7-5所示。

    图7-5  CHAP的验证过程

    • PPPoE Server主动发起验证请求,PPPoE Server向PPPoE Client发送一些随机产生的报文(Challenge)。
    • PPPoE Client接到PPPoE Server的验证请求后,利用报文ID、CHAP密码和MD5算法对该随机报文进行加密,将生成的密文和自己的用户名发回PPPoE Server(Response)。
    • PPPoE Server用自己保存的PPPoE Client密码和MD5算法对原随机报文加密,比较二者的密文,若比较结果一致,认证通过,若比较结果不一致,认证失败。
    CHAP与PAP验证过程对比
    • PAP认证中,口令以明文方式在链路上发送,完成PPP链路建立后,PPPoE Client会不停地在链路上反复发送用户名和口令,直到身份验证过程结束,所以安全性不高。当实际应用过程中,对安全性要求不高时,可以采用PAP认证建立PPP连接。

    • CHAP认证中,验证协议为三次握手验证协议。它只在网络上传输用户名,而并不传输用户密码,因此安全性比PAP认证高。当实际应用过程中,对安全性要求较高时,可以采用CHAP认证建立PPP连接。

  • NCP阶段

    认证成功后,PPP进入NCP阶段。NCP阶段的主要功能是协商PPP报文的网络层参数,如IP地址,DNS Server IP地址,WINS Server IP地址等。

    NCP协商支持多种协议,如IPCP协议、BCP协议,最为常用的是IPCP协议。PPPoE用户主要通过IPCP来获取访问网络的IP地址或IP地址段。

    IPCP的协商过程是基于PPP状态机进行协商的。经过双方协商,通过配置请求、配置确认、配置否认等包文交换配置信息,最终由initial (或closed)状态变为Opened状态。IPCP状态变为Opened的条件必须是发送方和接收方都发送和接收过确认包文。

    IPCP协商过程中,协商包文可包含多个选项,即参数。各个选项的拒绝或否认都不能影响IPCP的UP,IPCP可以无选项协商,无选项协商也同样能够UP。选项有IP Address、网关、掩码等,其中IP Address是最重要的一个选项,有些厂家的实现必须这个选项得到确认,大多数厂家的实现允许这个选项为空。

    NCP协商流程与LCP协商流程类似,协商双方互相发送NCP报文,并且互相回应Ack报文后,标志NCP己协商完,用户上线成功,可以正常访问网络了。

    NCP的基本协商流程如图7-6所示。

    图7-6  NCP的基本协商流程

PPPoE Session的PPP协商成功后,就可以承载PPP数据报文。在PPPoE Session阶段所有的以太网数据包都是单播发送的。

Terminate阶段

PPP通信双方应该使用PPP协议自身来结束PPPoE会话,但在无法使用PPP协议结束会话时可以使用PADT(PPPoE Active Discovery Terminate)报文。

进入PPPoE Session阶段后,PPPoE Client和PPPoE Server都可以通过发送PADT报文的方式来结束PPPoE连接。PADT数据包可以在会话建立以后的任意时刻单播发送。在发送或接收到PADT后,就不允许再使用该会话发送PPP流量了。

用户组授权功能

设备支持根据用户组对用户进行授权控制,即用户认证成功后,认证服务器下发用户组,将用户进行分类。每个用户组可以关联不同的ACL规则,通过用户组和ACL规则的关联,实现对每类用户进行ACL授权信息控制,即同类用户采用同样的授权信息。

翻译
下载文档
更新时间:2019-12-28

文档编号:EDOC1000141386

浏览量:20358

下载量:353

平均得分:
本文档适用于这些产品

相关版本

相关文档

Share
上一页 下一页