L2TP协议笔记1---L2TP概念及协议流程分析

来源：互联网发布：闪迪数据恢复软件编辑：程序博客网时间：2024/05/20 10:53

转自：http://lijt100616.blog.51cto.com/1338011/341144

这个协议是早前做防火墙测试工作时主要负责测试的协议，虽然只做了几个月，但感觉如果把当时的一些学习笔记和经验整理好放在网络中，不仅可以使自己的协议理解得到巩固，也让自己有机会在和别人交流中互相学习。

当初学习时，看的资料大部分都是先简介协议然后直接就开始抽象的介绍各种报文格式、报文每个字段的作用，光是大量报文名称看着头就很大了，所以在这里先介绍了L2TP的大框，知道是干什么的、有哪些概念、整体运作的过程大概是什么样的，然后在针对每一个步骤涉及的报文进行深入研究，看着一个协商报文可以形象的想象出其在这个L2TP建立过程中的位置和作用。

L2TP协议简介

Layer 2 Tunneling Protocol （第二层隧道协议）

该协议是一种工业标准的Internet隧道协议，功能大致和PPTP协议类似，比如同样可以对网络数据流进行加密。不过也有不同之处，比如PPTP要求网络为IP网络，L2TP要求面向数据包的点对点连接；PPTP使用单一隧道，L2TP使用多隧道；L2TP提供包头压缩、隧道验证，而PPTP不支持。L2TP协议是由IETF起草，微软、Ascend、Cisco、3COM等公司参予制定的二层隧道协议，它结合了PPTP和L2F两种二层隧道协议的优点，为众多公司所接受，已经成为IETF有关2层通道协议的工业标准，基于微软的点对点隧道协议 (PPTP)和思科2层转发协议(L2F)之上的，被一个因特网服务提供商和公司使用使这个虚拟私有网络的操作能够通过因特网。

此段说明来自百度百科，如果想要更详细了解L2TP的相关介绍，可在搜索引擎中搜索，介绍的很详细这里就不重复描述了。

一、L2TP实现的两种方式

名词解释：

LAC(L2TP Access Concentrator L2TP访问集中器)

是附属在交换网络上的具有PPP端系统和L2TP协议处理能力的设备。LAC一般是一个网络接入服务器NAS，主要用于通过PSTN/ISDN网络为用户提供接入服务。

