HCIA-Security_V4.0 | 11_加密技术应用

1 加密学的应用

在信息安全领域，主要使用数字信封、数字签名和数字证书等密码技术。

• 数字信封：结合对称和非对称加密，从而保证数据传输的机密性。
• 数字签名：采用散列算法，从而保证数据传输的完整性。
• 数字证书：通过第三方机构（CA）对公钥进行公证，从而保证数据传输的不可否认性。

常用场景：

• VPN：很多 VPN 技术需要采用加解密技术来保证数据的机密性，如 IPSec VPN、SSL VPN。
• IPv6：为了防止设备被攻击者冒充，可以在设备上配置 SEND（Secure Neighbor Discovery）路由器授权功能。通过数字证书技术选用合法网关设备。
• HTTPS 登录设备：管理员可以通过 HTTPS 方式安全地登录 HTTPS 服务器的 Web 界面，并通过 Web 界面对设备进行管理。为了提高双方建立 SSL 连接时的安全性，在设备上为 HTTPS 客户端指定由 Web 浏览器信任的 CA 颁发的本地证书。这样，Web 浏览器可以验证本地证书的合法性，避免了可能存在的主动攻击，保证了管理员的安全登录。
• 设备系统登录授权：将用户密码先进行摘要算法之后存放，用户登录时比对授权。

2 VPN 简介

2.1 VPN 基础

定义

虚拟专用网，用于在公网上构建私人专用虚拟网络并在此传输私网流量。通过把现有的物理网络分解成逻辑上隔离的网络，在不改变网络现状的情况下实现安全、可靠的连接。

基本特征：

• 专用（Private）：在用户视角与传统专网没有区别，并提供足够的安全保证，且与底层承载网络（一般为 IP 网络）之间保持资源独立。
• 虚拟（Virtual）：VPN 用户内部的通信是通过公共网络进行的，即获得的只是一个逻辑意义上的专网。这个公共网络称为 VPN 骨干网（VPN Backbone）。

优势：

• 安全：对数据进行封装和加密。
• 廉价：不需要改变现有网络拓扑。
• 支持移动业务。
• 可扩展性。
• 提供比传统数据专网更强的扩展性和灵活性。

封装原理

基本原理：隧道（Tunnel）技术。使用一种协议封装另一种协议报文（通常是 IP 报文），封装后的报文也可以再次被其他封装协议封装。对用户来说，隧道是其所在网络的逻辑延伸，在使用效果上与实际物理链路相同。

分类

根据应用场景

Client-to-Site VPN：客户端-企业内网，客户端可以是一台防火墙。又称 Remote Access VPN，适用于出差员工 VPN 拨号接入。此场景可以使用以下几种 VPN 技术实现：SSL、IPSec、L2TP 和 L2TP over IPSec。

Site-to-Site VPN：局域网（如公司内网）-局域网，部署的设备通常为路由器或防火墙。此场景可以使用以下几种 VPN 技术实现：IPSec、L2TP、L2TP over IPSec、GRE over IPSec 和 IPSec over GRE。

根据应用对象

Extranet VPN：利用 VPN 将企业网延伸至合作伙伴处，使不同企业间通过 Internet 来构筑 VPN；

Intranet VPN：通过公用网络进行企业内部各个网络的互连；

Access VPN：面向出差员工，允许出差员工跨越公用网络远程接入公司内部网络。

根据 VPN 实现层次

L3VPN

• 三层 VPN 工作在协议栈的网络层。
• IPSec VPN：IPSec 报头与 IP 报头工作在同一层次，封装报文时是以 IP in IP 的方式进行封装，或者是 IPSec 报头和 IP 报头同时对数据载荷进行封装；
• GRE VPN 可以实现任意一种网络协议在另一种网络协议上的封装。与 IPSec 相比，安全性没有保障。

L2VPN

• 二层 VPN 工作在协议栈的数据链路层。
• 主要有：
  • 点到点隧道协议（PPTP，Point-to-Point Tunneling Protocol）
  • 二层转发协议（L2F，Layer 2 Forwarding）
  • 二层隧道协议（L2TP，Layer 2 Tunneling Protocol）

关键技术

隧道技术

对传输报文进行封装，利用 VPN 骨干网建立专用数据传输通道，实现报文的安全传输。

分支 VPN 网关收到原始报文 → 封装 → 通过 Internet 传输到总部 VPN 网关 → 解封装。

“封装/解封装”过程本身就可以为原始报文提供安全防护功能，所有被封装的报文在 Internet 上传输时所经过的逻辑路径被称为“隧道”。

身份认证技术

• GRE：不支持针对用户的身份认证技术；
• L2TP：依赖 PPP 提供的认证。对接入用户进行认证的时候，可以使用本地认证也可以使用第三方 RADIUS 服务器来认证，认证通过以后会给用户分配内部的 IP 地址，通过此 IP 地址对用户进行授权和管理；
• IPSec：使用 IKEv2 时，支持对用户进行 EAP 认证。认证方式同 L2TP 一样，认证通过后分配 IP 地址，通过此 IP 地址可以对用户进行授权和管理；
• SSL VPN：对接入用户进行认证时，支持本地认证、证书认证和服务器认证，另外，接入用户也可以对 SSL VPN 服务器进行身份认证，确认 SSL VPN 服务器的合法性。

加密技术

加密对象：数据报文、协议报文。

