首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

L2TP协议概念及流程(2)

L2TP协议概念及流程(2)

四、L2TP隧道的呼叫建立流程
1、L2TP隧道的呼叫建立流程
图5
(1) 用户端PC机发起呼叫连接请求;
(2) PC机和LAC端进行PPP LCP协商;
(3) LAC对PC机提供的用户信息进行PAP或CHAP认证;
(4) LAC将认证信息(用户名、密码)发送给RADIUS服务器进行认证;
(5)RADIUS服务器认证该用户,如果认证通过则返回该用户对应的LNS地址等相关信息,并且LAC准备发起Tunnel连接请求;
(6) LAC端向指定LNS发起Tunnel连接请求;
(7) LAC端向指定LNS发送CHAP challenge信息,LNS回送该challenge响应消息CHAPresponse,并发送LNS侧的CHAP challenge,LAC返回该challenge的响应消息CHAPresponse;
(8) 隧道验证通过;
(9) LAC端将用户CHAP response、responseidentifier和PPP协商参数传送给LNS;
(10) LNS将接入请求信息发送给RADIUS服务器进行认证;
(11) RADIUS服务器认证该请求信息,如果认证通过则返回响应信息;
(12) 若用户在LNS侧配置强制本端CHAP认证,则LNS对用户进行认证,发送CHAP challenge,用户侧回应CHAPresponse;
(13) LNS再次将接入请求信息发送给RADIUS服务器进行认证;
(14) RADIUS服务器认证该请求信息,如果认证通过则返回响应信息;
(15) 验证通过,用户访问企业内部资源。
注:此节如下附加内容涉及到报文协商,前面没有介绍,可以先了解L2TP笔记2中关于报文格式与协商的相关内容,再回头深入分析此节,此节放在这里是为了便于对于整体协商过程进行深入分析。
附加:2、针对流程中步骤7、步骤12的Challenge验证过程的分析(1)LAC向LNS发SCCRQ请求消息时,会产生一个随机的字符串做为本端CHAPChallenge发给LNS。
(2)LNS收到这个Challenge后,再加上本端配置的密码及SCCRP产生一个新的字符串,用MD5算出一个16个字节的Response,在SCCRP消息中发给LAC。
同时也产生一个随机的字符串(LNS Challenge)放在SCCRP中一起发给LAC。
(3)LAC将自己的CHAPChallenge加上本端配置的密码,再加上SCCRP产生一个新字符串,用MD5算出一个16字节的字符串,并与LNS发来的SCCRP中带的LNSCHAP Response比较,相同通过,不同断掉。
(4)同理LNS也要验证LAC,LAC用在SCCRP中发现的LNS CHAPChallenge加上本端密码和SCCCN组合,再用MD5算出一个16字节的字符串做为LAC CHAPResponse在SCCCN中发给LNS。
(5)LNS用自己发的Challenge+本端密码+SCCCN用MD5算出一个16字节字符串,与收到的作比较,相同通过,不同断掉。
附加:3、LAC代LNS与PC协商LCP(即认证代理)和用于认证的AVPS
正常用户认证方式:
当LAC检测到有用户拨入电话的时候,向LNS发送ICRQ,请求在已经建立的tunnel中开始session的建立,LAC可以一直等到接收到了LNS回应的ICRP后,表明session可以建立的时候再回答远端(拨号用户)的呼叫,这样LNS可获得足够的信息来决定是否回答这个远端的呼叫。

LAC代LNS与PC协商LCP(即认证代理):
LAC在接收到ICRP之前,自行先回答远端(拨号用户)的呼叫,代替LNS与其进行LCP协商和PPP认证,用获得的信息来决定选择哪个LNS(此处对应流程图中步骤5),这种情况下LAC对呼叫的指示和呼叫的回答只是哄骗性质的。在session可以建立时,LAC向LNS发送ICCN时会携带着先前与呼叫用户进行的LCP协商和PPP认证涉及的特性信息(此处对应流程图中步骤9),包含这些信息的AVP如下:
①Inital Received LCP CONFREQ(ICCN\属性26):为LNS提供LAC从PPP对端(即拨号用户)接收到初始的conf-request。
②Last Sent LCP CONFREQ(ICCN\属性27):提供LAC发送到PPP对端最后的conf-request。
③Last Received LCP CONFREQ(ICCN\属性28):提供LAC从PPP对端接收到的最后的conf-request。
④Proxy Authen Type(ICCN\属性29):标识是否使用验证代理,验证的类型
0---Reserved 1---Textual username/password exchange
2---PPP CHAP 3---PPP PAP
4---No Authentication 5---Microsoft CHAP Version1(MSCHAPv1)
⑤Proxy Authen Name(ICCN\属性30):验证时客户端响应的名称。
⑥Proxy Authen Challenge(ICCN\属性31):LAC发送到PPP对端的Challenge。
⑦Proxy Authen ID(ICCN\属性32):为LAC和PPP对端的验证定了一个ID。
⑧Proxy Authen Response(ICCN\属性33):LAC从PPP对端接收到的PPPAuthentication Response。
继承事业,薪火相传
返回列表