思维导图

01

加密学的应用

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

数字信封：结合对称和非对称加密，从而保证数据传输的机密性。

数字签名：采用散列算法，从而保证数据传输的完整性。

数字证书：通过第三方机构（CA）对公钥进行公证，从而保证数据传输的不可否认性。

结合到实际的网络应用场景，数字信封、数字签名和数字证书可以用于以下场景：VPN、IPv6、HTTPS登录设备、设备系统登录授权

在各种应用场景中，其中最主要的应用场景就是在VPN上的应用。本课程主要介绍几种加密VPN及一些其他常用的VPN技术。

02

VPN产生背景

在VPN（Virtual Private Network）出现之前，跨越Internet的数据传输只能依靠现有物理网络，具有很多的不安全因素。

如下图所示，某企业的总部和分支机构位于不同区域（如位于不同的国家或城市），当分支机构员工需访问总部服务器的时候，数据传输要经过Internet。由于Internet中存在多种不安全因素，则当分支机构的员工向总部服务器发送访问请求时，报文容易被网络中的黑客窃取或篡改，最终造成数据泄密、重要数据被破坏等后果。

03

VPN定义与封装原理

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

VPN的基本原理是利用隧道（Tunnel）技术，对传输报文进行封装，利用VPN骨干网建立专用数据传输通道，实现报文的安全传输。

VPN具有以下两个基本特征：专用（Private）、虚拟（Virtual）

VPN对数据进行封装和加密，即使网络黑客窃取到数据也无法破解，确保了数据的安全性，且搭建VPN不需改变现有网络拓扑，没有额外费用。

VPN和传统的数据专网相比具有如下优势：安全、廉价、支持移动业务、可扩展性、VPN在保证网络的安全性、可靠性、可管理性的同时提供更强的扩展性和灵活性。

04

VPN分类

VPN现在广泛应用于企业网络分支机构和出差员工连接总部网络的场景，以下是VPN常见的几种分类方式。

根据应用场景不同分类：

Client-to-Site VPN：即客户端与企业内网之间通过VPN隧道建立连接，客户端可以是一台防火墙、路由器，也可以是个人计算机。此场景可以使用以下几种VPN技术实现：SSL、IPSec、L2TP和L2TP over IPSec；又称为Remote Access VPNSite-to-Site VPN：即两个局域网之间通过VPN隧道建立连接，部署的设备通常为路由器或者防火墙。此场景可以使用以下几种VPN技术实现：IPSec、L2TP、L2TP over IPSec、GRE over IPSec和IPSec over GRE。

根据应用对象不同分类：

Extranet VPN： 利用VPN将企业网延伸至合作伙伴处，使不同企业间通过Internet来构筑VPN；Intranet VPN：通过公用网络进行企业内部各个网络的互连；Access VPN：面向出差员工，允许出差员工跨越公用网络远程接入公司内部网络。

根据VPN技术实现的网络层次分类：应用层SSL VPN、网络层GRE IPSec L3VPN、数据链路层PPTP L2F L2TP L2VPN

05

VPN的关键技术

隧道技术：

VPN的基本原理是利用隧道（Tunnel）技术，对传输报文进行封装，利用VPN骨干网建立专用数据传输通道，实现报文的安全传输。

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

隧道技术是VPN的基本技术，类似于点对点连接技术。如图所示，分支VPN网关收到原始报文后，将报文封装，然后通过Internet传输到总部VPN网关。总部VPN网关再对报文进行解封装，最后得到原始报文。

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

身份认证技术：

身份认证技术，其主要用于移动办公用户远程接入的情况。总部的VPN网关对用户的身份进行认证，确保接入内部网络的用户是合法用户，而非恶意用户。不同的VPN技术能提供的用户身份认证方法不同：

GRE：不支持针对用户的身份认证技术；L2TP：依赖PPP提供的认证。IPSec：使用IKEv2时，支持对用户进行EAP认证。SSL VPN：对接入用户进行认证时，支持本地认证、证书认证和服务器认证

加密技术：

加密技术就是把明文加密成密文的过程，这样即便黑客截获了报文也无法知道其真实含义。加密对象有数据报文和协议报文之分，能够实现协议报文和数据报文都加密的协议安全系数更高。

GRE和L2TP协议本身不提供加密技术，所以通常结合IPSec协议一起使用，依赖IPSec的加密技术。

IPSec：支持对数据报文和协议报文进行加密。

