L2TP协议原理.doc

L2TP协议原理

一.L2TP协议结构
图1-1 L2TP协议结构

图1-1描述了PPP帧和控制通道以及数据通道之间的关系：PPP帧在不可靠的L2TP数据通道内传输，控制消息在可靠的L2TP控制通道内传输。
L2TP数据报文和控制报文全部以UDP报文形式发送。数据消息不重发，不能保证可靠性；控制消息使用流控和重发机制，能保证可靠传输。L2TP注册了UDP端口1701，这个端口号仅用于初始隧道建立过程。L2TP隧道发起方任选一个空闲端口（未必是1701）向接收方的1701端口发送报文；接收方收到报文后，也任选一个空闲端口（未必是1701），给发送方的指定端口回送报文。至此，双方的端口选定，并在隧道连通的时间内不再改变。
二.L2TP报文头
L2TP的控制消息和数据消息使用相同的报文头。
图1-2 L2TP报文头格式

L2TP报文头中标记为可选（opt）的字段，是指在数据消息中可选，在控制消息中则是必选的。
表1-1 L2TP报文头字段描述
字段名
含义
取值要求
T
类型（Type），取值为“0”时表示数据消息，取值为“1”时表示控制消息
－
L
长度在位标志，取值为“1”时表示报文头中存在长度字段Length
控制消息中必须为“1”
x
保留位
－
S
顺序字段在位标志，取值为“1”时表示报文头中存在Ns和Nr字段
控制消息中必须为“1”
O
取值为“1”时表示报文头中存在offset size字段
控制消息中必须为“0”
P
优先级（Priority），只用于数据消息
控制消息中必须为“0”
Ver
版本号
对于L2TPv2协议取值为“2”
Length
消息的总长度，单位为字节
－
Tunnel ID
隧道标识符，只具有本地意义
Hello控制消息具有全局性，其Tunnel ID必须为0。
Session ID
会话标识符，只具有本地意义
－
Ns
当前消息的顺序号
－
Nr
希望接收的下一条控制消息的顺序号
数据消息中是保留字段
offset size
偏移值，指示载荷数据开始的位置
－
offset padding
填充位
－

L2TP报文头中包含隧道标识符（Tunnel ID）和会话标识符（Session ID）信息，隧道标识符与会话标识符由对端分配，用来标识不同的隧道和会话。隧道标识相同、会话标识不同的报文将被复用在一条隧道上。

三.L2TP数据报文结构
用户PPP报文（已携带源IP报文头及PPP报文头）在公共网络上以IP报文形式传输时携带以下协议头：
l 1个L2TP报文头（16字节）
l 1个UDP报文头（8字节）
l 1个新IP报文头（20字节），指示L2TP隧道的源地址和目的地址
L2TP数据报文的格式如图1-3。
图1-3 L2TP数据报文的格式

LAC收到PPP报文后，进行如下封装：
l 首先为其封装L2TP报文头；
l 接着封装UDP报文头
l 然后封装新的IP头，并从连接公共网络的接口发送出去。

L2TP协议本身没有数据分片功能，但是在进行IP封装时，可以在需要时进行分片。为保证报文不分片，封装后的报文大小不能超过实际接口的MTU。
LNS从连接公共网络的接口收到该报文后，进行如下处理：
l 去掉IP头和UDP头，将报文送往L2TP协议模块；
l L2TP协议剥离L2TP协议头和PPP头，将该报文还原为用户IP报文，并发送到私网内部服务器。
四.控制连接和会话连接的建立过程
消息报文
在VRP的实现中，控制连接和会话连接的建立过程中涉及的消息包括：
1.SCCRQ（Start-Control-Connection-Request）：用来向对端请求建立控制连接。
2.SCCRP（Start-Control-Connection-Reply）：用来告诉对端，本端收到了对端的ACCRQ消息，允许建立控制连接。
3.SCCCN（Start-Control-Connection-Connected）：用来告诉对端，本端收到了对端的SCCRP消息，本端已完成隧道的建立。
4.StopCCN（Stop-Control-Connection-Notification）：用来通知对端拆除控制连接，本端已清除所有会话连接，将关闭隧道接口。StopCCN中携带了发送端控制连接拆除原因。
5.ICRQ（Incoming-Call-Request）：只有LAC才会发送；每当检测到用户的呼叫请求，LAC就发送ICRQ消息给LNS，请求建立会话连接。ICRQ中携带会话参数。
6.ICRP（Incoming-Call-Reply）：只有LNS才会发送；收到LAC的ICRQ，LNS就使用ICRP回复，表示允许建立会话连接。
7.ICCN（Incoming-Call-Connected）：只有LAC才会发送；LAC收到LNS的ICRP，就使用ICCN回复，表示LAC已回复用户的呼叫，通知LNS建立会话连接。
8.CDN（Call-Disconnect-Notify）：用来通知对端拆除会话连接，并告知对端拆除的原因。
9.Hello：用来检测隧道的连通性。
10.ZLB（Zero-Length Body）：如果本端的队列没有要发送的消息时，发送ZLB给对端。在会话连接和控制连接的拆除过程中，发送ZLB还表示收到StopCCN或CDN。ZLB只有L2TP头，没有负载部分，因此而得名。
控制连接的建立和拆除期间包含以下过程：
1.控制连接的建立
2.会话连接的建立
3.控制连接的维持
4.会话连接的拆除
5.控制连接的拆除
控制连接的建立
控制连接的建立先于会话连接。只有控制连接建立起来了，会话连接才可能建立起来。L2TP的控制连接建立过程如图1-4。
图1-4 控制连接建立的三次握手