• GRE：本身不提供加密技术，通常结合 IPSec 协议一起使用，依赖 IPSec 的加密技术。
• L2TP：本身不提供加密技术，通常结合 IPSec 协议一起使用，依赖 IPSec 的加密技术。
• IPSec：支持对数据报文和协议报文进行加密。
• SSL VPN：支持对数据报文和协议报文加密。

数据验证技术

采用摘要技术，检查报文真伪，丢弃伪造的、被篡改的报文。

技术对比

2.2 GRE VPN

简介

Generic Routing Encapsulation，通用路由封装，一种三层 VPN 封装技术。GRE 可以对某些网络层协议（如 IPX、Apple Talk、IP 等）的报文进行封装，使封装后的报文能够在另一种网络中（如 IPv4）传输，从而解决了跨越异种网络的报文传输问题。

异种报文传输的通道称为 Tunnel（隧道）。

通常通过在 IPv4 网络上建立 GRE 隧道，解决两个 IPv6 网络的通信问题。GRE 隧道两端的隧道地址可以配置为不同网段的地址。

协议栈

网络封装技术基本构成三要素：乘客协议、封装协议、传输协议。

净荷：GRE 封装前的报文。
乘客协议：GRE 封装前的报文协议。
封装协议（运载协议）：对报文协议封装 GRE 头部。
传输协议：对封装后的报文进行转发的协议。

封装

两步封装过程：

• 为原始报文添加 GRE 头；
• 在 GRE 头前面再加上新的 IP 头。

GRE 的封装操作是通过逻辑接口 Tunnel 完成的，Tunnel 接口是一个通用的隧道接口，所以 GRE 协议在使用这个接口的时候，会将接口的封装协议设置为 GRE 协议。Tunnel 接口的 Destination 地址一般指对端外网出口 IP 地址。

GRE 封装和解封装报文的过程如下：

• 设备从连接私网的接口接收到报文后，检查报文头中的目的 IP 地址字段，在路由表查找出接口，如果发现出接口是隧道接口，则将报文发送给隧道模块进行处理；
• 隧道模块接收到报文后首先根据乘客协议的类型和当前 GRE 隧道配置的校验参数，对报文进行 GRE 封装，即添加 GRE 报文头；
• 设备给报文添加传输协议报文头，即 IP 报文头。该 IP 报文头的源地址就是隧道源地址，目的地址就是隧道目的地址；
• 设备根据新添加的 IP 报文头目的地址，在路由表中查找相应的出接口，并发送报文。之后，封装后的报文将在公网中传输。
• 接收端设备从连接公网的接口收到报文后，首先分析 IP 报文头，如果发现协议类型字段的值为 47，表示协议为 GRE，于是出接口将报文交给 GRE 模块处理。GRE 模块去掉 IP 报文头和 GRE 报文头，并根据 GRE 报文头的协议类型字段，发现此报文的乘客协议为私网中运行的协议，于是将报文交给该协议处理。

报文处理过程

• PC_A 访问 PC_B 的原始报文进入防火墙 A 后，首先匹配路由表；
• 根据路由查找结果，防火墙 A 将报文送到 Tunnel 接口进行 GRE 封装，增加 GRE 头，外层加新 IP 头；
• 防火墙 A 根据 GRE 报文的新 IP 头的目的地址（2.2.2.2），再次查找路由表；
• 防火墙 A 根据路由查找结果将报文发送至防火墙 B，图中假设防火墙 A 查找到的去往防火墙 B 的下一跳地址是 1.1.1.2;
• 防火墙 B 收到 GRE 报文后，首先判断这个报文是不是 GRE 报文。封装后的 GRE 报文会有个新的 IP 头，这个新的 IP 头中有个 Protocol 字段，字段中标识了内层协议类型，如果这个 Protocol 字段值是 47，就表示这个报文是 GRE 报文。如果是 GRE 报文，防火墙 B 则将该报文送到 Tunnel 接口解封装，去掉新的 IP 头和 GRE 头，恢复为原始报文；如果不是，则报文按照普通报文进行处理；
• 防火墙 B 根据原始报文的目的地址再次查找路由表，然后根据路由匹配结果将报文发送至 PC_B。

安全策略

• 原始报文进入 Tunnel 接口：Trust > DMZ；
• 原始报文 GRE 封装后防火墙 A 进行转发：Local > Untrust；
• 报文到达防火墙 B 解封装：Untrust > Local；
• 报文解封装后防火墙 B 转发原始报文：DMZ > Trust。

2.3 IPSec VPN

IPSec VPN 简介

IPSec（IP Security）协议族是 IETF 制定的一系列安全协议，IPSec VPN 是利用 IPSec 隧道建立的网络层 VPN。

L2TP VPN 和 GRE VPN 上数据明文传输，在网络中部署 IPSec，可对传输的数据进行保护。

IPSec 从以下几个方面保障了用户业务数据在 Internet 中的安全传输：

• 数据来源验证
• 数据加密
• 数据完整性
• 抗重放

IPSec VPN 体系结构

IPSec VPN 体系结构主要由 AH、ESP 和 IKE 协议套件组成。

• AH 协议：报文头验证协议，主要提供的功能有数据源验证、数据完整性校验和防报文重放功能。但不加密所保护的数据报；
• ESP 协议：封装安全载荷协议。提供 AH 协议的所有功能外（但其数据完整性校验不包含 IP 头），还可提供对 IP 报文的加密功能；
• IKE 协议：用于自动协商 AH 和 ESP 所使用的密码算法。

