L2TP详解（二）

今天继续给大家介绍HCIE安全。本文给大家介绍的是L2TP相关内容，包括L2TP的特点和应用场景。
强烈推荐阅读本文前置文章：
L2TP详解（一）

一、L2TP隧道和会话建立过程

在LAC和LNS之间存在着两种类型的链接：隧道链接和会话链接。
隧道链接定义了互相通信的两个实体——LAC和LNS。并且在一对LAC和LNS之间可以建立多个L2TP隧道，隧道由一个控制链接和至少以下会话组成。L2TP首先需要建立L2TP隧道，然后再L2TP隧道上建立会话链接，最后建立PPP链接。所有的L2TP需要承载的数据信息都是在PPP链接中进行传递的。
会话链接复用在隧道链接之上，用于表示承载在隧道链接中的每个PPP链接过程，会话是有方向的，从LAC向LNS发起的会话叫做Incoming会话，从LNS向LAC发起的会话叫做Outgoing会话。
总得来看，在L2TP中，总是先有隧道，后有会话。LAC和LNS之间可以建立多条隧道，每一条隧道又可以承载多条会话。

二、L2TP三种场景区别

在上文中，我们介绍了L2TP三种场景，分别是是NAS-Initiated VPN、LAC-Auto-Initiated VPN和Client-Initiated VPN。这三种场景区别如下：

项目	Client-Initiated VPN	NAS-Initiated VPN	LAC-Auto-Initiated VPN
协商方式	L2TP Client和LNS协商建立L2TP隧道和L2TP会话，建立PPP链接	接入用户使用PPPoE拨号触发LAC和LNS之间协商建立L2TP隧道和L2TP会话，接入用户和LNS协商建立PPP链接	LAC主动拨号和LNS协商建立L2TP隧道和L2TP会话，建立PPP链接
隧道和会话关系	每个L2TP Client和LNS之间均建立一条L2TP隧道，每条隧道中仅承载一条L2TP会话和PPP链接	LAC和LNS的链接可以存在多条L2TP隧道，一条L2TP隧道可以承载多条L2TP会话	LAC和LNS之间建立一条永久的L2TP隧道，且仅承载一条永久的L2TP会话和PPP链接
安全性	LNS对L2TP Client进行PPP认证，安全性较高	LAC对接入用户进行认证，LNS对接入用户进行二次认证（可选），安全性最高	LAC不对用户进行认证，LNS对LAC配置的用户进行PPP认证，安全性低
回程路由配置	LNS上会自动下发UNR路由，指导回程报文进入L2TP隧道，无需手动配置	LNS上会自动下发UNR路由，指导回程报文进入L2TP隧道，无需手动配置	LNS上需要手动配置到目的地址为网段的静态路由，或者在LAC上配置easy-ip方式的源NAT
地址分配	LNS直接给用户下发地址	LNS直接给用户下发地址	LNS为LAC分配地址

三、L2TP控制消息和数据消息

在L2TP隧道和会话的建立过程中，存在控制消息和数据消息两种大的消息类型。
控制消息用于隧道和会话连接的建立、维护以及传输控制，位于隧道和会话建立过程中。控制消息的传输是可靠传输，并且支持对控制消息的流量控制和拥塞控制。控制消息又分为控制报文和会话报文。控制报文用于建立、拆除和维护隧道，会话报文用于建立和拆除会话。
数据消息用于承载用户的PPP链接数据报文，并在隧道上进行传输。数据消息的传输是不可靠的，若数据报文丢失，不予重传，也不支持对数据消息的流量控制和拥塞控制。
L2TP各种类型的控制消息和数据消息如下表所示：

四、L2TP认证方式

（一）NAS-Initiated VPN

在NAS-Initiated VPN中，L2TP可以对用户进行两次PPP认证，第一次发生在LAC侧，第二次发生在LNS侧。只有一种情况LNS侧不对接入用户进行二次认证，即启用LCP重协商后，不再相应的VT接口上配置认证。这时，用户只在LAC侧接受一次认证。

（二）LAC-Auto-Initiated VPN

在LAC-Auto-Initiated VPN场景中，LAC侧不对用户进行认证，只在LNS侧对LAC配置的用户进行PPP认证。

（三）Client-Initiated VPN

在Client-Initiated VPN场景中，在LNS侧对用户进行PPP认证。

（四）LNS二次认证方式

对于LNS设备而言，对LAC用户信息的处理有以下三种方式：
1、LAC代理认证：相信LAC是可靠的，直接在LAC发来的用户信息进行认证。
2、强制CHAP认证：不相信LAC，要求重新对用户进行认证。
3、LCP重协商：不仅不相信LAC，还要重新发起LCP协商，协商MRU参数和认证方式。
在上述三种方式种，后两种方式被称为LNS二次认证，若LNS配置二次认证而PPPoE Client不支持二次认证，将会导致L2TP VPN无法建立。
原创不易，转载请说明出处：https://blog.csdn.net/weixin_40228200/article/details/119361305