SSL VPN：支持对数据报文和协议报文加密。

数据验证技术：

数据验证技术就是对报文的真伪进行检查，丢弃伪造的、被篡改的报文。那么验证是如何实现的呢？它采用一种称为“摘要”的技术。

“摘要”技术主要采用Hash函数将一段长的报文通过函数变换，映射为一段短的报文。在收发两端都对报文进行验证，只有摘要一致的报文才被接受。

VPN技术对比

06

GRE VPN

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

异种报文传输的通道称为Tunnel（隧道）。通常通过在IPv4网络上建立GRE隧道，解决两个IPv6网络的通信问题。

07

GRE协议栈

网络封装技术，其基本的构成要素都可以分为三个部分：乘客协议、封装协议、传输协议。GRE也不例外，为了方便理解，我们用邮政系统打个比方：

乘客协议就是我们自己写的信，信的语言可以是汉语、英语、法语等，具体的内容由写信人、读信人自己负责；封装协议可以理解为信封，可以是平信、挂号或者EMS，不同的信封就对应于多种封装协议；运输协议就是信的运输方式，可以是陆运、海运或者空运，不同的运输方式就对应于多种运输协议。

GRE封装报文时，封装前的报文称为净荷，封装前的报文协议称为乘客协议，然后GRE会封装GRE头部，GRE成为封装协议，也叫运载协议，最后负责对封装后的报文进行转发的协议称为传输协议。

08

GRE封装

GRE是按照协议栈对报文进行逐层封装。封装过程可以分成两步：

第一步是为原始报文添加GRE头；第二步是在GRE头前面再加上新的IP头。

GRE的封装操作是通过逻辑接口Tunnel完成的，Tunnel接口是一个通用的隧道接口，所以GRE协议在使用这个接口的时候，会将接口的封装协议设置为GRE协议。

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

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

09

GRE报文处理过程

PC_A通过GRE隧道访问PC_B时，防火墙A和防火墙B上的报文转发过程如下：

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。

010

GRE安全策略

PC_A发出的原始报文进入Tunnel接口这个过程中，报文经过的安全域间是Trust > DMZ；原始报文被GRE封装后，防火墙A在转发这个报文时，报文经过的安全域间是Local > Untrust。

当报文到达防火墙B时，防火墙B会进行解封装。在此过程中，报文经过的安全域间是Untrust > Local；GRE报文被解封装后，防火墙B在转发原始报文时，报文经过的安全域间是DMZ > Trust。

011

IPSec VPN

IPSec（IP Security）协议族是IETF制定的一系列安全协议，它为端到端IP报文交互提供了基于密码学的、可互操作的、高质量的安全保护机制。IPSec VPN是利用IPSec隧道建立的网络层VPN。

IPSec通过加密与验证等方式，从以下几个方面保障了用户业务数据在Internet中的安全传输：

数据来源验证：接收方验证发送方身份是否合法；数据加密：发送方对数据进行加密，以密文的形式在Internet上传送，接收方对接收的加密数据进行解密后处理或直接转发；数据完整性：接收方对接收的数据进行验证，以判定报文是否被篡改；抗重放：接收方拒绝旧的或重复的数据包，防止恶意用户通过重复发送捕获到的数据包所进行的攻击。

012

IPSec VPN体系结构

IPSec VPN体系结构主要由AH、ESP和IKE协议套件组成。具体介绍如下：

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

013

IPSec协议体系

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

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

AH和ESP协议提供的安全功能依赖于协议采用的验证、加密算法。

IPSec加密和验证算法所使用的密钥可以手工配置，也可以通过因特网密钥交换IKE（Internet Key Exchange）协议动态协商。本课程主要讲解手工方式的IPSec隧道建立。

014

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协议规范。

015

封装模式

传输模式：在传输模式中，AH头或ESP头被插入到IP头与传输层协议头之间，保护TCP/UDP/ICMP负载。以TCP报文为例，原始报文经过传输模式封装后，报文格式如图所示。

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

隧道模式：在隧道模式下，AH头或ESP头被插到原始IP头之前，另外生成一个新的报文头放到AH头或ESP头之前，保护IP头和负载。以TCP报文为例，原始报文经隧道模式封装后的报文结构如图所示。

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

传输模式和隧道模式的区别在于：

从安全性来讲，隧道模式优于传输模式，它可以完全地对原始IP数据报进行验证和加密，隐藏内部IP地址、协议类型和端口；从性能来讲，隧道模式因为有一个额外的IP头，所以它将比传输模式占用更多带宽。

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

