网络协议 — IPSec 安全隧道协议族

小乔

目录

• IPSec 安全隧道协议族
• 封装协议
  
  • Authentication Header 协议
  • Encapsulating Security Payload 协议
    
• 封装模式
• Transport（传输模式）
  
  • Tunnel（隧道模式）
    
• 安全偶联协商
  
  • Security Association 协议
  • Internet Key Exchange 协议
  • IKE 的对称密钥交换过程
    
• IPSec NAT-Tranversal
  
  • NAT-T 的封装模式
  • NAT-T 的协商过程
    
• IPSec 的 MTU 分片和加密问题
• IPSec Virtual Private Network
  
  • IPSec Virtual Tunnel Interface
  • GRE over IPSec VPN
  • L2TP over IPSec VPN
    
• Strongswan 的应用实践
  
  • net2net-psk 网络拓扑
  • base configuration
  • moon Site
  • sun Site
  • 测试
  • 运维
    

IPSec 安全隧道协议族

IPSec（Internet Protocol Security，互联网协议安全）是一个基于 IP 网络的安全隧道协议族，包含了一系列认证、加密、隧道封装协议。包括：

• 安全认证协议（Authentication Header，AH）
• 安全封装协议（Encapsulating Security Payload，ESP）
• 安全偶联协议（Security Association，SA）
• 安全密钥交换协议（Internet Key Exchange，IKE）
  

                               
登录/注册后可看大图

这些协议共同构建了 IPSec 的安全框架：

• 加密算法：用于加密数据，有：
  

• 对称加密算法：AES、DES、3DES 等。
• 非对称加密算法：RSA、DH（Diffie-Hellman）等。
  

验证算法：用于校验数据完整性，有 MD5、SHA-1、SHA-2 等。封装协议：IPSec 具有 AH 和 ESP 这 2 种封装协议，它们具有不同的安全特性，如下图所示。

                               
登录/注册后可看大图

• 封装模式：IPSec 还支持 Transport（传输模式）和 Tunnel（隧道模式）这 2 种不同的封装模式。不同的封装模式和封装格式可以组合出多种安全特性，在实际应用中需要根据不同的应用场景进行选择，如下图所示。
  

                               
登录/注册后可看大图

封装协议

在实际应用中，AH 和 ESP 封装协议可以单独使用，也可以组合使用。

• AH 协议可以确保数据的完整性和数据源身份认证；
• ESP 协议可以提供更高级别的数据加密特性；
• AH-ESP 协议组合可以提供最完备的安全保障，但协议开销也最高。
  

具体选择使用哪种协议，以及如何配置和组合它们，取决于特定的安全需求和网络环境。

Authentication Header 协议

AH（Authentication Header，安全认证协议）通常与 Transport 模式一起使用，用于 E2E 的身份认证安全通信，但不能加密数据的内容，具有以下安全特性：

• 数据认证范围：AH 对几乎整个 Original IP Packet 进行身份认证，包括 Header 和 Payload（Header 中的可变域除外）。
• 数据加密范围：AH 不对数据进行加密。
• 数据完整性校验：AH 使用 HASH 算法（e.g. MD5、SHA）生成 MAC（消息认证码）的方式来校验数据的完整性。
  

AH 的封装格式如下图所示：

• Next Header（下一个头）：标识被封装数据的协议类型。
• Payload Length（载荷长度）：标识 Original IP Payload 的长度。
• Reserved（保留位）：置 0。
• Security Parameter Index（SPI，安全参数索引）：标识安全参数。
• Sequence Number（序列号）：32bits 长度的单调递增的数值，此数值溢出后，需要重新建立 SA，并使用 DH 加密算法交换密钥，以此来防止重放攻击。
• Authentication Data（身份认证数据）：包含了对当前 IP Packet 进行身份认证所必须的数据。
  

                               
登录/注册后可看大图

Encapsulating Security Payload 协议

ESP（Encapsulating Security Payload，安全封装协议）可以在 Transport 模式和 Tunnel 模式下使用，可以提供 E2E 或网络之间的身份认证和加密安全通信。

安全特性：

• 数据认证范围：ESP 只会对除了 Original IP Payload 进行身份认证，并没有专门对 Original IP Header 的内容进行任何保护。
• 数据加密范围：ESP 使用加密算法（e.g. DES、3DES、AES等）对 IP Payload 进行加密。
• 数据完整性校验：ESP 使用 HASH 算法（e.g. MD5、SHA）生成 MAC（消息认证码）的方式来校验数据的完整性。
  