IPSec 协议体系

IPSec 通过验证头 AH（Authentication Header）和封装安全载荷 ESP（Encapsulating Security Payload）两个安全协议实现 IP 报文的安全保护。

• AH 是报文头验证协议，主要提供数据源验证、数据完整性验证和防报文重放功能，不提供加密功能；
• ESP 是封装安全载荷协议，主要提供加密、数据源验证、数据完整性验证和防报文重放功能。

• AH 和 ESP 协议提供的安全功能依赖于协议采用的验证、加密算法。
• IPSec 加密和验证算法所使用的密钥可以手工配置，也可以通过因特网密钥交换 IKE（Internet Key Exchange）协议动态协商。

AH 和 ESP 报文格式对比

AH 报文头字段含义如下：

• Next Header（下一头部）：8 比特，标识 AH 报文头后面的负载类型。传输模式下，是被保护的上层协议（TCP 或 UDP）或 ESP 协议的编号；隧道模式下，是 IP 协议或 ESP 协议的编号；
• Pad Length（负载长度）：8 比特，表示以 32 比特为单位的 AH 头部长度减 2，缺省为 4；
• Reserved（保留字段）：16 比特，保留将来使用，缺省为 0；
• SPI（安全参数索引）：32 比特，用于唯一标识 IPSec 安全联盟；
• Sequence Number（序列号）：32 比特，是一个从 1 开始的单项递增的计数器，唯一地标识每一个数据包，用于防止重放攻击；
• Authentication Data（认证数据）：一个变长字段，长度为 32 比特的整数倍，通常为 96 比特。该字段包含数据完整性校验值 ICV（Integrity Check Value），用于接收方进行完整性校验。可选择的认证算法有 MD5（Message Digest）、SHA-1（Secure Hash Algorithm）、SHA-2、SM3。前三个认证算法的安全性由低到高依次排列，安全性高的认证算法实现机制复杂，运算速度慢。SM3 密码杂凑算法是中国国家密码管理局规定的 IPSec 协议规范。

封装模式

传输模式

AH 头或 ESP 头被插入到 IP 头与传输层协议头之间，保护 TCP/UDP/ICMP 负载。

以 TCP 报文为例。原始报文经过传输模式封装后，报文格式如图所示。

传输模式不改变报文头，故隧道的源和目的地址必须与 IP 报文头中的源和目的地址一致，所以只适合两台主机或一台主机和一台 VPN 网关之间通信。

隧道模式

AH 头或 ESP 头被插到原始 IP 头之前，另外生成一个新的报文头放到 AH 头或 ESP 头之前，保护 IP 头和负载。在新的 IP 报文头部字段中，TTL（Time To Live，存活时间）参数无需进行数据完整性校验。

以 TCP 报文为例，原始报文经隧道模式封装后的报文结构如图所示。

隧道模式主要应用于两台 VPN 网关之间（主要）或一台主机与一台 VPN 网关之间的通信。

区别与联系

区别：

• 安全性：隧道模式优于传输模式，它可以完全地对原始IP 数据报进行验证和加密，隐藏内部 IP 地址、协议类型和端口；
• 性能：隧道模式的额外 IP 头使其占用更多带宽。

当安全协议同时采用 AH 和 ESP 时，AH 和 ESP 协议必须采用相同的封装模式。

IPSec 数据加密及认证

两种安全机制：加密和认证：

• 加密：采用对称加密算法对数据进行加解密。
• 认证：采用 HMAC（Hash-based Message Authentication Code）功能，比较数字签名进行数据完整性和真实性认证。

• ICV（Integrity Check Value）用于接收方进行完整性校验。可选择的认证算法有 MD5、SHA1、SHA2、SHA3。
• MAC 密钥：Message Authentication Code 密钥，用于 HMAC 算法。

IPSec 常用的对称加密算法包括：

• 数据加密标准 DES（Data Encryption Standard）
• 3DES（Triple Data Encryption Standard）
• 先进加密标准 AES（Advanced Encryption Standard）
• 国密算法（SM1 和 SM4）

其中 DES 和 3DES 算法安全性低，存在安全风险，不推荐使用。

IPSec 常用的验证算法包括：

• 消息摘要 MD5（Message Digest 5）
• 安全散列算法 SHA1（Secure Hash Algorithm 1）、SHA2
• 国密算法 SM3

其中 MD5、SHA1 算法安全性低，存在安全风险，不推荐使用。

IKE 与 AH/ESP 之间关系

• IKE 是 UDP 之上的一个应用层协议，是 IPSec 的信令协议。IKE 为 IPSec 协商生成密钥，供 AH/ESP 加解密和验证使用。AH 协议和 ESP 协议有自己的协议号，分别是 51 和 50。
• IKE 协议有 IKEv1 和 IKEv2 两个版本。

IKE 的交换阶段

IKE 使用了两个阶段为 IPSec 进行密钥协商并建立安全联盟。

• 第一阶段：通信各方彼此间建立了一个已通过身份验证和安全保护的隧道，即 IKE SA（Internet Key Exchange Security Association，互联网密钥交换安全联盟）。协商模式包括主模式、野蛮模式。认证方式包括预共享密钥、数字签名方式、公钥加密；
• 第二阶段：用在第一阶段建立的安全隧道为 IPSec 协商安全服务，建立 IPSec SA。IPSec SA 用于最终的 IP 数据安全传送。协商模式为快速模式。