016

IPSec数据加密及认证

IPSec提供了两种安全机制：加密和认证。

IPSec采用对称加密算法对数据进行加密和解密。数据发送方和接收方使用相同的密钥进行加密和解密；IPSec采用HMAC（Hash-based Message Authentication Code）功能，比较数字签名进行数据完整性和真实性认证。

ICV(Integrity Check Value)用于接收方进行完整性校验。可选择的认证算法有MD5、SHA1、SHA2、SM3。

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（Senior Middle 3）。其中，MD5、SHA1算法安全性低，存在安全风险，不推荐使用。

IPSec的加密功能，无法验证解密后的信息是否是原始发送的信息或完整。IPSec采用HMAC（Hash-based Message Authentication Code）功能，比较数字签名进行数据包完整性和真实性验证。通常情况下，加密和验证通常配合使用。

如图所示，在IPSec发送方侧，加密后的报文通过验证算法和对称密钥生成完整性校验值ICV，将IP报文和完整性校验值ICV同时发给对端；在IPSec接收方侧，使用相同的验证算法和对称密钥对加密报文进行处理，同样得到完整性校验值ICV，然后比较完整性校验值ICV，进行数据完整性和真实性验证，验证不通过的报文直接丢弃，验证通过的报文再进行解密。

017

IKE与AH/ESP之间关系

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

IKE协议有IKEv1和IKEv2两个版本。

018

IKE的交换阶段

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

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

IKE使用了两个阶段的ISAKMP。第一阶段建立IKE安全联盟（IKE SA），第二阶段利用这个既定的安全联盟，为IPSec协商具体的安全联盟。

IKE的工作流程如下：

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

019

IPSec SA

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

建立IPSec SA一般有两种方式：手工方式和IKE方式。

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

建立IPSec SA一般有两种方式：

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

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

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

020

IKE SA

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

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

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协议。

021

IKEv1第一阶段协商

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

IKE交换阶段第一阶段——主模式交换

主模式被设计成将密钥交换信息与身份认证信息相分离的一种交换技术。这种分离保证了身份信息在传输过程中的安全性，这是因为交换的身份信息受到了加密保护；主模式总共需要经过三个步骤共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是响应方对发起方的认证。

IKE交换阶段第一阶段——野蛮模式交换

从上述主模式协商的叙述中可以看到，在第二次交换之后便可生成会话密钥，会话密钥的生成材料中包含了预共享密钥。而当一个对等体同时与多个对等体进行协商SA时，则需要为每个对等体设置一个预共享密钥。为了对每个对等体正确地选择对应的预共享密钥，主模式需要根据前面交换信息中的IP地址来区分不同的对等体；但是当发起者的IP地址是动态分配获得时，由于发起者的IP地址不可能被响应者提前知道，而且双方都打算采用预共享密钥验证方法，此时响应者就无法根据IP地址选择对应的预共享密钥。野蛮模式就是被用于解决这个矛盾的；与主模式不同，野蛮模式仅用3条信息便完成了IKE SA的建立。由于对消息数进行了限制，野蛮模式同时也限制了它的协商能力，而且不会提供身份保护；在野蛮模式的协商过程中，发起者会提供一个保护套件列表、Diffie-Hellman公共值、nonce以及身份资料。所有这些信息都是随第一条信息进行交换的。作为响应者，则需要回应选择一个保护套件、Diffie-Hellman公共值、nonce、身份资料以及一个验证载荷。发起者将它的验证载荷在最后一条消息交换；野蛮模式由于在其第一条信息中就携带了身份信息，因此本身无法对身份信息进行加密保护，这就降低了协商的安全性，但也因此不依赖IP地址标识身份，在野蛮模式下也就有了更多灵活的应用。

IKEv1主模式和野蛮模式区别

交换的消息：主模式为6个；野蛮模式为3个。

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

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

022

IKEv1第二阶段协商

快速模式协商过程

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

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

IKE交换阶段第二阶段——快速模式交换

建立好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定义了三种交换：初始交换（Initial Exchanges）、创建子SA交换（Create_Child_SA Exchange）以及通知交换（Informational Exchange）。

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

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

初始交换过程：

消息①和②属于第一次交换（称为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来保护进行。

023

L2TP VPN

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

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

L2TP VPN主要有三种使用场景：

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

024