ESP 的封装格式如下图所示：出了会添加 ESP Header 之外还会在 IP Packet 尾部添加一个 ESP Tail 和 ESP Auth data。

• Security Parameter Index（SPI，安全参数索引）：标识安全参数。
• Sequence Number（序列号）：32bits 长度的单调递增的数值，此数值溢出后，需要重新建立 SA，并使用 DH 加密算法交换密钥，以此来防止重放攻击。
• Payload Data（载荷数据）：Original IP Payload。
• Padding（填充位）：某些块加密算法需要填充至特定的长度。
• Pad Length（填充长度）：标识具体的填充长度。
• Authentication Data（身份认证数据）：包含了对当前 IP Packet 进行身份认证所必须的数据。
  

                               
登录/注册后可看大图

封装模式

无论是 Tunnel 模式还是 Transport 模式，添加的除了 Original IP Packet 之外的封装头部和尾部的总长度不能超过 58Bytes，具体长度视乎于具体的封装模型而定。

Transport（传输模式）

Transport（传输模式）具有以下特性：

• Transport 模式提供主机级别的安全性，因为只有 IP Payload 被加密了，而 IP Header 在网络中是可见的。所以通常用于端到端通信场景，例如：两个主机之间的通信。
• 在 Transport 模式中，Original IP Packet 的 srcIP 和 dstIP 不会更改。
  

                               
登录/注册后可看大图

Tunnel（隧道模式）

Tunnel（隧道模式）具有以下特性：

• 在 Tunnel 模式下，IPSec 会创建一个 New IP Packet，并将 Original IP Packet 作为 New IP Packet 的 Payload 进行封装。
• Tunnel 模式提供了网络级别的安全性，因为整个 Original IP Packet 都被加密和认证。所以可以用于网络之间的通信，例如：在两个远程网络之间建立安全通信。
  

                               
登录/注册后可看大图

安全偶联协商Security Association 协议

一个 IPSec 通信连接需要首先在两端建立 Security Association（安全偶联），通过 SA 协议的交互流程来协商 AH 或 ESP 封装协议所需要使用到的加密协议、对称秘钥、对端 IP 地址等信息。其中，关键的对称秘钥还需要额外的通过 IKE 协议来进行互换。

一个 IPSec 连接对应一个 SA，由 3-tuple 来唯一标识，包括：

• SPI（Security Parameter Index，安全参数索引）
• 目的 IP 地址
• 安全协议号（AH 或 ESP）
  

其中，SPI（32bits）用于唯一标识一个 SA，它会被添加到 AH 或 ESP Header 中。

                               
登录/注册后可看大图

Internet Key Exchange 协议

IKE（Internet Key Exchange，安全密钥交换协议）是建立在 ISAKMP（Internet Security Association and Key Management Protocol，互联网安全联盟和密钥管理协议）之上的、专用于保证对称密钥安全交换的自动协商协议，并提供了 SA 自动建立、CA 身份认证等功能。

使用 IKE 来建立和维护 SA，可以有效简化了 IPSec 的使用和管理，并提供更好的安全性。包括：

• 使用 IKE 自动随机生成 SPI 的取值，代替手工生成。
• 使用 IKE 自动生成对称密钥，代替手工生成。
• 大规模的 IPSec VPN 端到网关场景中，往往需要使用 CA 认证机制，使用 IKE 的 CA 身份认证代替手动生成。
• 使用 IKE 提供周期性的动态建立 SA，并且每次重建 SA 都会使用 DH（Diffie-Hellman）加密算法，使得每个 SA 所使用的 Pre-Master Secret 对称密钥都是不相同的，支持向前保密（Forward Secret）特性。
• AH 和 ESP Header 中基于 Sequence Number 字段的防重放保护同样需要 IKE 动态建立 SA 的机制。
  

IKE 支持的 SA 生命周期具有 2 种定义方式：

• 基于时间：定义一个 SA 从建立到失效的时间；
• 基于流量：定义一个 SA 允许处理的最大流量。
  

在 SA 终结条件到达后、SA 失效前，IKE 会自动协商建立新的 SA：

• 在新的 SA 开始协商而没有协商好之前，继续使用旧的 SA 保护通信；
• 在新的 SA 协商好之后，则立即采用新的 SA 保护通信。
  