IKE 使用了两个阶段的 ISAKMP（Internet Security Association Key Management Protocol，Internet 安全关联 密钥管理 协议）。第一阶段建立 IKE 安全联盟（IKE SA），第二阶段利用这个既定的安全联盟，为 IPSec 协商具体的安全联盟。

在 RFC2409（The Internet Key Exchange）中规定，IKE 第一阶段的协商可以采用两种模式：主模式（Main Mode）和野蛮模式（Aggressive Mode）。这两种模式各自做着同样的事情：建立一个加密和验证无误的通信信道（IKE SA），以及生成验证过的密钥，为双方的 IKE 通信提供机密性、消息完整性以及消息源验证服务。IKE 中定义的其他所有交换都要求一个验证过的 IKE SA 作为首要条件。所以无论是主模式还是野蛮模式，第一阶段都必须在其他交换之前完成。

IKE 的工作流程如下：

• 当一个报文从某接口外出时，如果此接口应用了 IPSec，会进行安全策略的匹配；
• 如果找到匹配的安全策略，会查找相应的安全联盟。如果安全联盟还没有建立，则触发 IKE 进行协商。IKE 首先建立第一阶段的安全联盟，即 IKE SA；
• 在第一阶段安全联盟的保护下协商第二阶段的安全联盟，即 IPSec SA；
• 使用 IPSec SA 保护通讯数据。

IPSec SA

安全传输数据前提：在 IPSec 对等体（即运行 IPSec 协议的两个端点）之间成功建立安全联盟 SA（Security Association）。

IPSec SA 是单向的。

作用：帮助 IPSec 对特定要素进行约定，比如：加密算法使用 DES，认证算法使用 MD5，封装方式使用 Tunnel 等。

IPSec 技术在数据加密、数据验证、数据封装等方面有多种实现方法或算法，两端的设备使用 IPSec 进行通信时需要保证一致的加密算法、验证算法等。因此需要一种机制帮助两端设备协商这些参数。

建立 IPSec 一般有两种方式：

• 手工方式：管理成本很高，加密验证方式需要手工配置，手工刷新 SA，且 SA 信息永久存在安全性较低，适用于小型网络；
• IKE 方式：管理成本比较低，加密验证方式通过 DH 算法生成，SA 信息有生成周期，且 SA 动态刷新，适用于小型、中大型网络。

IPSec SA 由一个三元组来唯一标识，包括安全参数索引 SPI（Security Parameter Index）、目的 IP 地址和使用的安全协议号（AH 或 ESP）。

IKE SA 的主要作用是构建一条安全的通道，用于交互 IPSec SA。

IKE SA

现网中交互对称密钥一般会使用密钥分发协议：IKE（Internet Key Exchange，因特网密钥交换）。

IKE 协议建立在 ISAKMP 定义的框架上，是基于 UDP 的应用层协议。它为 IPSec 提供了自动协商密钥、建立 IPSec 安全联盟的服务，能够简化 IPSec 的配置和维护工作。

IKE SA 是双向的。

• IKE 支持的认证算法有：MD5、SHA1、SHA2-256、SHA2-384、SHA2-512、SM3。
• IKE 支持的加密算法有：DES、3DES、AES-128、AES-192、AES-256、SM1 和 SM4。

ISAKMP 由 RFC2408 定义，定义了协商、建立、修改和删除 SA 的过程和包格式。

• ISAKMP 只是为 SA 的属性和协商、修改、删除 SA 的方法提供了一个通用的框架，并设有定义具体的 SA 格式。
• ISAKMP 报文可以利用 UDP 或者 TCP，端口都是 500，一般情况下常用 UDP 协议。

IKEv1 第一阶段协商

主模式预共享密钥协商过程

主模式被设计成将密钥交换信息与身份认证信息相分离的一种交换技术。保证了身份信息在传输过程中的安全性，因为交换的身份信息受到了加密保护。

完成第一阶段协商的 3 步骤 6 消息 → 建立 IKE SA：

• 模式协商
• Diffie-Hellman 交换和 nonce 交换
• 对对方身份的验证

特点：

• 身份保护：
  在对方希望隐藏自己的身份时尤为重要。
• 对 ISAKMP 协商能力的完全利用。

若使用预共享密钥方法验证，在消息 1、2 发送之前，协商发起者和响应者必须计算产生自己的 cookie，用于唯一标识每个单独的协商交换。cookie 使用源/目的 IP 地址、随机数字、日期和时间进行 MD5 运算得出，并且放入消息 1 的 ISAKMP 中，用以标识单独的一个协商交换。

在第一次交换中，需要交换双方的 cookie 和 SA 载荷，在 SA 载荷中携带需要协商的 IKE SA 的各项参数，主要包括 IKE 的散列类型、加密算法、认证算法和 IKE SA 的协商时间限制等。

第一次交换后到第二次交换前，通信双方需要生成用于产生 Diffie-Hellman 共享密钥的 DH 值。生成方法是双方各自生成一个随机数字，通过 DH 算法对随机数字进行运算，得出一个 DH 值 Xa 和 Xb（Xa 是发起方的 DH 值，Xb 是响应者的 DH 值），然后双方再根据 DH 算法运算得出一个临时 Ni 和 Nr。

在第二次交换中，双方交换各自的密钥交换载荷（即 Diffie-Hellman 交换）以及临时值载荷（即 nonce 交换）。其中密钥交换载荷包含了 Xa 和 Xb，临时值交换包含了 Ni 和 Nr。

