VPN技术：L2TP 介绍

1、L2TP 基本概念

二层隧道协议L2TP（Layer 2 Tunneling Protocol）是虚拟私有拨号网VPDN（Virtual Private Dial-up Network）隧道协议的一种，它扩展了点到点协议PPP（Point-to-Point Protocol）的应用，是应用于远程办公场景中为出差员工远程访问企业内网资源提供接入服务的一种重要VPN技术。

L2TP的典型组网如上，企业分支或者出差员工通过公共网络与总部之间建立L2TP隧道，在L2TP中涉及到如下几个概念。

PPP 终端

L2TP应用中，PPP终端指发起拨号，将数据封装为PPP类型的设备，如远程用户PC、企业分支网关等均可作为PPP终端。

NAS

NAS网络接入服务器（Network Access Server）主要由ISP维护，用于连接拨号网络，是距离PPP终端地理位置最近的接入点。NAS用于传统的拨号网络中，ISP在NAS上部署LAC，可为远程拨号用户提供L2TP服务，和企业总部建立隧道连接。

这里来讲， ppp 终端并不知道 L2TP 隧道的存在，只需要通过 ppp 拨号到 NAS，建立 ppp 链路用于传输 网络层及以上的的报文，由 NAS 进行转发。

LAC

L2TP访问集中器LAC是交换网络上具有PPP和L2TP协议处理能力的设备。LAC根据PPP报文中所携带的用户名或者域名信息，和LNS建立L2TP隧道连接，将PPP协商延展到LNS。

在不同的组网环境中，LAC可以是不同的设备：

• NAS-Initiated场景：在传统的拨号网络中，ISP在NAS上部署LAC，或在企业分支的以太网络中，为PPP终端配备网关设备，网关作为PPPoE服务器，同时部署为LAC。
• L2TP Client-Initiated场景：企业分支在网关设备配置可以主动向LNS发起L2TP隧道连接请求的L2TP Client，不需要远端系统拨号触发，L2TP Client为LAC。
• Client-Initiated场景：出差人员使用PC或移动终端接入Internet，在PC或移动终端上使用L2TP拨号软件，则PC或移动终端终端为LAC。

LAC可以发起建立多条L2TP隧道使数据流之间相互隔离。

LNS

L2TP网络服务器LNS是终止PPP会话的一端，通过LNS的认证，PPP会话协商成功，远程用户可以访问企业总部的资源。对L2TP协商，LNS是LAC的对端设备，即LAC和LNS建立了L2TP隧道；对PPP，LNS是PPP会话的逻辑终止端点，即PPP终端和LNS建立了一条点到点的虚拟链路。

LNS位于企业总部私网与公网边界，通常是企业总部的网关设备。必要时，LNS还兼有网络地址转换（NAT）功能，对企业总部网络内的私有IP地址与公共IP地址进行转换。

隧道和会话

在LAC和LNS的L2TP交互过程中存在两种类型的连接。

• 隧道（Tunnel）连接

  L2TP隧道在LAC和LNS之间建立，一对LAC和LNS可以建立多个L2TP隧道，一个L2TP隧道可以包含多个L2TP会话。

• 会话（Session）连接

  L2TP会话发生在隧道连接成功之后，L2TP会话承载在L2TP隧道之上，每个L2TP会话对应一个PPP会话，PPP会话的数据帧通过L2TP会话所在的L2TP隧道传输。

2、L2TP基本原理

L2TP协议架构

L2TP协议包含两种类型的消息，控制消息和数据消息，消息的传输在LAC和LNS之间进行。L2TP协议通过这两种消息，扩展了PPP的应用。

• 控制消息

  用于L2TP隧道和会话连接的建立、维护和拆除。在控制消息的传输过程中，使用消息丢失重传和定时检测隧道连通性等机制来保证控制消息传输的可靠性，支持对控制消息的流量控制和拥塞控制。

• 数据消息

  用于封装PPP数据帧并在隧道上传输。数据消息是不可靠的传输，不重传丢失的数据报文，不支持对数据消息的流量控制和拥塞控制。

下图说明了PPP报文、控制消息和数据消息在L2TP协议架构中的位置和关系。

控制消息承载在L2TP控制通道上，控制通道实现了控制消息的可靠传输，将控制消息封装在L2TP报头内，再经过IP网络传输。

数据消息携带PPP帧承载在不可靠的数据通道上，对PPP帧进行L2TP封装，再经过IP网络传输。

L2TP协议使用UDP端口1701，这个端口号仅用于初始隧道的建立。L2TP隧道发起方任选一个空闲端口向接收方的1701端口发送报文；接收方收到报文后，也任选一个空闲端口，给发起方的选定的端口回送报文。至此，双方的端口选定，并在隧道连通的时间内不再改变。

L2TP报文结构

远程用户拨号产生的PPP报文经L2TP封装后的报文格式如下图所示

L2TP报文进行了多次封装，比原始报文多出38个字节（如果需要携带序列号信息，则比原始报文多出42个字节），封装后报文的长度可能会超出接口的MTU值，而L2TP协议本身不支持报文分片功能，这时需要设备支持对IP报文的分片功能。当L2TP报文长度超出发送接口的MTU值时，在发送接口进行报文分片处理，接收端对收到分片报文进行还原，重组为L2TP报文。

3、L2TP 应用场景

3.1、Client-Initiated场景

从隧道协商和报文封装两方面介绍L2TP在Client-Initiated场景中的工作原理。

L2TP隧道协商

Client-Initiated场景，移动办公用户在访问企业总部服务器之前，需要先通过L2TP VPN软件与LNS建立L2TP隧道。下图所示是隧道协商的完整过程。

1. 移动办公用户与LNS建立L2TP隧道。

2. 移动办公用户与LNS建立L2TP会话。

   移动办公用户在第3步会与LNS间建立PPP连接，L2TP会话用来记录和管理它们之间的PPP连接状态。因此，在建立PPP连接以前，隧道双方需要为PPP连接预先协商出一个L2TP会话。会话中携带了移动办公用户的LCP协商信息和用户认证信息，LNS对收到的信息认证通过后，通知移动办公用户会话建立成功。L2TP会话连接由会话ID进行标识。

3. 移动办公用户与LNS建立PPP连接。

   移动办公用户通过与LNS建立PPP连接获取LNS分配的企业内网IP地址。

4. 移动办公用户发送业务报文访问企业总部服务器。

L2TP报文封装

报文的封装和解封装过程如下图所示。

1. 移动办公用户向企业总部服务器发送业务报文。

   业务报文通过L2TP拨号软件进行PPP封装和L2TP封装，然后按照移动办公用户PC的本地路由转发给LNS。