IKE 的对称密钥交换过程

值得注意的是，IKE 不是简单的在网络上传输对称密钥（会遭受中间人攻击），而是通过一系列数据的交换，最终计算出双方共享的对称密钥，类似 TLS 协议。

IKE 使用了 2 个阶段为 IPSec 通信连接进行密钥协商并建立 SA：

• 第一阶段：通信各方彼此间建立了一个已通过身份认证和安全保护的通道，即：建立一个 ISAKMP SA。
• 第二阶段：用在第一阶段建立的 ISAKMP SA 安全隧道为 IPSec 协商安全服务，即：为 IPSec 协商和建立一个用于安全传输 IP Packets 的 IPSec SA。
  

其中，第一阶段具有主模式（Main Mode）和野蛮模式（Aggressive Mode）这 2 种 IKE 交换方法。

• 主模式的 IKE 协商过程中包含了 3 对消息：
  
  • 第一对叫 SA 交换，是协商确认有关安全策略的过程；
  • 第二对消息叫密钥交换，交换 Diffie-Hellman 公共值和辅助数据（如：随机数），密钥材料在这个阶段产生；
  • 最后一对消息是 ID 信息和认证数据交换，进行身份认证和对整个第一阶段交换内容的认证。
    
• 野蛮模式交换的主要区别在于：野蛮模式不提供身份保护，只交换 3 条消息。
  

所以，在对身份保护要求不高的场合，使用交换报文较少的野蛮模式可以提高协商的速度。而在对身份保护要求较高的场合，则应该使用主模式。

                               
登录/注册后可看大图

IPSec NAT-Tranversal

由于 IPSec 的安全加密特性，所以从技术实现上会与 NAT 存在冲突。如下图所示总结了这种冲突的情况：

• Transport-AH、Tunnel-AH 和 Transport-ESP 都不支持 NAPT。
• Tunnel-ESP 只支持一对一的 NAT，但不支持 PAT。
  

                               
登录/注册后可看大图

具体而言，Transport 模式的冲突原因如下：

• Transport-AH 的 Authenticate（数据身份认证）范围为整个 IP Packet，而 NAT 会修改 IP Header 的 Address，所以就会导致接收方 Authenticate 失败。同样，PAT 会修改 TCP Header 的 Port，也会导致 Authenticate 失败。
• Transport-ESP 的 Authenticate 范围为 ESP Header 和 ESP Tail 之间。因为 ESP 不校验 IP Header 所以 NAT 行为并不会导致接收方的 Authenticate 失败，但由于 NAT 修改了 IP Header 中的 Address，理论上后面的 TCP checksum 也会随之修改，而 TCP checksum 已经属于 ESP 校验范围之内了，NAT 设备无法进行修改，所以接收端在 TCP 层接收时会导致 checksum 校验失败。
  

                               
登录/注册后可看大图

Tunnel 模式的冲突原因如下：

• Tunnel-AH 的 Authenticate 范围会包含外层的 New IP Header，因此 NAT 同样会造成接收方 Authenticate 失败。
• Tunnel-ESP 经过 NAT 后，内层的 Original IP Header 并不会被改变，所以 TCP checksum 也不会改变，接收方也就不会再出现 checksum 失败了。但也存在着缺点：它只能支持一对一的 NAT，即：NAT 后面只有一台内网主机。如果考虑 PAT 来补充的话，又回因为 TCP Header 已经被加密而无法实现。
  

                               
登录/注册后可看大图

NAT-T 的封装模式

IPSec NAT-Tranversal 用于解决上述提到的 IPSec 和 NAT 冲突问题。而解决方案就是使用 ESP-UDP-Encapsulate 封装模式，即：在 ESP Header 前加上一个 New UDP Header，srcPort 和 dstPort 均是 4500，使得 NAT 设备按照处理一个普通的 UDP 数据报的方式对它进行处理。这个方法同时适用于 Transport-ESP 和 Tunnel-ESP 模型，以及同时支持 PAT 和 NAT。

• UDP-Encapsulated-Transport 模式
  

                               
登录/注册后可看大图

• UDP-Encapsulated-Tunnel 模式
  

                               
登录/注册后可看大图

应用了 IPSec NAT-T 后，NAT 设备后有多台内网主机，它们都可以通过 NAT 之后并与 Server 建立 IPSec 连接了。

                               
登录/注册后可看大图