双方交换了临时值载荷 Ni 和 Nr 之后，配合事先预置好的预共享密钥(?)，再通过随机函数运算便可产生一个密钥 SKEYID，这个密钥是后续所有密钥生成的基础。随后，通过自己算出来的 DH 值、交换得到的 DH 值以及 SKEYID 进行运算便可产生一个只有双方才知道的共享密钥 SKEYID_d。此共享密钥并不进行传输，传输的只是 DH 值以及临时值，因此即使第三方得到了这些材料也无法计算出共享密钥。

在第二次交换完成后，双方所需的计算材料都已经交换完毕，此时，双方就可以将所有的密钥计算出来，并使用该密钥对随后的 IKE 消息提供安全保护。这些密钥包括：SKEYID_a 以及 SKEYID_e。SKEYID_a 用来为 IKE 消息提供完整性以及数据源身份验证等安全服务；SKEYID_e 则用于对 IKE 消息进行加密。

第三次交换是对标识载荷和散列载荷进行交换。标识载荷包含了发起者的标识信息、IP 地址或主机名。散列载荷包含上一过程中产生的三组密钥进行 Hash 运算得出的值。这两个载荷通过 SKEYID_e 进行加密，如果双方的载荷相同，那么认证成功，IKE 第一阶段主模式预共享密钥交换也就完成了。

野蛮模式预共享密钥协商过程

共需交换 3 个消息：

• 消息 1 交换 SA 载荷、密钥材料和身份信息；
• 消息 2 在交换消息 1 内容的同时增加了 Hash 认证载荷；
• 消息 3 是响应方对发起方的认证。

从上述主模式协商的叙述中可以看到，在第二次交换之后便可生成会话密钥，会话密钥的生成材料中包含了预共享密钥。而当一个对等体同时与多个对等体进行协商 SA 是，则需要为每个对等体设置一个预共享密钥。为了对每个对等体正确地选择对应的预共享密钥，主模式需要根据前面交换信息中的 IP 地址来区分不同的对等体。

但是当发起者的 IP 地址是动态分配获得时，由于发起者的 IP 地址不可能被响应者提前知道，而且双方都打算采用预共享密钥验证方法，此时响应者就无法根据 IP 地址选择对应的预共享密钥。野蛮模式就是被用于解决这个矛盾的，野蛮模式可以采用 IP 地址方式或名称方式标识对等体。

由于对消息数进行了限制，野蛮模式同时也限制了它的协商能力，而且由于在其第一条信息中就携带了身份信息，因此本身无法对身份信息进行加密保护，这就降低了协商的安全性，但也因此不依赖 IP 地址标识身份，在野蛮模式下也就有了更对灵活的应用。

IKEv1主模式和野蛮模式区别

交换的消息：

• 主模式为 6 个，野蛮模式为 3 个。

身份保护：

• 主模式的最后两条消息有加密，可以提供身份保护功能；而野蛮模式消息集成度过高，因此无身份保护功能。

对等体标识：

• 主模式只能采用 IP 地址方式标识对等体；而野蛮模式可以采用 IP 地址方式或者 Name 方式标识对等体。

IKEv1 第二阶段协商

快速模式协商过程

快速模式一共需要交换 3 个消息：

• 消息 1 和消息 2 中，交换 SA、KEY、Nonce 和 ID。用以协商算法、保证 PFS 以及提供“在场证据”；
• 消息 3 是用于验证响应者是否可以通信，相当于确认信息。

建立好 IKE SA 之后（无论通过主模式还是通过野蛮模式交换），便可用它为 IPSec 生成相应的 SA。IPSec SA 是通过快速模式交换来建立的，对快速模式交换来说，它是在已经建立好的 IKE SA 的保护下完成的。

在一次快速交换模式中，通信双方需要协商拟定 IPSec 安全联盟的各项特征，并为其生成密钥。IKE SA 保护快速模式交换的方法是：对其进行加密，并对消息进行验证。消息的验证是通过伪随机函数来进行的。来自 IKE SA 的 SKEYID_a 的值作为一个密钥，对快速模式交换的整个消息进行验证。这种验证除了能提供数据完整性保证之外，还能对数据源的身份进行验证。在消息接收到之后，我们知道它只有可能来自验证通过的实体，而且那条消息在传送过程并未发生改变。而通过加密（使用 SKEYID_e），则可保障交换的机密性。

快速模式需要从 SKEYID_d 状态中衍生出用于 IPSec SA 的密钥，这个密钥将在伪随机函数中使用，这样便可确保每个 SA 都有自己独一无二的密钥。每个 SA 都有一个不同的 SPI，所以入方向 SA 的密钥也会与出方向 SA 不同。所有 IPSec 密钥都是根据相同的来源衍生的，所以相互间都有关联。假如一名攻击者能够根据 IKE SA 判断出 SKEYID_d 的值，那么就能非常容易地掌握自那个 SKEYID_d 衍生出来的 IPSec SA 的任何密钥。另外，还能继续掌握未来将要衍生的所有密钥，这显然是个大问题，所有这些密钥都不能保证所谓的“完美向前保密（PFS）”。快速 模式为此专门提供了一个 PFS 选项，来满足这方面的需要，用户可根据自己地安全需要选择是否使用 PFS。