2. LNS接收到报文以后，拆除报文的L2TP头和PPP头，然后按照到企业内网的路由将报文转发给企业总部服务器。

3. 企业总部服务器收到移动办公用户的报文后，向移动办公用户返回响应报文。

3.2、NAS-Initiated场景

从隧道协商和报文封装两方面介绍L2TP在NAS-Initiated场景中的工作原理。

L2TP隧道协商

拨号用户在向企业内网发送业务数据以前，要先协商好传输数据所需的隧道信息。下图所示是拨号用户从发起访问请求，到NAS和LNS协商完成L2TP隧道，直至最后成功访问企业内网资源的完整过程。

1. 拨号用户与NAS建立PPPoE连接。

   拨号用户发出PPPoE广播报文寻找NAS接入设备，找到的NAS设备是其随后访问企业总部内网资源的隧道入口。

2. NAS与LNS建立L2TP隧道。

   PPPoE连接建立完成后，会触发NAS与LNS间协商L2TP隧道。NAS和LNS之间通过L2TP的控制消息、协商隧道ID和隧道认证等内容协商成功后则建立一条L2TP隧道，由隧道ID进行标识。

3. NAS与LNS建立L2TP会话。

   拨号用户在第4步会与LNS间建立PPP连接，L2TP会话用来记录和管理它们之间的PPP连接状态。因此，在建立PPP连接以前，隧道双方需要为PPP连接预先协商出一个L2TP会话。会话中携带了NAS的LCP协商信息和用户认证信息，LNS对收到的信息认证通过后，通知NAS会话建立成功。L2TP会话连接由会话ID进行标识。

4. 拨号用户与LNS建立PPP连接获取LNS分配的企业内网IP地址。

   1. （可选）LNS对拨号用户进行身份认证。

      在NAS-Initiated场景中，用户身份认证有两种方案，一种是仅使用NAS对用户做身份认证，另一种是NAS和LNS分别对用户做身份认证（也叫二次认证）。认证方案的选择由LNS侧的配置控制，LNS侧有如下三种身份认证方式。

      • 代理认证：表示仅使用NAS进行用户认证，LNS不再对用户进行二次身份认证。例如，步骤1中，拨号用户与NAS建立PPPoE连接时，NAS已经使用PAP/CHAP方式对拨号用户做了身份认证，则此处LNS将不做二次认证。
      • 强制CHAP认证：表示NAS认证完用户身份以后，LNS要求用户使用CHAP方式重新进行身份认证，该方式属于二次身份认证。
      • LCP重协商：表示LNS不信任NAS的认证结果，要求用户重新与LNS进行LCP协商并进行身份认证，该方式属于二次身份认证。

      身份认证完成后，拨号用户向LNS发送请求消息，请求LNS向其分配企业内网IP地址。

   2. LNS向拨号用户返回消息，此消息中携带了为拨号用户分配的企业内网IP地址（即LNS地址池中的IP地址），PPP连接建立完成。

5. 拨号用户发送业务报文访问企业总部。

   拨号用户使用企业分配的内网地址访问内网服务器，报文经过NAS和LNS的加解封装后到达对端。

L2TP报文封装

报文的封装和解封装过程如下图所示。

1. 拨号用户发出的原始数据经过PPP头和PPPoE头封装后发往NAS设备。

   由于PPPoE是点到点连接，PPPoE连接建立以后，拨号用户本地PC不用进行路由选择，直接将封装后的报文发送给NAS设备。

2. NAS设备使用VT（Virtual-Template）接口拆除报文的PPPoE头，再进行L2TP封装，然后按照到Internet的公网路由将封装后的数据发送出去。

3. LNS设备接收到报文以后，拆除报文的L2TP头和PPP头，然后按照到企业内网的路由进行报文转发。

4. 企业总部服务器收到拨号用户的报文后，向拨号用户返回响应报文。

3.3、L2TP Client-Initiated场景

从隧道协商和报文封装两方面介绍L2TP在L2TP Client-Initiated场景中的工作原理。

L2TP隧道协商

L2TP Client-Initiated场景，L2TP Client和LNS配置完L2TP以后，L2TP Client会主动向LNS发起隧道协商请求。下图所示是隧道协商的完整过程。

1. L2TP Client与LNS建立L2TP隧道。

2. L2TP Client与LNS建立L2TP会话。

   L2TP Client在第3步会与LNS间建立PPP连接，L2TP会话用来记录和管理它们之间的PPP连接状态。因此，在建立PPP连接以前，隧道双方需要为PPP连接预先协商出一个L2TP会话。

3. L2TP Client与LNS建立PPP连接。

   L2TP Client通过与LNS建立PPP连接获取LNS分配的企业内网IP地址。

4. 企业分支员工发送访问企业总部服务器的业务报文，报文经过L2TP Client和LNS的加解封装后到达对端

L2TP报文封装

报文的封装和解封装过程如下图所示。

1. 企业分支员工向总部内网服务器发送访问请求。

   分支员工的PC按照本地路由将请求报文转发给L2TP Client。

2. L2TP Client收到报文后使用VT（Virtual-Template）接口对此报文进行PPP封装和L2TP封装。

   报文封装完成后L2TP Client再按照到Internet的公网路由将封装好的报文发送出去。

3. LNS设备接收到报文以后，使用VT接口拆除报文的L2TP头和PPP头，然后按照到企业内网的路由将报文转发给总部内网服务器。

4. 企业总部服务器收到分支员工的报文后，向分支员工返回响应报文。

4、L2TPv3 介绍

二层隧道协议第三版L2TPv3(Layer Two Tunneling Protocol - Version 3)是一种二层隧道技术，可以透传多种二层报文（如PPP、Ethernet、HDLC、ATM等），运用于用户侧的二层接入链路在分组交换网络中透明传递。

用户需要在分支和总部或者分支之间建立二层连接时，可以通过部署VLL（Virtual Leased Line）来实现，但是VLL的部署成本太高。通过L2TPv3提供二层连接，只做以太二层透传，不用对现有的IP网络做升级改造，从而节省运营商网络建设投资，使各企业可以享受到更低费用的服务。

L2TPv3原理介绍

如下图所示，企业分支局域网之间想通过IP网络进行二层数据通信，在企业出口网关处配置了L2TPv3功能。

相关概念

• LCCE

  控制连接终点LCCE（L2TP Control Connection Endpoint）：L2TP控制连接隧道任意一端的L2TP节点。它既可以是LAC，也可以是LNS。取决于在数据链路层还是在网络层处理隧道帧。若在数据链路层处理隧道帧，则LCCE是LAC；若在网络层处理隧道帧，则LCCE是LNS。