NAT-T 的协商过程

                               
登录/注册后可看大图

IPSec 连接两端需要在 IKE 完成协商后才能使用 NAT-T。

阶段一：

• 探测出双方都支持 NAT-T。
• 探测出双方报文传输路径上存在 NAT 设备。
• 前 4 个 Msg 都是使用 Sport=Dport=500 进行通信。但当探测到 NAT 设备后，作为 Initiator 再发出第 5 个 Msg 就会将端口切换到 Sport=Dport=4500，Responder 收到该消息后，如果解密成功，后续也会使用新的 4500 端口。注意，RFC3948 规定了 New UDP Header 中的端口要使用和 IKE 协商时相同的端口号，这个端口号在 RFC3947 中规定为 4500。
  

阶段二：

• 双方协商 NAT-T 的封装模式，UDP-Encapsulated-Tunnel 还是 UDP-Encapsulated-Transport。
• 其中，UDP-Encapsulated-Transport 模式还会向对方发送自己的原始 IP 地址，让对方可以据此修正后续 TCP 报文的 checksum。要知道，经过 NAT 设备之后，报文的 IP 地址发生了变化，就会导致接收端校验失败。IPsec 采用的方法是在 IKE 协商时，就将自己原始 IP 地址信息发给对端，这样 Server 在解密出 TCP 报文后，可以根据这个信息修正 checksum。
  

IPSec 的 MTU 分片和加密问题

由于 AH 和 ESP 封装协议会增加额外的首部和尾部，这可能会导致添加封装后 IPSec 报文超出了 L2 MTU，从而导致分片。IPSec 分片可能会引发一些问题，包括：增加网络延迟、增加网络负载、增加数据包丢失的风险等。例如：据统计 IPSec 分片可能会导致硬件加解密加速卡 50%～90% 的性能下降。这是因为 IPSec 分片首先需要进行软件重组，然后再传送给硬件卡进行解密，使得软件重组成为了限制硬件加速的瓶颈。

因此 IPSec 设备上线前往往需要仔细评估网络环境、设备能力和需求，选择合适的 IP MTU 配置策略，并进行充分的测试和验证，以确保 L2 MTU >= IP MTU + IPSec。

在大多数场景中，可以采用常规的 IP MTU 配置措施来避免 IPSec 分片，例如：

• 修改 IPSec 设备的 IP MTU 设置，确保内层的 Original IPv4 Packet 分片再添加上外层的 IPSec 封装后仍然不会超过 L2 MTU，继而导致 IPSec 封装报文的分片。比如说，在视频流场景中，由于无法避免的大包问题，Original IP Packet 分片是固然存在的，此时需要计算并设定更小的 IP MTU。
• 在措施 1 的基础上，通过在网络设备中启用 PMTUD（Path MTU Discovery）技术，在 L2 传输链路上进行 MTU 探测和协商出最佳的 L2 MTU 值，并在 IPSec 设备中自动调整 IP MTU 设置。
  

对于措施 2 而言，不同的网络设备型号会具有相应的功能特性，以 Cisco Router 作为 IPSec Gateway 时对 Tunnel-ESP（52B 开销）的处理特性为例，支持使用 ipsec 配置命令来修改对 IPSec 封装包的 PMTUD 处理，包括：clear、copy、set IP Header Flags DF 位。例如：

• 假设整个路径上的 L2 MTU 为 1500Bytes，未设置 IP Header Flags DF（Don’t Fragment）位，存在 IPSec 分片。
  

• Router 收到发往 H1 的 1500B 的 Original IP Packet（IPv4 Header 20B + TCP Payload 1480B）。
• Original IP Packet 经过 Tunnel-ESP 封装，增加了 52B 的开销（New IP Header + ESP Header + ESP Tail）。
• 此时的 IPSec 封装包为 1552B，超出了 L2 MTU 1500B，因此会进行分片。
• PSec 封装包被分为 2 片，分别为 1500B 和 72B（添加了额外的 New IPv4 Header 20B）。
• IPSec Tunnel 对端的 Router 接收到 2 个分片后，剥离附加的 New IPv4 Header，并重组为 IPSec 封装包，然后解密和解封装。
• 最终，Router 将 1500B 的 Original IP Packet 交给 H2。
  

假设整个路径上的 L2 MTU 为 1500Bytes，设置了 IP Header Flags DF（Don’t Fragment）位，避免 IPSec 分片。如下图所示。