为了在快速模式交换中实现 PFS，需要执行一次额外的 Diffie-Hellman 交换，最终生成的共享密钥将在为 IPSec 生成密钥的过程中用到。显然，一旦交换完成，这个密钥便不复存在。一旦完成，它所驻留的那个内存位置必须清零和释放。从而保证了密钥之间的不相关性。

我们前面将快速模式描述成一种简单的请求／响应交换，但它的实际功用远不止于此。发起者可能需要一个“在场”证据，证明响应者在线，而且已经实际地处理了它的初始快速模式消息。为了达到这个要求，响应者需要在验证散列载荷中，加入交换的发起者 nonce 以及消息 ID。这个摘要现在不仅能保障消息的完整性，也能为发起者提供源验证功能，另外还能提供在场证据。

响应者也需要一个在场证据，从发起者传来的可能是一条过期的消息，是由不怀好意的人重播的。这个人可能不知道消息的内容，但通过对通信的分析，能够知道它是一条快速模式消息。如果重播那条消息，响应者便不得不创建多余的 SA。我们可将其想像成一种“服务否认”攻击，只是属于比较温和的那种，因为响应者会根据这条消息，增加不必要的内存及 SA 管理开销。想要防范此类攻击，需在快速模式交换中增加第三条消息。在这条消息中，发起者需要同时包括 nonce 和此次交换的消息 ID，并把它们保存在一个验证散列载荷中。这样发起者便可向响应者证实：自己是此次交换的活动参与者。

在前两条消息中，发起者和响应者都发送了 SA 载荷，和主模式、野蛮模式一样，SA 载荷是用来协商各种保护算法的。而 Ni、Nr 以及 ID 则是用来提供“在场证据”的。Xa 以及 Xb 则是用来生成新的 DH 共享密钥，保证 PFS 的。Xa 以及 Xb 将与 IKE 第一阶段生成的 SKEYID_d、Ni、Nr 以及 SPI 等信息共同生成最终用于 IPSec 加密的密钥。

最后发起者会发送一条确认信息，响应者收到该信息后就知道发起者已经收到了第二条消息。此时 IKE 第二阶段结束。

IKEv2 协商

IKEv2 定义了三种交换：初始交换（Initial Exchanges）、创建子 SA 交换（Create_Child_SA Exchange）以及通知交换（Informational Exchange）。

采用 IKEv2 协商安全联盟比 IKEv1 协商过程要简化的多。要建立一堆 IPSec SA，IKEv1 需要经历两个阶段：“主模式+快速模式”或者“野蛮模式+快速模式”，前者至少需要交换 9 条消息，后者也至少需要 6 条消息。而 IKEv2 正常情况使用 2 次交换共 4 条消息就可以完成一对 IPSec SA 的建立，如果要求建立的 IPSec SA 大于一对时，每一对 IPSec SA 只需要额外增加 1 次创建子 SA 交换，也就是 2 条消息就可以完成。

初始交换

正常情况下，IKEv2 通过初始交换就可以完成第一对 IPSec SA 的协商建立。IKEv2 初始交换对应 IKEv1 的第一阶段，初始交换包含两次交换四条消息，如下图所示：

• 消息 ① 和 ② 属于第一次交换（称为 IKE_SA_INIT 交换），以明文方式完成 IKE SA 的参数协商，包括协商加密和验证算法、交换临时随机数和 DH 交换。
  IKE_SA_INIT 交换后生成一个共享密钥材料，通过这个共享密钥材料可以衍生出 IPSec SA 的所有密钥。
• 消息 ③ 和 ④ 属于第二次交换（称为 IKE_AUTH 交换），以加密方式完成身份认证、对前两条信息的认证和 IPSec SA 的参数协商。IKEv2 支持 RSA 签名认证、预共享密钥认证以及扩展认证方法 EAP（Extensible Authentication Protocol）。EAP 认证是作为附加的 IKE_AUTH 交换在 IKE 中实现的，发起者通过在消息 3 中省去认证载荷来表明需要使用 EAP 认证。

创建子 SA 交换

当一个 IKE SA 需要创建多对 IPSec SA 时，需要使用创建子 SA 交换来协商多于一对的 IPSec SA。另外，创建子 SA 交换还可以用于 IKE SA 的重协商。

创建子 SA 交换包含一个交换两条消息，对应 IKEv1 协商阶段 2，交换的发起者可以是初始交换的协商发起方，也可以是初始交换的协商响应方。创建子 SA 交换必须在初始交换完成后进行，交换消息由初始交换协商的密钥进行保护。

类似于 IKEv1，如果启用 PFS，创建子 SA 交换需要额外进行一次 DH 交换，生成新的密钥材料。生成密钥材料后，子 SA 的所有密钥都从这个密钥材料衍生出来。

通知交换

运行 IKE 协商的两端有时会传递一些控制信息，例如错误信息或者通告信息，这些信息在 IKEv2 中是通过通知交换完成的，如图所示。

通知交换必须在 IKE SA 保护下进行，也就是说通知交换只能发生在初始交换之后。控制信息如果是 IKE SA 的，那么通知交换必须由该 IKE SA 来保护进行；控制信息如果是某子 SA 的，那么该通知交换必须由生成该子 SA 的 IKE SA 来保护进行。

2.4 L2TP VPN

简介

L2TP（Layer Two Tunneling Protocol）二层隧道协议是另一种常见 VPN 协议。