• PW

  伪线PW（Pseudowire）：一条从本地AC接口到对端AC接口之间的虚拟的、直接相连的数据通道，能够完成用户的二层数据透明传输。每个L2TPv3会话对应一条PW。

• AC接口

  AC接口：连接用户侧设备的接口，用于接收和发送用户侧流量。在本手册内，只支持接入VLANIF接口、三层WAN物理接口和子接口（不支持灵活QinQ模式）。

• PW接口

  PW接口：连接对端LCCE的接口，用于LCCE接收和发送L2TPv3协议报文和网络侧数据报文。

• 静态隧道：

  静态隧道是指直接通过命令行配置指定本端和对端的参数，不需要经过报文协商过程就直接进行数据转发。

  一个接口下只有一个隧道，一个隧道只支持一个会话。不同的接口下可以配置多个隧道。

工作过程

如下图所示，将企业分支A网关设备部署为LCCE1，企业分支B网关设备部署为LCCE2，LCCE1和LCCE2之间建立L2TPv3隧道。

1. 企业分支机构在LCCE设备上全局使能L2TPv3功能。
2. 在LCCE设备上创建Tunnel接口。配置隧道封装协议为L2TPv3、隧道工作模式为静态，设置隧道源地址和目的地址以及Session ID等其他参数。
3. 在LCCE设备上将AC接口和Tunnel接口绑定。
4. 流量经过AC接口，通过Tunnel转发到对端设备。

L2TPv3报文格式

企业分支发送的报文经L2TPv3封装后的报文格式，如下图所示。

如图2-3所示，企业分支A发送报文到企业分支B，有以下过程：

1. 分支A向分支B发送数据报文。
2. LCCE1收到报文之后根据AC口VLAN封装规则对报文进行处理。然后根据AC口查隧道封装表，在报文二层头上直接封装L2TPv3头，查路由表后从隧道接口发送出去。
3. LCCE2接收到报文后查路由表并判断是否是L2TPv3报文。若是L2TPv3报文则查隧道解封装表，校验对端LCCE1配置与本端LCCE2配置是否一致，合法的话剥掉L2TPv3头。剥掉L2TPv3头的报文从AC口，根据VLAN封装规则处理后发送给分支B；若不是L2TPv3报文或者配置不一致则丢弃报文。

业务接入方式

两分支机构处于不同的VLAN需要互通，可以采用以下几种接入L2TPv3的方式：

• 整端口接入L2TPv3隧道：当AC口为WAN口时，即在AC口配置Link-bridge命令将AC口和Tunnel绑定。L2TPv3隧道可以透传不带Tag，带一层Tag或者带两层Tag的二层报文。
• 终结一层Tag接入L2TPv3隧道：对AC接口下的子接口接收到的带有一层或两层Tag的报文，子接口剥除报文的最外层Tag，报文封装L2TPv3报文头后进入L2TPv3隧道；对从AC接口下的子接口发出的报文，子接口添加一层Tag再发送出去。
  • 当接受到的报文带有一层Tag，剥掉报文Tag就是C-Tag终结方式。
  • 当接受到的报文带有两层Tag，剥掉报文最外层Tag就是S-Tag终结方式。
• 终结两层Tag接入L2TPv3隧道：对AC接口下的子接口接收到的带有两层Tag的报文，子接口剥掉两层Tag（S-Tag和C-Tag），报文封装L2TPv3报文头后进入L2TPv3隧道；对从AC接口下的子接口发出的报文，子接口添加两层Tag（S-Tag和C-Tag）再发送出去。

5、L2TP LNS 和 LAC 搭建

LNS 搭建

Linux 下通过配置xl2tpd 软件的配置文件进行搭建， 一般配置文件位置：/etc/xl2tpd/xl2tpd.conf

LNS 的一个参考配置

[global]
ipsec saref = no
debug tunnel = no
debug avp = no
debug network = no
debug state = no
access control = no
rand source = dev
port = 1701
auth file = /etc/ppp/pap-secrets
 
[lns default]
ip range = 192.168.18.20 - 192.168.18.254
local ip = 192.168.18.1
name = l2tp
pass peer = yes
require pap = yes
require chap = yes
require authentication = yes
ppp debug = no
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

然后配置 xl2tpd.conf 配置文件中指定的 ppp 链路选项配置(pppoptfile)：/etc/ppp/options.xl2tpd

require-mschap-v2
refuse-mschap
ms-dns 127.0.0.53
asyncmap 0
auth
crtscts
idle 1800
mtu 1410
mru 1410
hide-password
local
modem
lock
connect-delay 5000
lcp-echo-interval 30
lcp-echo-failure 4
name "xl2tpd"
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

然后配置 xl2tpd.conf 配置文件中指定的 ppp认证文件配置

之后重启 xl2tpd， 不同 linux 环境下重启方式可能不同，ubuntu 下：service xl2tpd restart

LAC 搭建

Linux 下通过配置xl2tpd 软件的配置文件进行搭建或者使用 win10 的 VPN 连接

设置 -> VPN -> 添加 VPN 连接

上述VPN 连接没有配置 ipsec, 如果是 l2tp over ipsec 配置， VPN 类型可以根据 lns ipsec 的配置进行选择，lns ipsec 可以选择使用证书认证和预共享密钥认证的方式。

Linux 下通过配置xl2tpd 软件配置 LAC, 首先配置 /etc/xl2tpd/xl2tpd.conf 文件

[lac myvpn]
lns = 192.168.4.213
ppp debug = yes
pppoptfile = /etc/ppp/options.l2tpd.client
length bit = yes
require chap = yes
refuse pap = yes
require authentication = yes
1
2
3
4
5
6
7
8

然后配置 xl2tpd.conf 配置文件中指定的 ppp 链路选项配置(pppoptfile)：/etc/ppp/options.l2tpd.client

ipcp-accept-local
ipcp-accept-remote
refuse-eap
refuse-mschap-v2
require-chap
refuse-pap
noccp
noauth
mtu 1280
mru 1280
noipdefault
defaultroute
usepeerdns
connect-delay 5000
name "l2tp"
password "l2tp123"
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

终端输入 echo "c myvpn" > /run/xl2tpd/l2tp-control , 建立 L2TP 连接, myvpn 名称为 xl2tpd.conf 中定义；如果关闭或断开 L2TP 连接，使用 echo "d myvpn" > /run/xl2tpd/l2tp-control 。

PPP认证方式的选择