Client-Initiated场景中的L2TP VPN原理

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

隧道协商：移动办公用户在访问企业总部服务器之前，需要先通过L2TP VPN软件与LNS建立L2TP VPN隧道。下图所示是移动办公用户与LNS协商建立L2TP VPN隧道，直至最后成功访问企业内网资源的完整过程。

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

L2TP Client发往内网服务器的报文的转发过程如下：

L2TP Client将原始报文用PPP头、L2TP头、UDP头、外层公网IP头层层封装，成为L2TP报文；L2TP 报文穿过Internet到达LNS；LNS收到报文后，在L2TP模块中完成了身份认证和报文的解封装，去掉PPP头、L2TP头、UDP头、外层公网IP头，还原成原始报文；原始报文只携带了内层私网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连接总部内网接口所在的安全区域。

025

SSL VPN

IPSec、L2TP等早期出现的VPN技术虽然可以支持远程接入这个应用场景，但这些VPN技术存在以下问题：移动办公用户需要安装指定的客户端软件；网络部署和维护都比较麻烦；无法对移动办公用户的访问权限做精细化控制。

SSL VPN作为新型的轻量级远程接入方案，可以有效地解决上述问题。SSL VPN是通过SSL协议实现远程安全接入的VPN技术，保证移动办公用户能够在企业外部安全、高效地访问企业内部的网络资源。

SSL VPN主要应用场景：企业出差员工

如上图所示，防火墙作为企业出口网关连接至Internet，并向移动办公用户（即出差员工）提供SSL VPN接入服务。移动办公用户使用终端（如便携机、PAD或智能手机）与防火墙建立SSL VPN隧道以后，就能通过SSL VPN隧道远程访问企业内网的Web服务器、文件服务器、邮件服务器等资源。

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

026

SSL VPN虚拟网关

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

移动办公用户登录SSL VPN虚拟网关并访问企业内网资源的过程如下：

用户登录：移动办公用户在浏览器中输入SSL VPN虚拟网关的IP地址或域名，请求建立SSL连接。虚拟网关向远程用户发送自己的证书，远程用户对虚拟网关的证书进行身份认证。认证通过后，远程用户与虚拟网关成功建立SSL连接，进入SSL VPN虚拟网关的登录页面；用户认证：在登录页面输入用户名、密码后，虚拟网关将对该用户进行身份认证。角色授权：用户身份认证通过后，虚拟网关会查询该用户所属的角色信息，然后再将该角色所拥有的资源链接推送给用户。资源访问：用户点击虚拟网关资源列表中的链接就可以访问对应资源。

027

SSL VPN业务

Web代理业务

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

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

Web代理业务交互流程：

远程用户通过域名（）来访问虚拟网关；登录虚拟网关成功后，远程用户会在虚拟网关中看到自己有权访问的Web资源列表，然后单击要访问的资源链接。防火墙在将内网资源（）呈现给远程用户时，会改写该资源的URL。远程用户点击资源链接后，发送给防火墙的HTTPS链接请求就是虚拟网关改写以后的URL，改写后的URL实质上是由和这两个URL拼接而成；防火墙收到上述URL后，会向Web Server重新发起一个HTTP请求，这个HTTP请求就是Web资源实际的URL（）；Web Server以HTTP方式向防火墙返回资源页面；虚拟网关将Web Server返回的资源页面，再经过HTTPS方式转发给远程用户。

Web改写：Web改写中的“改写”包含两层含义。第一层含义是加密，即远程用户在点击虚拟网关资源列表中的链接时，虚拟网关会将用户要访问的真实URL进行加密。第二层含义是适配。

Web link：Web Link不会进行加密和适配，只做单纯转发远程用户的Web资源请求。

文件共享业务

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

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

在文件共享业务中防火墙起到了协议转换器的作用，以访问内网Windows文件服务器为例，具体实现过程如图所示。

端口转发业务

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

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

网络扩展业务

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

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

远程用户通过Web浏览器登录虚拟网关。成功登录虚拟网关后启动网络扩展功能。启动网络扩展功能，会触发以下几个动作：

远程用户与虚拟网关之间会建立一条SSL VPN隧道；远程用户本地PC会自动生成一个虚拟网卡。虚拟网关从地址池中随机选择一个IP地址，分配给远程用户的虚拟网卡，该地址作为远程用户与企业内网Server之间通信之用。有了该私网IP地址，远程用户就如同企业内网用户一样可以方便访问内网IP资源；虚拟网关向远程用户下发到达企业内网服务器的路由信息。虚拟网关会根据网络扩展业务中的配置，向远程用户下发不同的路由信息。