1. LAC和LNS之间路由相互可达后，LAC端设置相应AVP，向LNS端发出SCCRQ报文，请求建立控制连接。
2. LNS收到来自LAC的SCCRQ。根据其中的AVP，如果同意建立隧道，便发送SCCRP报文给LAC。
3. LAC对接收到的SCCRP报文进行检查，从中取出隧道信息，并向LNS发送SCCCN报文，表示控制连接建立成功。
4. 当消息队列中没有消息时，LNS发送ZLB给对端。
在VRP中，使用display l2tp tunnel命令可以查看本设备上成功建立了哪些控制连接。
会话连接的建立
控制连接成功建立之后，一旦检测到用户呼叫，就请求建立会话连接。与控制连接不同的是，会话连接的建立具有方向性。在VRP中，会话连接请求是由LAC发起的。会话连接建立过程如图1-5。
图1-5 会话连接建立过程

L2TP的会话建立由PPP触发。
在VRP中，使用display l2tp session命令可以查看本设备上成功建立了哪些会话连接。
控制连接的维持
L2TP使用Hello报文检测隧道的连通性。LAC和LNS定时向对端发送Hello报文，若在一段时间内未收到Hello报文的应答，则重复发送Hello报文。如果重复发送报文的次数超过3次，则认为L2TP隧道已经断开，该PPP会话将被清除。此时需要重新建立隧道。
VRP中Hello报文发送的时间间隔可以手工设置。缺省情况下，Hello报文每隔60秒发送一次。LNS和LAC侧可以设置不同的Hello报文时间间隔。
会话连接的拆除
会话连接拆除的发起端可以是LAC或LNS。发起端通过发送CDN消息报文到对端来通知对端拆除会话连接。对端收到后发送ZLB ACK消息作为回应。图1-6是LAC侧发起会话连接拆除的过程。
图1-6 L2TP会话连接的拆除

控制连接的拆除
控制连接拆除的发起端可以是LAC或LNS。发起端通过发送StopCCN消息报文到对端来通知对端拆除控制连接。对端收到后发送ZLB ACK消息作为回应，同时在一定时间内保持控制连接以防止ZLB ACK消息丢失。图1-7是LAC侧发起控制连接拆除的过程。
图1-7 L2TP控制连接的拆除

五.隧道验证过程
隧道验证是和建立隧道同时进行的，不是单独进行的。
隧道验证过程如下：
1.首先LAC向LNS发SCCRQ请求消息时，产生一个随机的字符串作为本端的CHAP Challenge（SCCRQ携带的字段）发给LNS。
2.LNS收到SCCRQ后，利用SCCRQ携带的CHAP Challenge和本端配置的密码产生一个新的字符串，用MD5算出一个16个字节的Response；同时也产生一个随机的字符串（LNS Challenge），将Response和LNS Challenge放在SCCRP中一起发给LAC。
3.LAC端收到SCCRP后，对LNS进行验证：
− 利用自己的CHAP Challenge、本端配置的密码、SCCRP，产生一个新的字符串；
− 用MD5算出一个16字节的字符串；
− 与LNS端发来的SCCRP中带的LNS CHAP Response做比较，如果相同，则隧道验证通过，否则隧道验证不通过，断掉隧道连接。
4.如果验证通过，LAC将自己的CHAP Response放在SCCCN消息中发给LNS。
5.LNS收到SCCCN消息后，也进行验证：
− 利用本端的CHAP Challenge、本端配置的密码、SCCCN，得到一个字符串；
− 然后用MD5算出一个16字节的字符串；
− 与SCCCN消息中得到的LAC CHAP Response做比较。如果相同，则验证通过，否则拆除隧道。
六.L2TP隧道会话的建立过程
L2TP的典型组网如图1-8所示：
图1-8 L2TP隧道的典型组网示意图