PPP认证 有三种方式： PAP、CHAP 和 MSCHAPV2, PAP 模式是明文传输用户名和密码；CHAP 模式在传输过程中加密用户名和密码；MSCHAPV2 是 CHAP 模式的双向认证，暂时不清楚怎么配置。

WIN10 中配置选择 PAP 认证方式（一般默认使用 CHAP 认证方式）

Linux LAC 选择 PAP 认证方式

/etc/xl2tpd/xl2tpd.conf 文件中 拒绝 chap , 请求 pap

...
refuse chap = yes
require pap = yes
...
1
2
3
4

/etc/ppp/options.l2tpd.client 文件中也 拒绝 chap , 请求 pap

...
refuse-chap
require-pap
...
1
2
3
4

6、L2TP LNS 和 LAC 报文交互

L2TP隧道建立过程

L2TP隧道建立过程中涉及的消息包括：

• SCCRQ（Start-Control-Connection-Request）：用来向对端请求建立控制连接。
• SCCRP（Start-Control-Connection-Reply）：用来告诉对端，本端收到了对端的SCCRQ消息，允许建立控制连接。
• StopCCN（Stop-Control-Connection-Notification）：用来通知对端拆除控制连接。
• SCCCN（Start-Control-Connection-Connected）：用来告诉对端，本端收到了对端的SCCRP消息，本端已完成隧道的建立。
• Hello：用来检测隧道的连通性。
• ZLB（Zero-Length Body）：如果本端的队列没有要发送的消息时，发送ZLB给对端。在控制连接的拆除过程中，发送方需要发送STOPCCN，接收方发送ZLB。ZLB只有L2TP头，没有负载部分，因此而得名。

控制连接的建立

控制连接的建立先于会话连接。只有控制连接建立起来了，会话连接才可能建立起来。L2TP的控制连接建立过程如下

• LAC和LNS之间路由相互可达后，LAC端设置相应AVP，向LNS端发出SCCRQ报文，请求建立控制连接。
• LNS收到来自LAC的SCCRQ。根据其中的AVP，如果同意建立隧道，便发送SCCRP报文给LAC。
• LAC对接收到的SCCRP报文进行检查，从中取出隧道信息，并向LNS发送SCCCN报文，表示控制连接建立成功。
• 当消息队列中没有消息时，LNS发送ZLB给对端。

隧道验证过程

隧道验证是和建立隧道同时进行的，不是单独进行的。(隧道验证自己未实践验证)

隧道验证过程如下：

1. 首先LAC向LNS发SCCRQ请求消息时，产生一个随机的字符串作为本端的CHAP Challenge（SCCRQ携带的字段）发给LNS。
2. LNS收到SCCRQ后，利用LAC侧发送的CHAP Challenge和本端配置的密码产生一个16个字节的Response；同时也产生一个随机的字符串（LNS CHAP Challenge），将随机生成的这个字符串和Response放在SCCRP中一起发给LAC。
3. LAC端收到SCCRP后，对LNS进行验证。
   • LAC端利用自己的CHAP Challenge和本端配置的密码，产生一个新的16字节的字符串；
   • LAC端将新产生的字符串与LNS端发来的SCCRP中带的LNS CHAP Response做比较，如果相同，则隧道验证通过，否则隧道验证不通过，断掉隧道连接。
4. 如果验证通过，LAC将自己的CHAP Response放在SCCCN消息中发给LNS。
5. LNS收到SCCCN消息后，也进行验证：
   • LNS端利用本端的CHAP Challenge、本端配置的密码，产生一个16字节的字符串；
   • LNS端与SCCCN消息中得到的LAC CHAP Response做比较。如果相同，则验证通过，否则拆除隧道。

控制连接的维持

L2TP使用Hello报文检测隧道的连通性。LAC和LNS定时向对端发送Hello报文，若在一段时间内未收到Hello报文的应答，则重复发送Hello报文。如果重复发送报文的次数超过5次，则认为L2TP隧道已经断开，该PPP会话将被清除。此时需要重新建立隧道。

设备中Hello报文发送的时间间隔可以手工设置。缺省情况下，Hello报文每隔60秒发送一次。LNS和LAC侧可以设置不同的Hello报文时间间隔。

控制连接的拆除

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

L2TP会话建立过程

L2TP会话建立过程中涉及的消息包括：

• ICRQ（Incoming-Call-Request）：只有LAC才会发送；每当检测到用户的呼叫请求，LAC就发送ICRQ消息给LNS，请求建立会话连接。ICRQ中携带会话参数。
• ICRP（Incoming-Call-Reply）：只有LNS才会发送；收到LAC的ICRQ，LNS就使用ICRP回复，表示允许建立会话连接。
• ICCN（Incoming-Call-Connected）：只有LAC才会发送；LAC收到LNS的ICRP，就使用ICCN回复，表示LAC已回复用户的呼叫，通知LNS建立会话连接。
• CDN（Call-Disconnect-Notify）：用来通知对端拆除会话连接，并告知对端拆除的原因。
• ZLB（Zero-Length Body）：如果本端的队列没有要发送的消息时，发送ZLB给对端。在会话连接的拆除过程中，发送ZLB还表示收到CDN。ZLB只有L2TP头，没有负载部分，因此而得名。

会话连接的建立

控制连接成功建立之后，一旦检测到用户呼叫，就请求建立会话连接。与控制连接不同的是，会话连接的建立具有方向性。会话连接建立过程如下。

L2TP的会话建立由PPP触发。

会话连接拆除

会话连接拆除的发起端可以是LAC或LNS。发起端通过发送CDN消息报文到对端来通知对端拆除会话连接。对端收到后发送ZLB ACK消息作为回应。

7、L2TP PPP 相关知识点

PPP概述

PPP（point-to-point协议），即点对点协议，是数据链路层封装协议的一种。

PPP协议工作在串行接口和串行链路上，一般来说，PPP协议所构成的网络只允许双方之间通信，不允许像以太网一样接入交换机后接入其他的主机或设备。

PPP协议的一个重要功能便是提供了身份验证功能。但是PPP协议虽然提供了通信双方身份验证的功能，其协议中没有提供地址信息，而以太网是一个广播类型的多路访问网络，因而PPP协议是无法直接应用在以太网链路上的。

PPP协议在数据链路层封装的是PPP帧，PPP帧格式如下：

• FLAG

  在PPP协议中，头部和尾部都有一个Flag字段，Flag字段标识着一个PPP帧的开始和结束。FLAG字段长度8bit，固定为0x7e，因为PPP协议将FLAG设置为PPP帧的开始和结束，因此在一个PPP帧中不允许出现0x7e字段的数据，如果出现这样的数据，则需要进行特殊形式的转义。