• Router 收到 1500B 的 Original IP Packet 就将其丢弃，因为添加 IPSec 封装后会大于 PMTU（1500B）。
• Outer 向 H1 发送一条 ICMP 消息，并通知该 H1 下一跳 MTU 为 1442（1500 - 58 = 1442）。H1 会在其路由表中以 H2 主机路由的形式记录该信息。
• H1 将 H2 的 PMTU 降低到 1442B，因此 H1 在将数据重新发送到 H2 时发送更小的 Original IP Packet，然后添加 52B 的开销，由此产生 1496B 的 IPSec 封装包。
• 由于 IPSec 封装包的 New IP Header 中设置了 DF 位，因此，采用 1400B L2 MTU 的中间路由器将丢弃此数据包。
• 丢弃数据包的中间路由器向 IPSec 的发送端（第一个 Router）发送一条 ICMP 消息，告知其下一跳 L2 MTU 为 1400B，这个值记录在 IPSec Gateway SA 的 PMTU 中。
• H1 下次重新传输 1442B 的 Original IP Packet 时，Router 依旧会丢弃该数据包，因为最新的 PMTU 实际上更小。
• 所以 Router 继续向 H1 发送一条 ICMP 消息，通知它下一跳 MTU 现在为 1342（1400 - 58 = 1342），然后 H1 再次记录此信息。
• 当 H1 再次重新传输数据时，它使用 1342B MTU。此时，IPSec 封装包就不再需要分片了。
  

                               
登录/注册后可看大图

IPSec Virtual Private Network

Virtual Private Network 是 IPSec 的主要应用场景，具体的还可以分为以下细分场景：

• Site-to-Site（站点到站点）：S2S 通常是 2 个 IPSec VPN Gateway 之间的互联。应用在企业的多个分支机构互联场景中，这些站点之间的多台主机的数据通过 Gateway 建立的 IPSec 连接进行安全传输。
• End-to-End（端到端）：E2E 通常是 2 个 IPSec VPN Client 之间的互联。应用在主机互联场景中，这些主机之间的数据通过 IPSec 连接进行安全传输。
• End-to-Site（端到网关）：E2S 通常是 IPSec VPN Client 和 Gateway 之间的互联。应用在两个不同网络中的主机之间的数据通过 Gateway 建立的 IPSec 连接进行安全传输。通常会采用 L2TP over IPSec 方案进行部署，即：在 L2TP VPN 基础上采用 IPSec 来提供更好的安全保护。
  

                               
登录/注册后可看大图

IPSec Virtual Tunnel Interface

IPSec VTI（Virtual Tunnel Interface，虚拟隧道接口）是网络操作系统或服务器操作系统中的一种虚拟网络接口设备。

IPSec VTI 提供了一种将 IPSec VPN 配置为某个特定的网络接口上的能力，以便结合操作系统的 Routing 功能，实现将特定 Subnet 得网络流量通过特定的 VTI 发送到对应的 IPSec VPN 中。

• Tunnel 模式：IPSec VTI 将整个 Original IP Packet 封装在另一个 New IP Packet 中，此时 New IP Packet 的 srcIP 和 dstIP 会被更改为 Tunnel 两端的 IP 地址，然后进行加密。
• Transport 模式：IPSec VTI 仅对 Original IP Payload 进行加密和封装，而不会修改 IP Header，所以 Original IP Packet 的 srcIP 和 dstIP 不会被更改，IPSec VTI 仅用于加密。
  

使用 IPSec VTI 来建立 IPSec 安全连接具有以下优点：

• 简化配置：通过 Routes 来确定对哪些 IP Packets 需要进行 IPSec 保护。与通过 ACL 指定 IP Flow 范围的方式相比，这种方式简化了用户在部署 IPSec 安全策略时配置上的复杂性，使得 IPSec 的配置不会受到网络规划的影响，增强了网络规划的可扩展性，降低了网络维护成本。
• 减少开销：在保护远程接入用户流量的组网应用中，在 IPSec VTI 处进行报文封装，与 GRE over IPSec 或者 L2TP over IPSec 隧道封装方式相比，无需额外为入隧道流量加封装 GRE Header 或者 L2TP Header，减少了报文封装的层次，节省了带宽。
• 业务应用更灵活：IPsec VTI 在实施过程中明确地区分出 “加密前” 和 “加密后” 两个阶段，用户可以根据不同的组网需求灵活选择其它业务（例如：NAT、ACL、QoS）实施的阶段。例如：
  

