1.协议封装
在L2TP隧道中，L2TP的控制通道和数据通道都采用同样的L2TP头格式，如图5.42所示。只是其中的具体字段有所不同。
图5.42 L2TP头格式
其中主要字段解释如下：
（1）Type（T）bit 表明消息的类型。“1”表示此消息是控制消息，“0”表示此消息是数据消息。
（2）Ver 必须设置为2。
（3）Tunnel ID 是L2TP控制连接的标识符，也就是L2TP隧道的标识符。Tunnel ID是在隧道建立时通过Assigned Tunnel ID AVP交换的。
（4）session ID 用来标识一个隧道中的各个会话。Session ID是在隧道建立时通过Assigned Session ID AVP交换的。
（5）NS 这是一个数据消息或者控制消息的序列号。由0开始，递增到216，可用于确保消息的正确传送。
（6）Nr 这是对下一个收到的控制消息的序列号的预期。
在IP网络中，L2TP以UDP／IP作为承载协议，使用IANA注册的UDP端口1701。整个的L2TP报文，包括L2TP头及其载荷，都封装在UDP数据报中发送。
L2TP采用UDP端口1701作为服务端口。发起隧道呼叫时，使用任意UDP源端口及目的端口1701发起呼叫。但随后的通信将会被重定向到任意端口。
下面以一个用户侧向服务器侧的IP报文传递过程来描述L2TP VPN工作原理：
（1）原始用户数据为IP报文，先经过PPP封装，发送到LAC。
（2）LAC的链路层将PPP帧传递给L2TP协议，L2TP对其执行L2TP封装，再将其封装成UDP，并继续封装成可以在Internet上传输的IP报文。此时的结果就是IP报文中有PPP帧，帧中封装IP报文。不过，两个IP地址不同，用户报文的IP地址是私有地址，而LAC上的IP地址为公有地址。至此完成了VPN的私有数据的封装。LAC将此报文通过相应的隧道和会话发送到LNS。
（3）在LNS侧收到VPN封装的IP报文后，依次将IP，UDP，L2TP报文头去掉，就恢复了用户的PPP报文，并交送到PPP协议进行处理。将PPP报文头去掉就可以得到IP报文，然后可以根据IP头做相应操作，例如处理或转发。从服务器侧向客户侧方向上的报文传递过程恰恰相反，这里不再赘述。过程如图5.43所示。
图5.43 L2TP协议栈和封装过程
图5.44 建立控制连接
为了在VPN用户和服务器之间传递数据报文，必须在LAC和LNS之间建立传递数据报文的隧道。所以，建立一个控制连接是一切会话的基础。在隧道建立过程中，双方需要互相检查对方的身份，并协商一些参数。过程如图5.44所示。
控制连接时，通常：
（1）首先由LAC发起隧道建立请求SCCRQ（start－control－connection－request）。
（2）LNS收到请求后用SCCRP（start－control－connection－reply）进行应答。
（3）LAC在收到应答后返回确认SCCCN（start－control－connection－connected）。
（4）LNS收到SCCCN后，用ZLB（zero－length body）消息作为最后应答，隧道建立。
其中ZLB消息是一个只有L2TP头的控制消息，其作用是作为一个明确应答，以确保控制消息的可靠传递。
在控制连接建立的过程中，L2TP可以执行一个类似于CHAP的隧道验证过程。LAC或LNS均可用此方法验证对方的身份。这个验证过程与CHAP非常类似，LAC和LNS可以在SCCRQ或SCCRP消息中添加Challenge AVP，发起验证。接收方必须在SCCRP或SCCCN消息中以Challenge Response AVP响应验证过程。如果验证不通过，隧道就无法建立。
为了传送用户数据，在建立了控制连接后，就需要为用户建立会话。多个会话复用在一个隧道连接上。会话的建立是由PPP模块触发，如果该会话在建立时没有可用的隧道，那么先建立隧道连接。会话建立完毕后，才开始进行用户数据传输。
图5.45 建立会话
会话建立的过程与控制连接的建立过程类似，如图5.45。
通常LAC首先接收到一个入站呼叫，触发会话的建立过程：
（1）LAC发起会话建立请求ICRQ（ineomingcall－request）。
（2）LNS收到请求后返回应答ICRP（ineomingcall－reply）。
（3）LAC收到应答后返回确认ICCN（incomingcall－connected）。
（4）LNS收到ICCN后，用ZLB消息作为最后应答，会话建立。
LNS也可以发起会话的建立过程：
（1）LNS发起会话建立请求OCRQ（outgoing－call－request）。
（2）LAC返回1应答OCRP（outgoing－call－reply）。
（3）LAC执行呼叫。
（4）呼叫成功后，LAC返回确认OCCN（outgoing－call－connected）。(www.xing528.com)
（5）LNS收到OCCN后，用ZLB消息作为最后应答，会话建立。
一旦会话建立，就可以为用户转发数据了。
如前所述，用户数据实际上是PPP帧。这些PPP帧从远程系统到达LAC后，被传递给L2TP协议，L2TP对其添加L2TP头，并以正确的Tunnel ID和Session ID对其隧道和会话属性进行标识，然后再将其封装成UDP，并继续封装成可以在Internet上传输的IP报文，LAC将此报文通过相应的隧道和会话发送到LNS。
LNS侧收到这些IP报文后，依次将IP，UDP，L2TP报文头去掉，就恢复了用户的PPP报文。LNS根据相应的Tunnel ID Session ID将其递交给正确的处理点（例如一个Virtualtemplate接口）的。PP协议进行处理，将PPP报文头去掉就可以得到IP报文，然后可以根据IP头做相应操作，例如处理或转发。
相反的方向上执行的操作也是类似的。
为了掌握信息，了解隧道的运作情况，L2TP的LAC和LNS使用Hello控制消息维持彼此的状态，如图5.46所示。
图5.46 L2TP用Hello控制消息维护隧道的状态
图5.47 关闭会话
隧道端点双方均可以要求关闭一个会话。会话的关闭并不影响隧道的运转。
如图5.47所示，若LAC试图关闭一个会话，则其首先发送一个CDN（call－disconnectnotify）消息，通告对方关闭会话；当对方收到CDN后，以ZLB消息作为级后应答，会话关闭。
图5.48 关闭控制连接
隧道端点双方均可以要求关闭一个隧道。关闭隧道的同时，该隧道的所有会话均会关闭。
如图5.48所示，若LAC试图关闭一个隧道，则其首先发送一个StopCCN（stop－control－connectionnotification）消息，通告对方关闭控制连接；对方收到StopCCN后，以ZLB消息作为最后应答，控制连接关闭。
2.L2TP的验证过程
L2TP的验证如图5.49所示，分为以下步骤：
图5.49 L2TP的验证过程
第1步：用户端PC机发起呼叫连接请求；
第2步：PC机和LAC进行PPP LCP协商，确保之间的物理链路正常；
第3步：LAC对PC机提供的用户信息进行PAP或CHAP认证；
第4步：LAC将认证信息（用户名、密码）发送给RADIUS服务器进行认证；
第5步：RADIUS服务器认证该用户，如果认证通过则返回该用户对应的LNS地址等相关信息，并准备发起Tunnel连接请求；
第6步：LAC端向指定LNS发起Tunnel连接请求；
第7步：LAC端向指定LNS发送SCCRQ消息，其中包含LAC侧的CHAP challenge信息；
第8步：LNS回送SCCRP消息给LAC端，其中包括对接收到的LAC侧challenge的响应消息CHAP response，和LNS侧的CHAP challenge；
第9步：LAC端向该LNS发送SCCCN消息，通知LNS隧道验证通过，其中包括对LNS侧challenge的响应消息CHAP response；
第10步：LNS通知LAC端隧道验证通过；
第11步：LAC端将用户CHAP response，response identifier和ppp协商参数传送给LNS；
第12步：LNS将接入请求信息发送给RADIUS服务器进行认证；
第13步：RADIUS服务器认证该请求信息，如果认证通过则返回响应信息；
第14步：若用户在LNS侧配置强制本端CHAP认证，则LNS对用户进行认证，发送CHAP challenge；
第15步：用户侧回应CHAP response；
第16步：LNS再次将接入请求信息发送给RADIUS服务器进行认证；
第17步：RADIUS服务器认证该请求信息，如果认证通过则返回响应信息；
第18步：验证通过，用户访问企业内部资源。
不难发现，L2TP的验证可以包括3个部分：
①对拨入的远程系统的初始PPP验证。
②对LAC和LNS之间隧道的验证。
③LNS对远程系统的再次PPP验证。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