• Address

  在PPP协议中，因为进行通信的只有两方，因此一方发送的数据总是另一方，这一点PPP协议不像以太网协议一样，必须使用MAC地址来表明数据帧的发送者和接收者。PPP协议中的Address字段取值固定为0xff。

• Control

  长度8bit，取值固定0x03，无特殊作用。

• Protocol

  长度16bit，其取值类似于以太网帧的类型，表明了上层数据的类型。

• FCS

  长度16bit，用于帧校验。一个设备在收到PPP帧后会进行PPP帧校验，如果发现PPP在传输过程中出错，该帧会被立即丢弃。PPP协议没有纠错和重传机制。

L2TP PPP 报文

L2TP 报文中 PPP 字段 与原始 PPP 帧去除了 FLAG 和 FCS 字段。

PPP主要由三类协议族组成：

• 链路控制协议族（Link Control Protocol），主要用来建立、拆除和监控PPP数据链路。
• 网络层控制协议族（Network Control Protocol），主要用来协商在该数据链路上所传输的数据包的格式与类型。
• 扩展协议族CHAP（Challenge-Handshake Authentication Protocol）和PAP（Password Authentication Protocol），主要用于网络安全方面的验证。

链路配置报文主要用来建立和配置一条链路，包括：Config-Request、Config-Ack、Config-Nak和Config-Reject四种报文。

• 当接收Config-Request报文的一端能识别发送过来的所有配置参数选项且认可所有配置参数选项数据域的内容时，接收端将会给对端回一个Config-Ack报文，并将配置请求报文中的配置参数选项原封不动的放置在Config-Ack报文的数据域内。当配置请求报文的发送端收到Config-Ack报后，则会从当前阶段进入到下一个阶段。
• 当接收Config-Request报文的一端B能识别发送端A所发送过来的所有配置参数选项，但对部分配置参数选项数据域中的内容不认可时，接收端B将会给对端A回应一个Config-Nak报文。该报文中只携带不认可的配置参数选项，而这些配置参数选项的数据内容为本端希望的值。
• 当A收到Config-Nak报文后，会重新发送Config-Request报文，而这个Config-Request报文与上一次所发送的Config-Request报文区别在于：那些被对端B不认可的配置参数选项的内容被填写到刚刚协商完后再次发送的Config-Request报文中。
• 当接收Config-Request报文的一端B不能识别所有的发送端A发送过来的配置参数选项时，此时接收端B将会向对端A回一个Config-Reject报文，该报文中的数据域只携带那些不能识别的配置参数选项。当对端A接收到Config-Reject报文后，同样会再次发送一个Config-Request报文，这个配置请求报文与上一次发送的区别在于将不可识别的那些配置参数选项给删除了。

链路终止报文主要用来终止一条链路，分为Terminate-Request和Terminate-Reply两种报文。LCP报文中提供了一种机制来关闭一个点对点的连接，想要关断链路的一端A会持续发送Terminate-Request报文，直到收到一个Terminate-Reply为止。

除上述两种报文类型以外，剩余的所有报文类型均归属链路维护报文。

• 当接收端发现LCP报文的代码域code是一个不合法的值时，将会向发送端回应一个Code-Reject报文，在回应报文中会将所拒绝报文的全部内容附加上(注：code只有在LCP协议头中才存在)。
• 当接收端发现所接收到的PPP数据帧的协议域Protocol是一个不合法的值时，将会向发送端回应一个Protocol-Reject报文，发送端收到该拒绝报文后将停止发送该种协议类型的数据报文了（注：Protocol只有在PPP协议头中才存在）。
  Protocol-Reject报文只能在LCP的状态机处于Opened状态时才可被处理，而在其它状态接收到该报文将被丢弃。在Protocol-Reject报文的数据域内将携带所拒绝报文的协议类型和报文内容。
• Echo-Request报文和Echo-Reply报文主要用来检测双向链路上自环的问题，除此之外还可附带做一些链路质量的测试和其它功能。当LCP状态机处于Opened状态时，如果接收到了Echo-Request，就需向对端回送一个Echo-Reply报文。否则在其它LCP状态下，该类型的报文会被丢弃。

PPP的六个阶段

1. 链路不可用阶段：初始阶段
2. 链路建立阶段：LCP协商（协商认证方式等）
3. 验证阶段：PAP/CHAP验证\
4. 网络层协商阶段：NCP协商
5. PPP会话维持阶段：维持PPP会话，定时发送Echo Request报文，并等待Echo Reply报文
6. 网络终止阶段：终止PPP会话，回到链路不可用阶段。

详细内容见此文章： PPP拨号

8、使用 IP 工具配置 L2TPv3

格式或概要

# ip l2tp help
Usage: ip l2tp add tunnel
          remote ADDR local ADDR
          tunnel_id ID peer_tunnel_id ID
          [ encap { ip | udp } ]
          [ udp_sport PORT ] [ udp_dport PORT ]
          [ udp_csum { on | off } ]
          [ udp6_csum_tx { on | off } ]
          [ udp6_csum_rx { on | off } ]
Usage: ip l2tp add session [ name NAME ]
          tunnel_id ID
          session_id ID peer_session_id ID
          [ cookie HEXSTR ] [ peer_cookie HEXSTR ]
          [ seq { none | send | recv | both } ]
          [ l2spec_type L2SPEC ]
       ip l2tp del tunnel tunnel_id ID
       ip l2tp del session tunnel_id ID session_id ID
       ip l2tp show tunnel [ tunnel_id ID ]
       ip l2tp show session [ tunnel_id ID ] [ session_id ID ]

Where: NAME   := STRING
       ADDR   := { IP_ADDRESS | any }
       PORT   := { 0..65535 }
       ID     := { 1..4294967295 }
       HEXSTR := { 8 or 16 hex digits (4 / 8 bytes) }
       L2SPEC := { none | default }

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

描述

ip l2tp命令用于建立静态(即所谓的非托管)的l2tp以太网隧道。对于非托管隧道，不存在L2TP控制协议，因此不需要用户空间守护进程——隧道是通过在本地系统和远程对等端发出命令手动创建的。

L2TPv3适用于二层隧道。静态隧道用于在固定隧道的情况下建立跨IP网络的网络连接。L2TPv3隧道可以承载多个会话的数据。每个会话由session_id及其父隧道的tunnel_id标识。在隧道中创建会话之前，必须先创建隧道。

在创建L2TP隧道时，指定对端IP地址，可以是IPv4地址，也可以是IPv6地址。还必须指定到达对等体的本地IP地址。这个地址是本地系统侦听和接受从对等端接收到的L2TP数据包的地址。

