419 lines
21 KiB
Markdown
419 lines
21 KiB
Markdown
**号主：老杨丨11年资深网络工程师，更多网工提升干货，请关注公众号：网络工程师俱乐部**
|
||
|
||
|
||
|
||
上午好，我的网工朋友
|
||
|
||
企业分支之间经常有互联的需求，企业互联的方式很多，可以使用专线线路或者Internet线路。
|
||
部分企业从成本和需求出发会选择使用Internet线路进行互联，但是使用Internet线路存在安全风险，如何保障数据在传输时不会被窃取？
|
||
|
||
有的朋友会说[GRE](https://zhida.zhihu.com/search?content_id=252529020&content_type=Article&match_order=1&q=GRE&zhida_source=entity)，但**是在GRE隧道中不会对报文进行加密因此通过抓包是可以看到数据的报文信息，那怎么确保信息数据的安全呢？**
|
||
|
||
这就要提到今天要讲的**[IPSec](https://zhida.zhihu.com/search?content_id=252529020&content_type=Article&match_order=1&q=IPSec&zhida_source=entity) VPN**了，一起来看看IPSec VPN是如何运作并确保信息安全的。
|
||
|
||
|
||
|
||
**今日文章阅读福利：****《 VPN技术思维导图 》**
|
||
|
||
****既然讲到VPN相关，另外再分析一份VPN相关的好资源给你，私信我，发送暗号**“VPN”**，即可获取技术之路一把好武器。****
|
||
|
||
|
||
|
||
# **01** **IPSec基本概念**
|
||
|
||
IPsec（IP Security）协议族是IETF制定的一系列安全协议，**它为端到端IP报文交互提供了基于密码学的、可互操作的、高质量的安全保护机制。**
|
||
|
||
通过对数据加密、认证，IPsec使得数据能够在Internet网络上安全的传输。**IPsec VPN技术可以和多种VPN技术结合使用，使得企业互联更加灵活安全。**
|
||
|
||
|
||
|
||
IPSec隧道
|
||
|
||
|
||
|
||
|
||
|
||
GRE Over IPSec
|
||
|
||
**IPSec不是一个单独的协议，它给出了IP网络上数据安全的一整套体系结构**，包括[AH](https://zhida.zhihu.com/search?content_id=252529020&content_type=Article&match_order=1&q=AH&zhida_source=entity)、[ESP](https://zhida.zhihu.com/search?content_id=252529020&content_type=Article&match_order=1&q=ESP&zhida_source=entity)、[IKE](https://zhida.zhihu.com/search?content_id=252529020&content_type=Article&match_order=1&q=IKE&zhida_source=entity)等协议。
|
||
|
||
|
||
|
||
|
||
|
||
**IPSec体系结构**
|
||
|
||
IPSec通过加密与验证等方式，从以下几个方面保障了用户业务数据在Internet中的安全传输:
|
||
|
||
- **数据来源验证:**接收方验证发送方身份是否合法:
|
||
|
||
|
||
- **数据加密:**发送方对数据进行加密，以密文的形式在nternet上传送，接收方对接收的加密数据进行解密后处理或直接转发;
|
||
|
||
|
||
- **数据完整性:**接收方对接收的数据进行验证，以判定报文是否被改;
|
||
|
||
|
||
- **抗重放:**接收方拒绝旧的或重复的数据包，防止恶意用户通过重复发送捕获到的数据包所进行的攻击。
|
||
|
||
|
||
|
||
|
||
****01 数据加密****
|
||
|
||
**数据加密可以避免数据转发时被读取。数据加密一般有两种方案：**
|
||
|
||
- **对称加密：**使用同一个密码加密/解密，效率很高，但是对称加密在互相交互密钥时存在密钥被截取的风险。
|
||
|
||
- **非对称加密：**使用公钥加密，私钥解密，安全性很高但是加解密效率很低。
|
||
|
||
|
||
|
||
|
||
****02 数据认证****
|
||
|
||
**数据认证的主要目的是确认数据是否被篡改，数据认证主要基于Hash算法。**
|
||
|
||
- 数据通过Hash算法计算出一个唯一的Hash值，Hash值携带在数据中转发给对端。
|
||
|
||
|
||
- 对端设备对数据重新进行Hash，得出Hash值。将收到的Hash值与计算出的Hash值进行比对，一致说明没有被篡改。
|
||
|
||
|
||
|
||
|
||
数据认证方式简介
|
||
|
||
|
||
|
||
IPsec提供了两种安全机制：**加密和认证**。
|
||
|
||
- IPsec采用对称加密算法对数据进行加密和解密。数据发送方和接收方使用相同的密钥进行加密、解密。
|
||
|
||
- IPsec采用HMAC（Hash-based Message Authentication Code）功能，比较数字签名进行数据完整性和真实性认证。
|
||
|
||
|
||
|
||
|
||
****03 IPsec加密基本思路****
|
||
|
||
IPsec同时使用对称加密与非对称加密，保证了安全也兼顾了性能。
|
||
|
||
- 将对称加密所用的密钥，使用非对称算法加密并传递。
|
||
|
||
- 数据通过交互后的对称密钥加密。
|
||
|
||
|
||
|
||
|
||
IPsec加密基本思路
|
||
|
||
|
||
|
||
简单说就是双方通过使用非对称加密算法对同一密码进行加密得到一个对称秘钥，**然后使用该对称秘钥对数据进行加密**。一个前提就是密码是双方知道的，一般还是通过口头告知、文档等形式获取。
|
||
|
||
|
||
|
||
****04 安全联盟介绍****
|
||
|
||
SA（Security Association，安全联盟） 可以帮助IPsec对特定要素进行约定，比如：**加密算法使用DES，认证算法使用MD5，封装方式使用Tunnel等。**
|
||
|
||
IPsec技术在数据加密，数据验证，数据封装等方面有多种实现方式或算法，**两端的设备使用IPsec进行通信时需要保证一致的加密算法，验证算法等**。因此需要一种机制帮助两端设备协商这些参数。
|
||
|
||
**建立IPsec SA一般有两种方式：**
|
||
|
||
- **手工方式：**手工方式建立IPsec SA管理成本很高，加密验证方式需要手工配置，手工刷新SA，且SA信息永久存在安全性较低，适用于小型网络。
|
||
|
||
- **IKE方式：**IKE方式建立IPsec SA管理成本比较低，加密验证方式通过DH算法生成，SA信息有生成周期，且SA动态刷新，适用于小型，中大型网络。
|
||
|
||
|
||
IKE SA的主要作用是**构建一条安全的通道，用于交互IPsec SA。**
|
||
|
||
IPsec SA，由一个三元组来唯一标识，这个三元组包括安全参数索引SPI、目的IP地址和使用的安全协议号（AH或ESP）。
|
||
|
||
前面我们说到了IPSec框架中涉及到数据加密和认证，而实际情况下加密算法和认证算法很多，而IPSec中必须保证两端算法一致才能协商成功，那怎么协商呢？就是**通过SA来定义，通过在SA中指定加密算法、认证算法、封装模式、传输层协议等内容。**
|
||
|
||
而在IPSec中有两个阶段：**IKE阶段和IPSec阶段，两个是承上启下的作用。**
|
||
|
||
|
||
|
||
****05 密钥交换介绍****
|
||
|
||
**IPSec需要交互一个双方认可的对称秘钥，那怎么交互呢？**
|
||
|
||
**现网中交互对称密钥一般会使用密钥分发协议：IKE（Internet Key Exchange，因特网密钥交换）。**
|
||
|
||
IKE协议建立在[ISAKMP](https://zhida.zhihu.com/search?content_id=252529020&content_type=Article&match_order=1&q=ISAKMP&zhida_source=entity)（安全联盟和密钥管理协议）定义的框架上，是基于UDP的应用层协议。
|
||
|
||
**它为IPsec提供了自动协商密钥、建立IPsec安全联盟的服务，能够简化IPsec的配置和维护工作。**
|
||
|
||
|
||
|
||
密钥交换介绍
|
||
|
||
|
||
|
||
**IKE支持的认证算法有：**MD5、SHA1、SHA2-256、SHA2-384、SHA2-512、SM3。
|
||
|
||
**I****KE支持的加密算法有：**DES、3DES、AES-128、AES-192、AES-256、SM1和SM4。
|
||
|
||
ISAKMP由RFC2408定义，定义了**协商、建立、修改和删除SA的过程和包格式。**ISAKMP只是为SA的属性和协商、修改、删除SA的方法提供了一个通用的框架，并没有定义具体的SA格式。 **ISAKMP报文可以利用UDP或者TCP，端口都是500，一般情况下常用UDP协议，所以在防火墙上放通IPSec的流量可以允许UDP 500/4500端口的流量通过。**
|
||
|
||
|
||
|
||
****06 安全协议介绍****
|
||
|
||
IPSec的加密与解密大致是在原有的报文头部增加一层或多层头部以实现加密，在传输层中
|
||
|
||
IPsec有两种传输层协议提供认证或加密服务：**AH（认证头），ESP（封装安全载荷）。**
|
||
|
||
- AH仅支持认证功能，不支持加密功能。
|
||
|
||
- ESP支持认证和加密功能。
|
||
|
||
|
||
AH仅支持认证功能，不支持加密功能。AH在每一个数据包的标准IP报头后面添加一个AH报文头。AH对数据包和认证密钥进行Hash计算，接收方收到带有计算结果的数据包后，执行同样的Hash计算并与原计算结果比较，传输过程中对数据的任何更改将使计算结果无效，这样就提供了数据来源认证和数据完整性校验。**AH协议的完整性验证范围为整个IP报文。**
|
||
|
||
ESP支持认证和加密功能。 **ESP在每一个数据包的标准IP报头后面添加一个ESP报文头，并在数据包后面追加一个ESP尾（ESP Trailer和ESP Auth data）。**
|
||
|
||
与AH不同的是，ESP将数据中的有效载荷进行加密后再封装到数据包中，以保证数据的机密性，但ESP没有对IP头的内容进行保护，除非IP头被封装在ESP内部（采用隧道模式）。
|
||
|
||
**关键字段含义：**
|
||
|
||
- **Sequence Number：**是一个从1开始的单项递增的计数器，唯一地标识每一个数据包，用于防止重放攻击。
|
||
|
||
- **SPI：**IPsec安全参数索引，用于唯一标识IPsec安全联盟。
|
||
|
||
- **Authentication Data：**该字段包含数据完整性校验值 ICV（Integrity Check Value），用于接收方进行完整性校验。可选择的认证算法有MD5、SHA1、SHA2、SM3。
|
||
|
||
|
||
简单理解就是将内网源IP怎样进行再封装增加传输层报头，AH仅支持认证功能，**不支持加密功能，而ESP支持认证和加密功能,我一般情况下都是使用的ESP协议**。
|
||
|
||
|
||
|
||
ESP模式
|
||
|
||
|
||
|
||
|
||
|
||
AH模式
|
||
|
||
|
||
|
||
|
||
|
||
不同模式的报文抓包
|
||
|
||
###
|
||
|
||
****07 封装模式介绍****
|
||
|
||
在传输层使用安全协议还涉及到一个封装模式的问题。**封装模式是指将AH或ESP相关的字段插入到原始IP报文中，以实现对报文的认证和加密，封装模式有传输模式和隧道模式两种。**
|
||
|
||
现网中多使用隧道模式进行封装。就是说这个报文的字段摆放顺序是怎样的。
|
||
|
||
在传输模式中，AH头或ESP头被插入到IP头与传输层协议头之间，保护TCP/UDP/ICMP负载。**由于传输模式未添加额外的IP头，所以原始报文中的IP地址在加密后报文的IP头中可见。**
|
||
|
||
在隧道模式下，AH头或ESP头被插到原始IP头之前，另外生成一个新的报文头放到AH头或ESP头之前，保护IP头和负载。
|
||
|
||
**总结：**
|
||
|
||
**IPSec是一个框架，通过IPSec实现的VPN称为IPSec VPN。IPSec通过加密和认证来实现安全传输。****第一阶段首先需要协商秘钥一致**，通过秘钥交换IKE来协商，生成一个IKE的SA(安全联盟)，里面定义了加密算法、认证算法、隧道模式等。
|
||
|
||
**第二阶段使用一阶段的IKE SA进行加密数据**，可以选择AH或者ESP进行封装，AH不支持加密，ESP支持加密和认证，封装模式可以选择隧道模式或者传输模式，区别在于封装后数据包的头部不一样，一般情况下使用ESP安全协议以及隧道传输模式即可。
|
||
|
||
|
||
|
||
# **02** **IPSec VPN工作原理**
|
||
|
||
IPsec的基本工作流程如下：
|
||
|
||
- 通过IKE协商第一阶段协商出IKE SA。
|
||
|
||
- 使用IKE SA加密IKE协商第二阶段的报文，即IPsec SA。
|
||
|
||
- 使用IPsec SA加密数据。
|
||
|
||
|
||
|
||
|
||
IPsec基本工作流程
|
||
|
||
|
||
|
||
简单理解就是先创建一条安全协商的道路（IKE SA），然后通过IKE SA经过算法达到一个秘钥（IPSec SA）,接着使用IPSec SA对传输的流量进行加密与验证，这第三步就涉及到哪些流量需要加密，**我们需要通过一些方式将对应流量引入到IPSec VPN隧道中来进行传输。**
|
||
|
||
|
||
|
||
# **03** **IKE 协商**
|
||
|
||
前面我们学习了IPSec双方需要协商出一个SA来进行算法的匹配，一般情况下我们使用IKE方式建立IPsec SA。**IKE是建立在ISAKMP定义的框架上，是基于UDP的应用层协议**。
|
||
|
||
**它为IPsec提供了自动协商密钥、建立IPsec安全联盟的服务，能够简化IPsec的配置和维护工作。**
|
||
|
||
简单说就是我们通过IKE这个框架协商出双方认可的**加密算法、认证算法、传输模式等等**。
|
||
|
||
而IKE目前有两个版本：**[IKEv1](https://zhida.zhihu.com/search?content_id=252529020&content_type=Article&match_order=1&q=IKEv1&zhida_source=entity)和[IKEv2](https://zhida.zhihu.com/search?content_id=252529020&content_type=Article&match_order=1&q=IKEv2&zhida_source=entity)。**
|
||
|
||
|
||
|
||
****01 IKEv1****
|
||
|
||
采用IKEv1协商安全联盟主要分为两个阶段：
|
||
|
||
- **第一阶段：**通信双方协商并建立IKE协议本身使用的安全通道，即建立一个IKE SA；
|
||
|
||
|
||
- **第二阶段：**利用第一阶段已通过认证与安全保护的安全通道，建立一对用于数据安全传输的IPsec SA。
|
||
|
||
|
||
|
||
|
||
IKEv1
|
||
|
||
|
||
|
||
**IKEv1协商第一阶段介绍：**
|
||
|
||
IKEv1协商第一阶段的目的是建立IKE SA。**IKE SA建立后对等体间的所有ISAKMP消息都将通过加密和验证，这条安全通道可以保证IKEv1第二阶段的协商能够安全进行。**
|
||
|
||
IKEv1协商第一阶段支持两种协商模式：**主模式（Main Mode） 和野蛮模式（Aggressive Mode）。**
|
||
|
||
**主模式：**
|
||
|
||
**主模式包含三次双向交换，用到了六条ISAKMP信息，协商过程如图1所示。这三次交换分别是：**
|
||
|
||
- **消息①和②用于提议交换，发起方发送一个或多个IKE安全提议，响应方查找最先匹配的IKE安全提议，并将这个IKE安全提议回应给发起方。**匹配的原则为协商双方具有相同的加密算法、认证算法、认证方法和Diffie-Hellman组标识。
|
||
|
||
|
||
- 消息③和④用于**密钥信息交换**，双方交换Diffie-Hellman公共值和nonce值，用于IKE SA的认证和加密密钥在这个阶段产生。
|
||
|
||
|
||
- 消息⑤和⑥用于**身份和认证信息交换（双方使用生成的密钥发送信息）**，双方进行身份认证和对整个主模式交换内容的认证。
|
||
|
||
|
||
**野蛮模式：**
|
||
|
||
野蛮模式只用到**三条信息**，**前两条消息①和②用于协商IKE安全提议，交换Diffie-Hellman公共值、必需的辅助信息以及身份信息，并且消息②中还包括响应方发送身份信息供发起方认证，消息③用于响应方认证发起方。**
|
||
|
||
与主模式相比，野蛮模式**减少了交换信息的数目**，提高了协商的速度，但是没有对身份信息进行加密保护。
|
||
|
||
实际情况下如果双方都有公网IP使用主模式，如果一方是拨号网络使用野蛮模式，因为IP不固定，而且野蛮模式需要协商发起方主动向固定IP的一端发起，**野蛮模式安全性相对较低。**
|
||
|
||
**IKEv1协商第二阶段介绍：**
|
||
|
||
IKEv1协商第二阶段的目的是建立用来安全传输数据的IPsec SA，并为数据传输衍生出密钥。
|
||
|
||
第二阶段采用**快速模式（Quick Mode）**。该模式使用IKEv1协商第一阶段中生成的密钥对ISAKMP消息的完整性和身份进行验证，并对ISAKMP消息进行加密，故保证了交换的安全性。
|
||
|
||
|
||
|
||
快速模式协商过程
|
||
|
||
|
||
|
||
至此IKEv1就成功协商出了IKE SA和IPSec SA用于数据加密。
|
||
|
||
|
||
|
||
****02 IKEv2****
|
||
|
||
**IKEv2简化了IKEv1协商SA的过程。IKEv2通常使用2次交换共4条消息就可以完成一对IPsec SA的建立**，如果要求建立的IPsec SA大于一对时，每一对IPsec SA只需额外增加1次创建子SA交换，也就是2条消息就可以完成。
|
||
|
||
IKEv2定义了三种交换：**初始交换（Initial Exchanges）、创建子SA交换（Create_Child_SA Exchange）以及通知交换（Informational Exchange）**。
|
||
|
||
|
||
|
||
#### **1.初始交换**
|
||
|
||
IKEv2通过初始交换就可以完成第一对IPsec SA的协商建立。初始交换包含两次交换四条消息。
|
||
|
||
|
||
|
||
IKEv2初始交换介绍
|
||
|
||
|
||
|
||
**工作过程：**
|
||
|
||
- 消息①和②属于**第一次交换**（称为IKE_SA_INIT交换），**以明文方式完成IKE SA的参数协商，包括协商加密和验证算法，交换临时随机数和DH交换**。IKE_SA_INIT交换后生成一个共享密钥材料，通过这个共享密钥材料可以衍生出IPsec SA的所有密钥。
|
||
|
||
|
||
- 消息③和④属于**第二次交换**（称为IKE_AUTH交换），**以加密方式完成身份认证、对前两条信息的认证和IPsec SA的参数协商**。IKEv2支持RSA签名认证、预共享密钥认证以及扩展认证方法EAP（Extensible Authentication Protocol）。发起者通过在消息3中省去认证载荷来表明需要使用EAP认证。
|
||
|
||
|
||
就是如果是一条IPSec SA的建立只需要初始交换就可以完成，不需要用到子SA交换等等，更加简单快捷。
|
||
|
||
报文抓包如下：
|
||
|
||
只需要4个报文即可完成协商。
|
||
|
||
|
||
|
||
IKEv2是一次性把需要协商的数据都发送过去的模式。
|
||
|
||
|
||
|
||
IKEv2的初始交换中，**并没有直接区分为主模式（Main Mode）和野蛮模式（Aggressive Mode）这两种模式**，而是通过初始交换（Initial Exchanges）来完成类似于IKEv1中这两种模式的协商过程。
|
||
|
||
**在IKEv2中，初始交换包括IKE_SA_INIT交换和IKE_AUTH交换，这两个交换过程顺序完成后，可以建立一个IKEv2 SA和一对IPsec SA。**
|
||
|
||
**具体来说，IKEv2的初始交换配置如下：**
|
||
|
||
- **IKE_SA_INIT交换：**这个交换完成IKEv2 SA参数的协商以及密钥交换。它对应于IKEv1的主模式的第1、3个包，以及野蛮模式的第1、2个包。
|
||
|
||
|
||
- **IKE_AUTH交换：**这个交换完成通信对等体的身份认证以及IPsec SA的创建。它对应于IKEv1的主模式的第5、6个包，以及野蛮模式的第3个包。
|
||
|
||
|
||
**在IKEv2中，通过配置不同的认证方法和参数，可以实现类似于IKEv1中主模式和野蛮模式的功能。**例如，如果需要快速完成身份认证和密钥交换，可以使用类似于野蛮模式的配置，减少消息交换的数量。**如果需要更安全的身份认证过程，可以使用类似于主模式的配置，增加消息交换的数量以提供更强的安全性。**
|
||
|
||
|
||
|
||
#### **2.创建子SA交换介绍**
|
||
|
||
当一个IKE SA需要创建多对IPsec SA时，需要使用创建子SA交换来协商多于一对的IPsec SA。**创建子SA交换还可以用于IKE SA的重协商。**
|
||
|
||
创建子SA交换包含一个交换两条消息，对应IKEv1协商阶段2，交换的发起者可以是初始交换的协商发起方，也可以是初始交换的协商响应方。
|
||
|
||
|
||
|
||
创建子SA交换介绍
|
||
|
||
|
||
|
||
#### **3.IKEv2通知交换介绍**
|
||
|
||
运行IKE协商的两端有时会传递一些控制信息，例如错误信息或者通告信息，这些信息在IKEv2中是通过通知交换完成的。
|
||
|
||
通知交换必须在IKE SA保护下进行，也就是说通知交换只能发生在初始交换之后。**控制信息可能是IKE SA的，那么通知交换必须由该IKE SA来保护进行；也可能是某子SA的，那么该通知交换必须由生成该子SA的IKE SA来保护进行。**
|
||
|
||
|
||
|
||
IKEv2通知交换介绍
|
||
|
||
|
||
|
||
# **04** **定义IPsec被保护流**
|
||
|
||
**前面通过IKE已经协商出IPSec SA了，现在需要对分支间的数据进行保护，哪些流量需要进行加密保护呢？**我们需要通过一些方式来进行定义。
|
||
|
||
IPsec是基于定义的感兴趣流触发对特定数据的保护，可以通过以下两种方式定义：
|
||
|
||
- **ACL方式**，由ACL来指定要保护的数据流范围，筛选出需要进入IPsec隧道的报文。
|
||
|
||
- **路由方式**，通过IPsec虚拟隧道接口建立IPsec隧道，将所有路由到IPsec虚拟隧道接口的报文都进行IPsec保护。
|
||
|
||
|
||
ACL可以**更加精细控制源目地址、源目端口等流量，路由方式比较便捷**，但是**需要创建tunnel隧道接口方式**来实现，支持动态路由协议。
|
||
|
||
通过IKE协商出**IPSec SA秘钥**，通过ACL或者路由匹配到感兴趣流量，最后将IPSec策略应用到指定的接口就可以实现IPSec VPN了。
|
||
|
||
**总结：**
|
||
|
||
通过IKE协商SA，IKE分v1和v2，一般情况下我用的应该是v1，v2可以快速协商出SA，然后通过ACL或者路由定义感兴趣流量，**将IKE提议、IPSec提议、创建IPSec策略、应用到接口串联起来就可以实现IPSec VPN的应用了，其实就是理论比较复杂，实际配置不算太难。**
|
||
|
||
|
||
|
||
**整理：老杨丨11年资深网络工程师，更多网工提升干货，请关注公众号：网络工程师俱乐部** |