• 如果用户希望对 IPSec 封装加密前的 IP Packets 应用 NAT、ACL、QoS，则可以在 IPSec VTI（Logical Interface）上应用策略；
• 如果希望对 IPSec 封装后的 IP Packets 应用 NAT、ACL、QoS，则可以在 Physical Interface 上应用策略。
  

IPSec VTI 的工作原理

下面以更复杂的 Tunnel 模式为例。IPSec VTI 对 Original IP Packets 的封装/解封装发生在 VTI 上，并将报文的 IPSec 处理过程区分为两个阶段：“加密前” 和 “加密后”。用户流量到达实施 IPSec 配置的设备后，需要 IPSec 处理的报文会被转发到 IPSec VTI 上进行加封装/解封装。

发包封装流程：

• Router 将从入接口接收到的 IP 明文送到转发模块进行处理；
• 转发模块依据路由查询结果，将 IP 明文发送到 IPSec VTI 进行加封装，Original IP Packet 被封装在一个 New IP Packet 中，New IP Packet 的 srcIP 和 dstIP 分别为 Tunnel 的 srcIP 和 dstIP。
• IPSec VTI 完成对 IP 明文的加封装处理后，将 IP 密文送到转发模块进行处理；
• 转发模块进行第二次路由查询后，将 IP 密文通过隧道接口的实际物理接口转发出去。
  

                               
登录/注册后可看大图

收包解封装流程：

• Router 将从入接口接收到的 IP 密文送到转发模块进行处理；
• 转发模块识别到此 IP 密文的目的地为本设备的隧道接口地址且 IP 协议号为 AH 或 ESP 时，会将 IP 密文送到相应的 IPSec VTI 进行解封装：将 IP 密文的 New IP Header 去掉，对 Original IP Packet 进行解密处理。
• IPSec VTI 完成对 IP 密文的解封装处理之后，将 IP 明文重新送回转发模块处理；
• 转发模块进行第二次路由查询后，将明文的 Original IP Packet 从隧道的实际物理接口转发出去。
  

                               
登录/注册后可看大图

Linux iptables 与 VTI 的结合

最初往 Linux Kernel 增加 VTI 功能的作者提到：

Virtual tunnel interface is a way to represent policy based IPsec tunnels as virtual interfaces in linux. This is similar to Cisco's VTI (virtual tunnel interface) and Juniper's representaion of secure tunnel (st.xx). The advantage of representing an IPsec tunnel as an interface is that it is possible to plug Ipsec tunnels into the routing protocol infrastructure of a router. Therefore it becomes possible to influence the packet path by toggling the link state of the tunnel or based on routing metrics.

这表明了 VTI 在 Linux Kernel 中也是一种虚拟网络设备，主要作用是将经过这个设备的 IP 流量打上标签，IPSec 的策略再根据这个标签和相关信息来判断流量该怎么转发。

在 Linux 中，经常使用 iptables 来为各类网络应用打标签，例如：通过 iptables 打标签给 tc 来控制流量，通过 iptables 打标签来给 iproute 来控制路由等做法。所以，通常也可以通过 iptables 给 IP 网络流量打上标签，继而实现让其数据包被 IPSec 转发的效果的。

GRE over IPSec VPN

由于 IPSec 只能加密并传输单播流量，而无法加密和传输组播数据，例如：语音、视频、动态路由协议，所以需要通过 GRE over IPSec 来弥补了这一缺陷。

首先通过 GRE（Generic Routing Encapsulation，通用路由封装）对报文进行封装，然后再由 IPSec 对封装后的报文进行加密和传输，从而保证了组播业务的安全。协议栈结构如下：

                               
登录/注册后可看大图

L2TP over IPSec VPN

由于 IPSec 只能加密并传输 IP 三层流量，而无法加密和传输 L2 二层流程，所以需要通过 L2TP over IPSec 来弥补这一缺陷。其封装格式如下图所示，在安全的 IPSec Tunnel 之间传输 PPP 数据帧。

                               
登录/注册后可看大图

shadowaikaoshi

纨绔不饿死，儒冠多误身。
丈人试静听，贱子请具陈。
甫昔少年日，早充观国宾。
读书破万卷，下笔如有神。