L2TPv3定义了两种报文封装格式:UDP或IP。UDP封装是最常见的。IP封装使用专用的IP协议值承载L2TP数据，没有UDP的开销。只有当网络路径中没有NAT设备或防火墙时，才需要使用IP封装。

当创建L2TPv3以太网会话时，为该会话创建一个虚拟网络接口，然后必须像任何其他网络接口一样配置和启动该虚拟网络接口。当数据通过该接口时，将通过L2TP隧道传送到对端。通过配置系统路由表或将接口加入网桥，L2TP接口就像一条虚拟线(伪线 pseudowire)一样连接到对端。

建立非托管的L2TPv3以太网伪线需要在本地系统和对端手工创建L2TP上下文。每个站点使用的参数必须对应，否则不会传递任何数据。由于没有用于建立非托管L2TP隧道的控制协议，因此不可能进行一致性检查。一旦配置并启用了给定L2TP会话的虚拟网络接口，即使对等端尚未配置，也可以传输数据。如果没有配置对等体，L2TP数据报文将被对等体丢弃。

使用本文档中的L2TP add tunnel和L2TP add session命令建立非托管L2TP隧道。然后根据实际情况配置并使能隧道的虚拟网络接口。

注意，非托管隧道只携带以太网帧。如果您需要承载PPP流量(L2TPv2)，或者您的对等体不支持非托管的L2TPv3隧道，则需要一个实现L2TP控制协议的L2TP服务器。L2TP控制协议允许动态建立L2TP隧道和会话，并提供对网络故障的检测和处理。

增加一个新的隧道

ip l2tp add tunnel

name NAME
设置会话网络接口名称。缺省值是l2tpethN。

tunnel_id ID
配置隧道id, 32位整数形式。唯一标识隧道。该值必须与对等端使用的peer_tunnel_id值匹配。

peer_tunnel_id ID
配置对端隧道id，是对端分配给隧道的32位整型值。使用的值必须与对端使用的tunnel_id值匹配。

remote ADDR
配置远端对等体的IP地址。可以指定为IPv4地址或IPv6地址。

local ADDR
配置tunnel使用的本端接口IP地址。该地址必须是本地接口的地址。可以指定为IPv4地址或IPv6地址。

encap ENCAP
设置隧道的封装类型。有效的封装值为:udp、ip。

udp_sport PORT
配置隧道使用的UDP源端口。选择udp封装时必须存在。选择ip封装时忽略。

udp_dport PORT
设置隧道使用的UDP目的端口。选择udp封装时必须存在。选择ip封装时忽略。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

删除一个隧道

ip l2tp del tunnel

tunnel_id ID
设置待删除隧道的tunnel id。必须先删除隧道内的所有会话。
1
2
3
4

显示关于隧道的信息

ip l2tp show tunnel

tunnel_id ID
设置要显示的隧道id。如果不指定，则打印所有隧道的信息。
1
2
3
4

在隧道中增加一个会话

ip l2tp add session

name NAME
设置会话网络接口名称。缺省值是l2tpethN。

tunnel_id ID
配置隧道id, 32位整数形式。唯一标识要建立会话的隧道。该隧道必须已经存在。

session_id ID
配置会话id, 32位整数形式。唯一标识正在创建的会话。该值必须与对等端使用的peer_session_id值匹配。

peer_session_id ID
配置对等体会话id，会话id为32位整数形式，由对等体分配给会话。该值必须与对等体使用的session_id值匹配。

cookie HEXSTR
设置分配给会话的可选cookie值。这是一个4或8字节的值，指定为8或16个十六进制数字，例如014d3636deadbeef。该值必须与对等体设置的peer_cookie值匹配。cookie值在L2TP数据包中携带，在对端检查是否为期望值。默认是不使用cookie。

peer_cookie HEXSTR
设置分配给会话的可选对等体cookie值。这是一个4或8字节的值，指定为8或16个十六进制数字，例如014d3636deadbeef。该值必须与对等体设置的cookie值匹配。它告诉本地系统期望在接收到的L2TP数据包中找到什么cookie值。默认是不使用cookie。

l2spec_type L2SPECTYPE
配置会话的layer2特定的报头类型。取值为:none、udp。

offset OFFSET
在传输的L2TP数据包中，设置用户数据从L2TP头开始的字节偏移量。这几乎从未被使用过。如果设置了该值，则必须匹配对等体使用的peer_offset值。默认为0。

peer_offset OFFSET
设置从接收到的L2TP数据包中用户数据开始的L2TP头的字节偏移量。这几乎从未被使用过。如果设置了该值，则必须匹配对等体使用的偏移量值。默认为0。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

删除一个会话

ip l2tp del session

tunnel_id ID
配置待删除会话所在的隧道id。

session_id ID
配置要删除会话的会话id。
1
2
3
4
5
6
7

显示会话相关的信息

ip l2tp show session

tunnel_id ID
设置要显示的会话的tunnel id。如果不指定，则打印所有隧道的会话信息。

session_id ID
设置要显示的会话的会话id。如果不指定，则打印所有会话的信息。
1
2
3
4
5
6
7

举例

设置 L2TP 隧道和会话

site-A:
# ip l2tp add tunnel tunnel_id 3000 peer_tunnel_id 4000 encap udp local 1.2.3.4 remote 5.6.7.8 \
                  udp_sport 5000 udp_dport 6000
# ip l2tp add session tunnel_id 3000 session_id 1000 peer_session_id 2000
# ip link set l2tpeth0 up mtu 1488

site-B:
# ip l2tp add tunnel tunnel_id 4000 peer_tunnel_id 3000 encap udp local 5.6.7.8 remote 1.2.3.4 \
                  udp_sport 6000 udp_dport 5000
# ip l2tp add session tunnel_id 4000 session_id 2000 peer_session_id 1000
# ip link set l2tpeth0 up mtu 1488
1
2
3
4
5
6
7
8
9
10
11

注意，IP地址、UDP端口和隧道/会话ID在每个站点都是匹配和反转的。

配置为IP接口

如果只携带IP数据，则可以使用IP地址配置这两个接口。这可能是最简单的配置。

site-A:
ip addr add 10.42.1.1 peer 10.42.1.2 dev l2tpeth0

site-B:
ip addr add 10.42.1.2 peer 10.42.1.1 dev l2tpeth0

site-A:
ping 10.42.1.2
1
2
3
4
5
6
7
8

现在链接应该可以使用了。根据需要添加静态路由，以便通过新链接发送数据。

配置为桥接接口