远程用户向企业内网的服务器发送业务请求报文，该报文通过SSL VPN隧道到达虚拟网关。

虚拟网关收到报文后进行解封装，并将解封装后的业务请求报文发送给内网服务器。

内网服务器响应远程用户的业务请求。

响应报文到达虚拟网关后进入SSL VPN隧道。

028

VPN配置

IPSec VPN配置举例

需求描述：

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

配置思路：

完成接口基本配置；配置安全策略，允许私网指定网段进行报文交互；配置到对端内网的路由；配置IPSec策略，包括配置IPSec策略的基本信息、配置待加密的数据流、配置安全提议的协商参数。

定义被保护的数据流。

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

[FW_A] acl 3000[FW_A-acl-adv-3000]rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.00.0.0.255 [FW_A-acl-adv-3000] quit

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

[FW_B] acl 3000[FW_B-acl-adv-3000]rule 5 permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.00.0.0.255 [FW_B-acl-adv-3000] quit

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

[FW_A] IPSecproposal tran1[FW_A-IPSec-proposal-tran1]esp authentication-algorithm sha2-256[FW_A-IPSec-proposal-tran1]esp encryption-algorithm aes-256[FW_A-IPSec-proposal-tran1]quit

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

[FW_A] ike proposal10[FW_A-ike-proposal-10]authentication-method pre-share[FW_A-ike-proposal-10]prf hmac-sha2-256[FW_A-ike-proposal-10]encryption-algorithm aes-256[FW_A-ike-proposal-10]dh group14[FW_A-ike-proposal-10]integrity-algorithm hmac-sha2-256[FW_A-ike-proposal-10]quit

配置IKE peer

[FW_A] ike peer b[FW_A-ike-peer-b]ike-proposal 10[FW_A-ike-peer-b]remote-address 1.1.5.1[FW_A-ike-peer-b]pre-shared-key Test!1234[FW_A-ike-peer-b]quit[FW_B] ike peer a[FW_B-ike-peer-a]ike-proposal 10[FW_B-ike-peer-a]remote-address 1.1.3.1[FW_B-ike-peer-a]pre-shared-key Test!1234[FW_B-ike-peer-a]quit

配置IPSec策略

[FW_A] IPSec policymap1 10 isakmp[FW_A-IPSec-policy-isakmp-map1-10]security acl 3000[FW_A-IPSec-policy-isakmp-map1-10]proposal tran1[FW_A-IPSec-policy-isakmp-map1-10]ike-peer b[FW_A-IPSec-policy-isakmp-map1-10]quit[FW_B] IPSec policymap1 10 isakmp[FW_B-IPSec-policy-isakmp-map1-10]security acl 3000[FW_B-IPSec-policy-isakmp-map1-10]proposal tran1[FW_B-IPSec-policy-isakmp-map1-10]ike-peer a[FW_B-IPSec-policy-isakmp-map1-10]quit

引用IPSec策略。

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

[FW_A]interface GigabitEthernet 0/0/1[FW_A-GigabitEthernet0/0/1]IPSec policy map1[FW_A-GigabitEthernet0/0/1]quit

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

[FW_B] interfaceGigabitEthernet 0/0/1[FW_B-GigabitEthernet0/0/1]IPSec policy map1[FW_B-GigabitEthernet0/0/1]quit

SSL VPN配置举例

需求描述：

企业网络如图所示，企业希望移动办公用户通过Web代理访问企业Web服务器（Web Link）;企业使用防火墙的本地认证对各部门的员工进行用户认证，通过认证的用户能够获得接入企业内部网络的权限。

配置思路：

完成接口基本配置；配置用户和认证：配置认证域，创建用户组和用户；配置SSL VPN虚拟网关；配置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-gatewaygateway interface GigabitEthernet 0/0/1 private[FW] v-gatewaygateway udp-port 443[FW] v-gatewaygateway authentication-domain default

配置SSL协议的版本、加密套件、会话超时时间和生命周期。可直接使用默认值。选择“Web代理”业务，单击“下一步”。

命令行配置如下：

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

配置Web代理。选择“Web代理资源列表> 新建”，按如下配置新建Web代理资源。

命令行配置如下：

[FW-gateway-service]web-proxy link-resource Web-Server  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