LNS(L2TP Network Server L2TP网络服务器）

是PPP端系统上用于处理L2TP协议服务器端部分的设备。

VPDN（Virtual Private Dial Network，虚拟私有拨号网）

指利用公共网络（如ISDN和PSTN）的拨号功能及接入网来实现虚拟专用网。

注：如下示例中使用的防火墙（Firewall，FW）既可以当做LAC也可以作为LNS使用。

1、PC直接拨号到LNS，组网如图1所示

图1

2、PC通过LAC拨号连接到LNS，组网如图2所示

图2

因为一般都使用用PC---LAC---LNS组网，且此种组网包含了PC---LNS的组网形态，故后续描述均已PC---LAC---LNS为例。

LAC位于LNS和主机之间，用于在LNS和主机之间传递信息包，把从主机收到的信息包按照L2TP协议进行封装并送往LNS，将从LNS收到的信息包进行解封装并送往远端系统。LAC与主机之间可以采用本地连接或PPP链路，VPDN应用中通常为PPP链路。LNS作为L2TP隧道的另一侧端点，是LAC的对端设备，是被LAC进行隧道传输的PPP会话的逻辑终止端点。

二、L2TP封装位置分析

如下图3所示，从图中至上而下的分析，为PC的报文在PPP内网环境中发送到LAC，由LAC封装L2TP，再通过外网的报文正常转发给LNS的报文封装过程。

注：设计的网络环境为PC---LAC为内网使用PPP协议，LAC---LNS为外网使用协议由服务供应商自定。

图3

三、理解L2TP几个重要的概念

1、隧道和会话的概念

在一个LNS和LAC对之间存在着两种类型的连接，一种是隧道（Tunnel）连接，一对LAC和LNS中可以有多个L2TP隧道；另一种是会话（Session）连接，它复用在隧道连接之上，用于表示承载在隧道连接中的每个PPP会话过程。

隧道由一个控制连接和一个或多个会话（Session）组成。会话连接必须在隧道建立（包括身份保护、L2TP版本、帧类型、硬件传输类型等信息的交换）成功之后进行，每个会话连接对应于LAC和LNS之间的一个PPP数据流。控制消息和PPP数据报文都在隧道上传输。

L2TP使用Hello报文来检测隧道的连通性。LAC和LNS定时向对端发送Hello报文，若在一段时间内未收到Hello报文的应答，该隧道连接将被断开。
L2TP报文头中包含隧道标识符（Tunnel ID）和会话标识符（Session ID）信息，用来标识不同的隧道和会话。隧道标识相同、会话标识不同的报文将被复用在一个隧道上，报文头中的隧道标识符与会话标识符由对端分配。

隧道（tunnel）和会话（session）的关系，如图4所示；可以形象的理解为会话是建立在隧道之中的，隧道想成一个有10个车道的高速公路，一台拨号PC的数据流为一个会话，相当于占用了一个车道（告诉公路有多少车道是设备规定好的），这个车道只能跑这个运载这个PC的报文的卡车。（比如某型号设备每条隧道最多支持1000个会话）。

图4

2、控制消息和数据消息的概念

L2TP中存在两种消息：控制消息和数据消息。

控制消息：用于隧道和会话连接的建立、维护以及传输控制；控制消息的传输是可靠传输，并且支持对控制消息的流量控制和拥塞控制。
数据消息：用于封装PPP帧并在隧道上传输；数据消息的传输是不可靠传输，若数据报文丢失，不予重传，不支持对数据消息的流量控制和拥塞控制。

控制消息和数据消息共享相同的报文头。

四、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响应消息CHAP response，并发送LNS侧的CHAP challenge，LAC返回该challenge的响应消息CHAP response；

(8) 隧道验证通过；

(9) LAC端将用户CHAP response、response identifier和PPP协商参数传送给LNS；

(10) LNS将接入请求信息发送给RADIUS服务器进行认证；

(11) RADIUS服务器认证该请求信息，如果认证通过则返回响应信息；

(12) 若用户在LNS侧配置强制本端CHAP认证，则LNS对用户进行认证，发送CHAP challenge，用户侧回应CHAP response；

(13) LNS再次将接入请求信息发送给RADIUS服务器进行认证；

(14) RADIUS服务器认证该请求信息，如果认证通过则返回响应信息；

(15) 验证通过，用户访问企业内部资源。

注：此节如下附加内容涉及到报文协商，前面没有介绍，可以先了解L2TP笔记2中关于报文格式与协商的相关内容，再回头深入分析此节，此节放在这里是为了便于对于整体协商过程进行深入分析。

附加:2、针对流程中步骤7、步骤12的Challenge验证过程的分析

(1)LAC向LNS发SCCRQ请求消息时，会产生一个随机的字符串做为本端CHAP Challenge发给LNS。

(2)LNS收到这个Challenge后，再加上本端配置的密码及SCCRP产生一个新的字符串，用MD5算出一个16个字节的Response，在SCCRP消息中发给LAC。

同时也产生一个随机的字符串(LNS Challenge)放在SCCRP中一起发给LAC。

(3)LAC将自己的CHAP Challenge加上本端配置的密码，再加上SCCRP产生一个新字符串，用MD5算出一个16字节的字符串，并与LNS发来的SCCRP中带的LNS CHAP Response比较，相同通过，不同断掉。

(4)同理LNS也要验证LAC，LAC用在SCCRP中发现的LNS CHAP Challenge加上本端密码和SCCCN组合，再用MD5算出一个16字节的字符串做为LAC CHAP Response在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 Version 1(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对端接收到的PPP Authentication Response。

参考文献:
1、H3C产品手册

2、华为培训资料

3、百度知道

4、学习笔记