进行隧道验证的L2TP隧道呼叫建立流程如图1-9。
图1-9 L2TP隧道的呼叫建立流程

1. 用户端PC机发起呼叫连接请求；
2. PC机和LAC端（RouterA）进行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. 验证通过，用户访问企业内部资源。
七.LNS对用户的认证方式
LNS可对用户进行两次验证：第一次发生在LAC侧，第二次发生在LNS侧。只有一种情况LNS侧不对接入用户进行二次验证：启用LCP重协商后，不在相应的虚拟接口模板上配置验证。这时，用户只在LAC侧接受一次验证。其他情况都进行二次验证，验证模式（Authentication-mode）为“none”也算一种验证。
LNS侧对用户的验证方式有三种：代理验证、强制CHAP验证和LCP重协商。其中，LCP重协商的优先级最高，LCP重协商优先级最低。
LCP重协商
如果需要在LNS侧进行比LAC侧更严格的认证，或者LNS侧需要直接从用户获取某些信息（当LNS与LAC是不同厂商的设备时可能发生这种情况），则可以配置LNS与用户间进行LCP重协商。LCP重协商使用相应虚拟接口模板VT上配置的验证方式。此时将忽略NAS侧的代理验证信息

强制CHAP验证
如果只配置强制CHAP验证，则LNS对用户进行CHAP验证，如果验证不过的话，会话就不能建立成功。
代理验证
如果既不配置LCP重协商，也不配置强制CHAP验证，则LNS对用户进行的是代理验证。
代理验证就是LAC将它从用户得到的所有验证信息及LAC端配置的验证方式传给LNS，LNS会利用这些信息和LAC端传来的验证方式对用户进行验证。
对由NAS发起的VPN服务请求（NAS-Initialized VPN），在PPP会话开始时，用户先和NAS进行PPP协商。若协商通过，则由NAS初始化L2TP通道连接，并将用户信息传递给LNS，由LNS根据收到的代理验证信息，判断用户是否合法。
当LNS使用代理验证时，如果虚拟接口模板VT配置的验证方式为CHAP，而LAC端配置的验证方式为PAP，则由于LNS要求的CHAP验证级别高于LAC能够提供的PAP验证，验证将无法通过，会话也就不能正确建立。
如果在LAC端使用AAA NONE的认证方式，那么无论LAC侧采用PAP验证还是CHAP验证，AAA都不会认证。但送到LNS端以后，LNS端就采用AAA配置的认证方式（如Local、Radius或者NONE）进行认证。
代理验证与VT上的验证方式也有关系：
l VT上的验证方式不能比LAC侧复杂。如果LAC侧的验证方式为PAP，但LNS的VT上的验证方式为CHAP，则验证不通过。
l 其他情况下，采用LAC传来的验证方式，不管VT上配的是什么验证方式。

八.L2TP隧道交换
应用环境
随着组网方式的多样化，VPDN的使用也越来越灵活。在某些组网环境中，一个会话可能需要跨越多个隧道才能到达目的地。隧道交换（Tunnel Switch）就是为了解决会话从一个隧道交换到另一个隧道而提出的一种新技术。
图1-10 隧道交换组网

在图1-10中，LAC和LNS之间增加一台设备RouterB作为TUNLSW。
隧道交换原理
PC1访问PC2的过程如下：
1. PC1首先向LAC发起隧道建立请求，但它的目的地不是RouterC（LNS），而是中间的TUNLSW，这样，LAC和TUNLSW之间先建立一条隧道和会话；
2. TUNLSW发现这个会话的终结点不是自己后，向真正的LNS发起隧道建立请求；
3. TUNLSW将自己与LAC建立的会话续传到与LNS新建立的隧道上；
4. 会话到达真正的LNS后终结，建立真正的PPP连接。这样，PC1就可以访问PC2了。
在这个过程中，会话在TUNLSW设备上从LAC与TUNLSW建立的隧道上交换到了TUNLSW和LNS建立的隧道上，即，由TUNLSW设备完成会话的隧道交换。就像乘坐公共汽车，第一次不能到达目的地，需要在中间站换乘一次才能到达目的地。TUNLSW设备就是会话的中转站，它通过隧道交换技术来实现会话的中转。图1-10是一个比较简单的例子，在实际组网可能需要中转更多次才能到达真正的LNS。
TUNLSW设备上需要两个L2TP组，一个组用作TUNLSW作为LNS接受LAC发起的隧道建立请求，另一个组用作TUNLSW作为LAC向新的TUNLSW或LNS发起新的隧道建立请求。
有多种协议可用于实现隧道交换，包括L2TP协议。使用L2TP实现隧道交换的解决方案也称为Multi-Hop L2TP。