L2TP 是虚拟私有拨号网 VPDN（Virtual Private Dial-up Network）隧道协议的一种，它扩展了点对点协议 PPP（Point to Point Protocol）的应用，是一种在远程办公场景中为出差员工或企业分支远程访问企业内网资源提供接入服务的 VPN。使用的端口号为 1701。

三种主要使用场景：

• NAS-Intiated VPN：由远程拨号用户发起，远程系统通过 PSTN（Public Switched Telephone Network）/ISDN（Intergrated Service Digital Network）拨入 LAC（Link Access Concentrator）。由 LAC 通过 Internet 向 LNS（L2TP Network Server）发起建立隧道连接请求，拨号用户地址则由 LNS 分配。对远程拨号用户的验证与计费既可由 LAC 侧的代理完成，也可在 LNS 完成；
• Call-LNS：L2TP 除了可以为出差员工提供远程接入服务以外，还可以进行企业分支与总部的内网互联，实现分支用户与总部用户的互访。
• Client-Initialized：直接由 LAC 客户（指可在本地支持 L2TP 协议的用户）发起。客户需要知道 LNS 的 IP 地址。LAC 客户可直接向 LNS 发起隧道连接请求，无需再经过一个单独的 LAC 设备。在 LNS 设备上收到了 LAC 客户的请求之后，根据用户名、密码进行验证，并且给 LAC 客户分配私有 IP 地址。

Client-Initiated 场景中的 L2TP VPN 原理

从隧道协商、报文封装、安全策略这 3 个方面介绍 Client-Initiated 场景中 L2TP VPN 的工作原理。

隧道协商

移动办公用户在访问企业总部服务器之前，需要先通过 L2TP VPN 软件与 LNS 建立 L2TP VPN 隧道。

每个接入用户和 LNS 之间均建立一条隧道，每条隧道中仅承载一条 L2TP 会话和 PPP 连接。

下图所示是移动办公用户与 LNS 协商建立 L2TP VPN 隧道，直至最后成功访问企业内网资源的完整过程，流程为：建立 L2TP 隧道 → 建立 L2TP 会话 → LNS 对用户进行认证 → 建立 PPP 连接 → 用户访问内网资源。

报文封装

原始报文只携带了内层私网 IP 头，内层私网 IP 头中的源地址是 L2TP Client 获取到的私网 IP 地址，目的地址是内网服务器的私网 IP 地址。LNS 根据目的地址查找路由表，然后根据路由匹配结果转发报文。

安全策略

下图所示为 LNS 设备上报文所经过的安全域间，以及 LNS 的安全策略匹配条件。

移动办公用户访问总部服务器的过程中，经过 LNS 的流量分为以下 2 类，对应流量的安全策略处理原则如下：

• 移动办公用户与 LNS 间的 L2TP 报文：此处的 L2TP 报文既包含移动办公用户与 LNS 建立隧道时的 L2TP 协商报文，也包含移动办公用户访问企业总部服务器被解封前的业务报文，这些 L2TP 报文会经过 Untrust > Local 区域；
• 移动办公用户访问企业总部内网服务器的业务报文：LNS 通过 VT 接口将移动办公用户访问企业总部服务器的业务报文解封装以后，这些报文经过的安全域间为 DMZ > Trust。DMZ 区域为 LNS 上 Tunnel 接口所在的安全区域，Trust 为 LNS 连接总部内网接口所在的安全区域。

2.5 SSL VPN

简介

通过 SSL 协议实现远程安全接入的 VPN 技术。

解决问题：

• 移动办公用户需要安装指定的客户端软件
• 网络部署和维护都比较麻烦
• 无法对移动办公用户的访问权限做精细化控制

主要应用场景：企业出差员工。
特点：远程、身份认证、权限精细化控制。

SSL VPN 能够有效支援一对多的模式，但是在多对多的状况下支援度较差，较不适用于 Site-to-Site 的环境。虽然有部分设备可以通过类似 IPSec VPN 的创建方式创建 Site-to-Site 的环境，但使用上有其先天限制，在传输效能表现上较差。

封装

位于传输层与各种应用层协议之间，为数据通讯提供安全支持，建立在可靠的传输协议（如 TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。

虚拟网关

防火墙通过虚拟网关向移动办公用户提供 SSL VPN 接入服务，虚拟网关是移动办公用户访问企业内网资源的统一入口。下图是移动办公用户登录 SSL VPN 虚拟网关并访问企业内网资源的总体流程。系统管理员在防火墙上创建 SSL VPN 虚拟网关，并通过虚拟网关对移动办公用户提供 SSL VPN 接入服务。

流程：用户登录 → 用户认证 → 角色授权 → 资源访问

业务

Web 代理

移动办公用户访问内网 Web 资源时使用。

Web 代理按照实现方式的不同分为了 Web 改写和 Web link 两种。

• Web 改写：
  改写的两层含义：第一层是加密，即远程用户在点击虚拟网关资源列表中的链接时，虚拟网关会将用户要访问的真实 URL 进行加密。第二层是适配，防火墙将内网 Web 资源根据不同终端设备使用的不同操作系统和浏览器改写后转发给远程用户。
• Web Link：
  Web Link 不会进行加密和适配，只做单纯转发远程用户的 Web 资源请求。

文件共享

远程用户访问内网文件服务器（如支持 SMB 协议的 Windows 系统、支持 NFS 协议的 Linux 系统）时使用。

远程用户直接通过 Web 浏览器就能在内网文件系统上创建和浏览目录，进行下载、上传、改名、删除等文件操作。