为了承载非IP数据，使用标准的Linux实用程序将L2TP网络接口添加到网桥中，而不是为其分配自己的IP地址。由于原始以太网帧随后在隧道内携带，因此L2TP接口的MTU必须设置为允许这些报头的空间。

site-A:  
# ip link set l2tpeth0 up mtu 1446
# ip link add br0 type bridge
# ip link set l2tpeth0 master br0
# ip link set eth0 master br0
# ip link set br0 up
1
2
3
4
5
6

如果你使用的是VLAN，请为每个VLAN设置桥接，并在单独的L2TP会话上桥接每个VLAN。例如，要在eth1上通过L2TP伪线桥接VLAN ID 5:

site-A:
# ip link set l2tpeth0 up mtu 1446
# ip link add brvlan5 type bridge
# ip link set l2tpeth0.5 master brvlan5
# ip link set eth1.5 master brvlan5
# ip link set brvlan5 up
1
2
3
4
5
6

将L2TP接口添加到网桥中，将使网桥通过L2TP伪线转发流量，就像通过其他接口转发流量一样。网桥学习连接到每个接口的主机的MAC地址，并智能地将帧从一个网桥端口转发到另一个端口。没有为l2tpethN接口分配IP地址。如果在L2TP伪线的两端正确配置网桥，应该可以到达对等端网桥网络中的主机。

当原始以太网帧在L2TP隧道中桥接时，根据隧道使用的物理接口的MTU，可能会将大帧分片并作为单独的IP分片转发给接收方。当以太网帧携带由接收方重新组装的协议(如IP)时，这不是问题。然而，这样的碎片可能会给PPPoE这样的协议带来问题，因为在PPPoE协议中，接收方希望接收到的以太网帧与传输的帧完全一致。在这种情况下，离开隧道的帧在继续转发之前重新组装回单个帧是很重要的。为此，在每个隧道端点启用netfilter连接跟踪(conntrack)或手动加载Linux netfilter degrag模块。

site-A:
# modprobe nf_degrag_ipv4

site-B:
# modprobe nf_degrag_ipv4
1
2
3
4
5

如果正在使用IPv6协议使用L2TP，请使用IPv6 degrg模块。

互通性

一些网络设备厂商(如Cisco)支持非托管(静态)的L2TPv3隧道。

在Linux操作系统下，非托管隧道中不支持L2TP Hello消息。L2TP客户端和服务器使用Hello消息来检测链路故障，以便自动拆除和重建动态隧道。如果非Linux对等体在非托管隧道中支持Hello消息，则必须关闭该对等体才能与Linux进行互操作。

Linux默认使用缺省Layer2SpecificHeader类型，该类型在L2TPv3协议规范RFC3931中定义。该配置必须与对端保持一致。一些厂商的实现(例如Cisco)默认使用的Layer2SpecificHeader类型为None。

9、xl2tpd.conf 配置文件解析

参考 ubuntu 下 xl2tpd 配置文件的解释，大抵都是一样的

xl2tpd.conf 包含了实现 l2tp 协议的 xl2tpd 的配置信息

配置文件由 section 和 parameter 组成， 每个 section 都有一个特定的名称，在使用配置 FIFO 时(正常是 /var/run/xl2tpd/l2tp-control) 将使用该名称， 详细可查看 xl2tpd.8

特定的给定名称 default 将指定参数应用于接下来的所有的 section。

GLOBAL SECTION

• auth file

  指定在哪里寻找用于验证 l2tp 隧道的验证文件，默认是 /etc/xl2tpd/l2tp-secrets

• ipsec saref

  使用 IPsec 安全关联(Security Association )追踪, 当这个选项使能时，xl2tpd 接收到的包应该有额外的字段(refme 和 refhim)，这允许使用相同的内部 NATed IP 地址跟踪他多个 client， 并且也允许跟踪同一 NET 路由器后面的多个 client， 这需要内核支持，目前，仅适用在 Openswan KLIPS 的 mast 模式

  可以被设置为 yes 和 no, 默认是 no

• saref refinfo

  使用IPsec安全关联跟踪时，将使用新的 setsockopt

  默认 30 , 对于老的 SAref 修补内核，使用22

• listen-addr

  daemon 监听接口的 IP 地址，默认它监听 INADDR_ANY (0.0.0.0)， 意味着它监听所有的接口

• port

  指定 xl2tpd 应当使用的 UDP 端口，默认是 1701

• access control

  如果设置为 yes, xl2tpd 进程将只接受以下 section 中指定的对端地址的连接，默认是 no

• debug avp

  将此项设置为 yes 以启用 L2TP AVP 调试信息的 syslog 输出

• debug network

  将此项设置为 yes 以启用 L2TP network调试信息的 syslog 输出

• debug packet

  将其设置为 yes 以启用 L2TP 数据包调试信息的打印。注意：输出将转到STDOUT，因此只能与 -D 命令行选项一起使用

• debug state

  将此项设置为 yes 以启用 FSM 调试信息的 syslog 输出

• debug tunnel

  将此项设置为 yes 以启用 tunnel 调试信息的 syslog 输出

• max retries

  指定 tunnel 关闭前的重试次数，如果没有了 tunnel , 则停止重传，默认是 5

LNS SECTION

• exclusive

  如果设置为 yes，则在 2 个对端设备之间只允许建立一个控制隧道。

• (no) ip range

  指定 LNS 将分配给连接的 LAC PPP 隧道的 IP 地址范围。 可以定义多个范围。 使用“no” 声明不允许使用该特定范围。 使用 IP - IP 格式定义范围（示例：1.1.1.1 - 1.1.1.10）。 请注意，要么必须至少提供一个 ip 范围选项，要么必须将 assign ip 设置为 no。

• assign ip

  如果 xl2tpd 不应从使用 ip range 选项定义的池中分配 IP 地址，则将其设置为 no。 如果您有一些其他方法来分配 IP 地址，这会很有用，例如支持 RADIUS AAA 的 pppd。

• (no) lac

  指定允许连接到 xl2tpd LNS 的 LAC 的 IP 地址。 格式与 ip range 选项相同。

• hidden bit

  如果设置为 yes，xl2tpd 将使用 L2TP 的 AVP 隐藏功能。 要获取有关隐藏 AVP 和一般 AVP 的更多信息，请参阅 rfc2661（添加 URL？）

• local ip

  使用下面的IP作为xl2tpd自己的ip地址。

• local ip range

  指定 LNS 将分配为连接 LAC PPP 隧道的本地地址的地址范围。 此选项与 local ip 选项互斥，在希望每个隧道具有唯一 IP 地址的情况下很有用。 指定与 ip range 选项完全相同的范围值。 请注意，分配 ip 选项对此选项没有影响（没太懂，可以看英语原文）

