电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛

标题: L2TP协议概念及流程（2） [打印本页]

作者: yuyang911220 时间: 2016-9-16 10:49 标题: 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。

欢迎光临电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛 (http://bbs.eccn.com/)