在文件共享业务中防火墙起到了协议转换器的作用，以访问内网 Windows 文件服务器为例：

端口转发

远程用户访问内网 TCP 资源时使用端口转发业务。适用于 TCP 的应用服务包括 Telnet、远程桌面、FTP、Email 等。端口转发提供了一种端口级的安全访问内网资源的方式。

端口转发需要在客户端上运行一个 Active X 控件作为端口转发器，用于侦听指定端口上的连接。以用户 Telnet 到内网服务器为例，端口转发的实现过程如图所示。

网络扩展

远程用户访问内网 IP 资源时使用网络扩展业务，Web 资源、文件资源以及 TCP 资源都属于 IP 资源。

通常在不区分用户访问的资源类型时为对应用户开通网络扩展业务。

①：远程用户通过 Web 浏览器登录虚拟网关。
成功登录虚拟网关后启动网络扩展功能。启动网络扩展功能会触发“建立一条 SSL VPN 隧道”和②。

3 VPN 配置

IPSec VPN 配置举例

需求描述

• 两个网关之间通过 IKE 方式协商 IPSec VPN 隧道（采用预共享密钥认证），从而实现局域网之间安全地互访；
• 网络 A 和网络 B 通过防火墙 A 和 B 之间建立的 IPSex 隧道互联互通；
• 网络 A 属于 10.1.1.0/24 子网，通过接口 GigabitEthernet 0/0/3 与防火墙 A 连接；
• 网络 B 属于 10.1.2.0/24 子网，通过接口 GigabitEthernet 0/0/3 与防火墙 B 连接；
• 防火墙 A 和防火墙 B 路由可达。

配置思路

配置命令

定义被保护的数据流。

• 防火墙 A：配置高级 ACL 3000，允许 10.1.1.0/24 网段访问 10.1.2.0/24 网段。
  

• 防火墙 B：配置高级 ACL 3000，允许 10.1.2.0/24 网段访问 10.1.1.0/24 网段。
  

配置 IPSec 安全提议。（防火墙 A 与防火墙 B 配置相同，缺省参数可不配置）

配置 IKE 安全提议。（防火墙 A 与防火墙 B 配置相同）

配置 IKE peer。

配置 IPSec 策略。

引用 IPSec 策略。

• 防火墙 A：在接口 GigabitEthernet 0/0/1 上应用 IPSec 策略组 map1。
  

• 防火墙 B：在接口 GigabitEthernet 0/0/1 上应用 IPSec 策略组 map1.
  

SSL VPN 配置举例

需求描述

企业希望移动办公用户通过 Web 代理访问企业 Web 服务器（Web Link）；

企业使用防火墙的本地认证对各部门的员工进行用户认证，通过认证的用户能够获得接入企业内部网络的权限。

配置思路

• 配置用户和认证：配置认证域，创建用户组和用户；
• 配置 Web Link 功能：启用 Web Link 功能，配置 Web Link 资源；
• 配置角色授权：将用户组添加到虚拟网关中，创建角色，将角色与用户组绑定，同时启用 Web Link 功能；
• 配置安全策略，允许移动办公用户登录 SSL VPN 网关；允许出差员工访问 Web 代理资源。

配置命令

配置用户与认证。

“对象 > 用户 > default”，按如下参数配置，单击“应用”

用户 user0001 所属的用户组为 /default/group1，认证类型为本地认证，密码为 Password@123。需要注意，在新建用户 user0001 之前，应先新建用户组 /default/group1，这样才能在新建用户时引用已创建好的用户组。

命令行配置如下：

[FW] aaa
[FW-aaa] domain default
[FW-aaa-domain-default] authentication-scheme default
[FW-aaa-domain-default] service-type ssl-vpn
[FW-aaa-domain-default] quit
[FW-aaa] quit
[FW] user-manage group /default/group1
[FW-usergroup-/default/group1] quit
[FW] user-manage user user0001 domain default
[FW-localuser-user0001] password Password@123
[FW-localuser-user0001] parent-group /default/group1
[FW-localuser-user0001] quit

配置 SSL VPN 网关。

“网络 > SSL VPN > SSL VPN > 新建”，按如下参数配置。

命令行配置如下：

[FW] v-gateway gateway interface GigabitEthernet 0/0/1 private
[FW] v-gateway gateway udp-port 443
[FW] v-gateway gateway authentication-domain default

配置 SSL 协议的版本、加密套件、会话超时时间和生命周期。

可直接使用默认值。“Web 代理 > 下一步”。

命令行配置如下：

[FW] v-gateway gateway
[FW-gateway] service
[FW-gateway-service] web-proxy enable
[FW-gateway-service] web-proxy web-link enable

配置 Web 代理。

“Web 代理资源列表 > 新建”。

命令行配置如下：

[FW-gateway-service]web-proxy link-resource Web-Server http://10.2.0.2:8080 show-link

配置 SSL VPN 的角色授权

“角色授权列表 > 新建”

命令行配置如下：

[FW-gateway] vpndb
[FW-gateway-vpndb] group /default/sslvpn
[FW-gateway-vpndb] quit
[FW-gateway] role
[FW-gateway-role] role role
[FW-gateway-role] role role group /default/sslvpn
[FW-gateway-role] role role web-proxy enable
[FW-gateway-role] role role web-proxy resource Web-Server
[FW-gateway-role] quit
[FW-gateway] quit