• length bit

  如果设置为 yes，将使用 l2tp 数据包有效载荷中存在的长度位。

• (refuse | require) chap

  将要求或拒绝远程对端设备通过 CHAP 进行身份验证以进行 ppp 身份验证。

• (refuse | require) pap

  将要求或拒绝远程对等点通过 PAP 进行身份验证以进行 ppp 身份验证。

• (refuse | require) authentication

  将要求或拒绝远程对端设备对自己进行身份验证。

• unix authentication

  如果设置为 yes, /etc/passwd 将会被用于对端设备的 ppp authentication

• host name

  将在协商中将其报告为 xl2tpd 主机名。

• ppp debug

  这将为 pppd 启用调试。

• pass peer

  将对端的 IP 地址作为 ipparam 传递给 pppd。 默认启用。

• pppoptfile

  指定包含要使用的 pppd 配置参数的文件的路径。

• call rws

  此选项已弃用，不再起作用。 它曾经用于定义单个 L2TP 调用或会话的流量控制窗口大小。 L2TP 标准 (RFC2661) 不再定义呼叫或会话的流量控制或窗口大小。

• tunnel rws

  这定义了控制通道的窗口大小。 窗口大小定义为未确认的数据包的数量，而不是字节数。

• flow bits

  如果设置为 yes，序列号将包含在通信中。 在会话中使用序列号的功能目前已损坏且无法运行。

• challenge

  如果设置为 yes, 使用 challenge authentication 来认证对端设备

• rx bps

  如果设置，接收的最大带宽将是这个设置的值

• tx bps

  如果设置，发送的最大带宽将是这个设置的值

LAC SECTION

以下是 LAC 特定的配置标识， LNS section 中大部分描述可以在 LAC 的上下文中使用，这在其中是常识(本质上是 l2tp 协议调整标志和身份验证/ppp 相关的)

• lns

  设定 要连接的 lns 的域名和 ip 地址

• autodial

  如果设置为 yes, xl2tpd 将在启动时自动拨号 LAC

• redial

  如果设置为 yes, 如果拨号断开，xl2tpd 将尝试重拨，要注意的是如果启用，xl2tpd 会将密码保存在内存中，这是一个潜在的安全风险

• redial timeout

  在重拨之前等待 X 秒，redial 选项必须为 yes 才可以使用这个选项，默认 30 秒

• max redials

  将在尝试 X 次后放弃

部分翻译出错，请看原英文解释： https://manpages.ubuntu.com/manpages/focal/en/man5/xl2tpd.conf.5.html

10、PPP 认证协议介绍（RFC1334）

PAP 协议

PAP全称为：Password Authentication Protocol（口令认证协议），是PPP中的基本认证协议。PAP就是普通的口令认证，要求将密钥信息在通信信道中明文传输，因此容易被sniffer监听而泄漏。

• Code：1字节，表示PAP包的类型
  • 1 --> Authenticate-Request
  • 2 --> Authenticate-Ack
  • 3 --> Authenticate-Nak
• Identifier：ID号，1字节，辅助匹配请求和回应
• Length：2字节，表示整个PAP数据的长度，包括Code, Identifier, Length和Data字段。
• Data：可能是0字节或多个字节，具体格式由Code字段决定，成功或失败类型包中长度可能为0。

Authenticate-Request

• Code（Code = 1）,Identifier和Length字段含义如前面所述，Identifier字段必须每次认证时改变。
• Peer-ID-Length：长度1个字节，表示Peer-ID域的长度
• Peer-ID：可为0到多个字节长，表示认证对方的名称。
• Passwd-Length：长度1个字节，表示Password域的长度
• Password：可为0到多个字节长，表示认证的口令，明文

Authenticate-Ack 和 Authenticate-Nak

• Code（Code = 2 或者 3）,Identifier和Length字段含义如前面所述，Identifier字段必须每次认证时改变。

• Msg-Length：长度1个字节，表示Message域的长度

• Message：可为0到多个字节长，具体内容由应用实际实现时确定，RFC中没有限制其内容，推荐使用可读的ASCII字符表示信息内容。

PAP二次握手

• 第一次握手：被认证方将配置的用户名和密码信息使用Authenticate-Request报文以明文方式发送给认证方。

• 第二次握手：认证方收到被认证方发送的用户名和密码信息之后，根据本地配置的用户名和密码数据库检查用户名和密码信息是否匹配；如果匹配，则返回Authenticate-Ack报文，表示认证成功。否则，返回Authenticate-Nak报文，表示认证失败。

CHAP 协议

CHAP全称为：Challenge Handshake Authentication Protocol(挑战握手认证协议)，主要就是针对PPP的，除了在拨号开始时使用外，还可以在连接建立后的任何时刻使用。

• Code：1字节，表示CHAP 包的类型

  • 1 --> Challenge
  • 2 --> Response
  • 3 --> Success
  • 4 --> Failure

• Identifier：ID号，1字节，辅助匹配挑战、响应和回答，每次使用CHAP时必须改变

• Length：2字节，表示整个CHAP数据的长度，包括Code, Identifier, Length和 Data字段。

• Data：可能是0字节或多个字节，具体格式由Code字段决定，成功或失败类型包中长度可能为0。

Challenge 和 Response

• Value-Size：此字段1字节表示Value的长度

• Value：至少是一个字节，可变长，按网络序传输，Challenge 信息必须是随机的，在每次认证时改变，由应用在实际实现中自己定义的，RFC中并没有规定挑战信息的具体格式

• Name：至少一个字节，用来标志所传的这个包，必须是以’/0’或“/r/n”结束。

Success 和 Failure

• Message：可以是0字节，也可以是多个字节，内容可以根据实际应用自己确定。

CHAP三次握手

• 第一次握手：认证方主动发起认证请求，认证方向被认证方发送Challenge报文，报文内包含随机数（Random）和ID。

• 第二次握手：被认证方收到此Challenge报文之后，进行一次加密运算，运算公式为MD5{ ID＋随机数＋密码}，意思是将Identifier、随机数和密码三部分连成一个字符串，然后对此字符串做MD5运算，得到一个16 Byte长的摘要信息，然后将此摘要信息和端口上配置的CHAP用户名一起封装在Response报文中发回认证方。

• 第三次握手：认证方接收到被认证方发送的Response报文之后，按照其中的用户名在本地查找相应的密码信息，得到密码信息之后，进行一次加密运算，运算方式和被认证方的加密运算方式相同；然后将加密运算得到的摘要信息和Response报文中封装的摘要信息做比较，相同则认证成功，不相同则认证失败。