IPSec简介
起源
随着Internet的发展，越来越多的企业直接通过Internet进行互联，但由于IP协议未考虑安全性，而且Internet上有大量的不可靠用户和网络设备，所以用户业务数据要穿越这些未知网络，根本无法保证数据的安全性，数据易被伪造、篡改或窃取。因此，迫切需要一种兼容IP协议的通用的网络安全方案。
为了解决上述问题，IPSec（Internet Protocol Security）应运而生。IPSec是对IP的安全性补充，其工作在IP层，为IP网络通信提供透明的安全服务。
定义
IPSec是IETF（Internet Engineering Task Force）制定的一组开放的网络安全协议。它并不是一个单独的协议，而是一系列为IP网络提供安全性的协议和服务的集合，包括认证头AH（Authentication Header）和封装安全载荷ESP（Encapsulating Security Payload）两个安全协议、密钥交换和用于验证及加密的一些算法等。
通过这些协议，在两个设备之间建立一条IPSec隧道。数据通过IPSec隧道进行转发，实现保护数据的安全性。
受益
IPSec通过加密与验证等方式，从以下几个方面保障了用户业务数据在Internet中的安全传输：
数据来源验证：接收方验证发送方身份是否合法。
数据加密：发送方对数据进行加密，以密文的形式在Internet上传送，接收方对接收的加密数据进行解密后处理或直接转发。
数据完整性：接收方对接收的数据进行验证，以判定报文是否被篡改。
抗重放：接收方拒绝旧的或重复的数据包，防止恶意用户通过重复发送捕获到的数据包所进行的攻击。
PSec基本原理IPSec通过在IPSec对等体间建立双向安全联盟形成一个安全互通的IPSec隧道，并通过定义IPSec保护的数据流将要保护的数据引入该IPSec隧道，然后对流经IPSec隧道的数据通过安全协议进行加密和验证，进而实现在Internet上安全传输指定的数据。 IPSec安全联盟可以手工建立，也可以通过IKEv1或IKEv2协议自动协商建立。本文重点介绍如何定义IPSec保护的数据流、IKE自动协商建立安全联盟的过程。 - 定义IPSec保护的数据流
- IKEv1协商安全联盟的过程
- IKEv2协商安全联盟的过程
定义IPSec保护的数据流IPSec是基于定义的感兴趣流触发对特定数据的保护，至于什么样的数据是需要IPSec保护的，可以通过以下两种方式定义。其中IPSec感兴趣流即需要IPSec保护的数据流。ACL方式 手工方式和IKE自动协商方式建立的IPSec隧道是由ACL来指定要保护的数据流范围，筛选出需要进入IPSec隧道的报文，ACL规则允许（permit）的报文将被保护，未匹配任何permit规则的报文将不被保护。这种方式可以利用ACL的丰富配置功能，根据IP地址、端口、协议类型等对报文进行过滤进而灵活制定IPSec的保护方法。 路由方式 通过IPSec虚拟隧道接口建立IPSec隧道，将所有路由到IPSec虚拟隧道接口的报文都进行IPSec保护，根据该路由的目的地址确定哪些数据流需要IPSec保护。其中IPSec虚拟隧道接口是一种三层逻辑接口。 路由方式具有以下优点：
IKEv1协商安全联盟的过程
采用IKEv1协商安全联盟主要分为两个阶段：第一阶段，通信双方协商和建立IKE协议本身使用的安全通道，即建立一个IKE SA；第二阶段，利用第一阶段已通过认证和安全保护的安全通道，建立一对用于数据安全传输的IPSec安全联盟。 IKEv1协商阶段1IKEv1协商阶段1的目的是建立IKE SA。IKE SA建立后对等体间的所有ISAKMP消息都将通过加密和验证，这条安全通道可以保证IKEv1第二阶段的协商能够安全进行。 IKEv1协商阶段1支持两种协商模式：主模式（Main Mode）和野蛮模式（Aggressive Mode）。 主模式包含三次双向交换，用到了六条ISAKMP信息，协商过程如图4-9所示。这三次交换分别是：
野蛮模式只用到三条信息，前两条消息①和②用于协商IKE安全提议，交换Diffie-Hellman公共值、必需的辅助信息以及身份信息，并且消息②中还包括响应方发送身份信息供发起方认证，消息③用于响应方认证发起方。IKEv1协商阶段1的协商过程如图4-9所示。 图4-9 IKEv1协商阶段1的协商过程图
与主模式相比，野蛮模式减少了交换信息的数目，提高了协商的速度，但是没有对身份信息进行加密保护。
IKEv1协商阶段2IKEv1协商阶段2的目的就是建立用来安全传输数据的IPSec SA，并为数据传输衍生出密钥。这一阶段采用快速模式（Quick Mode）。该模式使用IKEv1协商阶段1中生成的密钥对ISAKMP消息的完整性和身份进行验证，并对ISAKMP消息进行加密，故保证了交换的安全性。IKEv1协商阶段2的协商过程如图4-10所示。 图4-10 IKEv1协商阶段2的协商过程图
IKEv1协商阶段2通过三条ISAKMP消息完成双方IPSec SA的建立： 协商发起方发送本端的安全参数和身份认证信息。 安全参数包括被保护的数据流和IPSec安全提议等需要协商的参数。身份认证信息包括第一阶段计算出的密钥和第二阶段产生的密钥材料等，可以再次认证对等体。 IPSec安全提议指IPSec协商过程中用到的安全协议、加密算法及认证算法等。 协商响应方发送确认的安全参数和身份认证信息并生成新的密钥。 IPSec SA数据传输需要的加密、验证密钥由第一阶段产生的密钥、SPI、协议等参数衍生得出，以保证每个IPSec SA都有自己独一无二的密钥。 如果启用PFS，则需要再次应用DH算法计算出一个共享密钥，然后参与上述计算，因此在参数协商时要为PFS协商DH密钥组。 - 发送方发送确认信息，确认与响应方可以通信，协商结束。
IKEv2协商安全联盟的过程
采用IKEv2协商安全联盟比IKEv1协商过程要简化的多。要建立一对IPSec SA，IKEv1需要经历两个阶段：“主模式＋快速模式”或者“野蛮模式＋快速模式”，前者至少需要交换9条消息，后者也至少需要6条消息。而IKEv2正常情况使用2次交换共4条消息就可以完成一对IPSec SA的建立，如果要求建立的IPSec SA大于一对时，每一对IPSec SA只需额外增加1次创建子SA交换，也就是2条消息就可以完成。 IKEv2定义了三种交换：初始交换（Initial Exchanges）、创建子SA交换（Create_Child_SA Exchange）以及通知交换（Informational Exchange）。 初始交换正常情况下，IKEv2通过初始交换就可以完成第一对IPSec SA的协商建立。IKEv2初始交换对应IKEv1的第一阶段，初始交换包含两次交换四条消息，如图4-11所示。 图4-11 初始交换过程图
消息①和②属于第一次交换（称为IKE_SA_INIT交换），以明文方式完成IKE SA的参数协商，包括协商加密和验证算法，交换临时随机数和DH交换。IKE_SA_INIT交换后生成一个共享密钥材料，通过这个共享密钥材料可以衍生出IPSec SA的所有密钥。 消息③和④属于第二次交换（称为IKE_AUTH交换），以加密方式完成身份认证、对前两条信息的认证和IPSec SA的参数协商。IKEv2支持RSA签名认证、预共享密钥认证以及扩展认证方法EAP（Extensible Authentication Protocol）。发起者通过在消息3中省去认证载荷来表明需要使用EAP认证。
创建子SA交换当一个IKE SA需要创建多对IPSec SA时，需要使用创建子SA交换来协商多于一对的IPSec SA。另外，创建子SA交换还可以用于IKE SA的重协商。 创建子SA交换包含一个交换两条消息，对应IKEv1协商阶段2，交换的发起者可以是初始交换的协商发起方，也可以是初始交换的协商响应方。创建子SA交换必须在初始交换完成后进行，交换消息由初始交换协商的密钥进行保护。 类似于IKEv1，如果启用PFS，创建子SA交换需要额外进行一次DH交换，生成新的密钥材料。生成密钥材料后，子SA的所有密钥都从这个密钥材料衍生出来。
通知交换运行IKE协商的两端有时会传递一些控制信息，例如错误信息或者通告信息，这些信息在IKEv2中是通过通知交换完成的，如图4-12所示。 通知交换必须在IKE SA保护下进行，也就是说通知交换只能发生在初始交换之后。控制信息可能是IKE SA的，那么通知交换必须由该IKE SA来保护进行；也可能是某子SA的，那么该通知交换必须由生成该子SA的IKE SA来保护进行。 图4-12 通知交换过程图
配置采用ACL方式建立IPSec隧道前置任务在采用ACL方式建立IPSec隧道之前，需完成以下任务：
配置流程采用ACL方式建立IPSec隧道配置流程如图4-22所示（使用IKE协议时以IKEv1为例）。 图4-22 采用ACL方式建立IPSec隧道配置流程
定义需要保护的数据流背景信息IPSec能够对一个或多个数据流进行安全保护，ACL方式建立IPSec隧道采用ACL来指定需要IPSec保护的数据流。实际应用中，首先需要通过配置ACL的规则定义数据流范围，然后在IPSec安全策略中引用该ACL，从而起到保护该数据流的作用。一个IPSec安全策略中只能引用一个ACL，因此：
ACL规则关键字的使用 在IPSec的应用中，ACL规则中的permit关键字表示与之匹配的流量需要被IPSec保护，而deny关键字则表示与之匹配的流量不需要被保护。一个ACL中可以配置多条规则，首个与数据流匹配上的规则决定了对该数据流的处理方式。 注意事项 IPSec隧道两端ACL规则定义的协议类型要一致。例如，一端使用IP协议，另一端也必须使用IP协议。 当IPSec隧道两端的ACL规则镜像配置时，任意一方发起协商都能保证SA成功建立；当IPSec隧道两端的ACL规则非镜像配置时，只有发起方的ACL规则定义的范围是响应方的子集时，SA才能成功建立。因此，建议IPSec隧道两端配置的ACL规则互为镜像，即一端配置的ACL规则的源地址和目的地址分别为另一端配置的ACL规则的目的地址和源地址。具体来说： 若两端都配置ISAKMP方式IPSec安全策略，ACL规则必须互为镜像。若一端配置ISAKMP方式IPSec安全策略，另一端配置策略模板方式IPSec安全策略，ISAKMP方式IPSec安全策略的ACL规则的范围可以小于策略模板方式IPSec安全策略的ACL规则，取双方ACL规则交集作为协商结果。 ACL中各条rule的地址段要避免出现重叠。因为地址段重叠的rule之间容易相互影响，造成数据流匹配rule规则时出现误匹配的情况。 同一个IPSec安全策略组中配置的ACL不能包含相同的rule规则。 同一个IPSec安全策略组中所有IPSec安全策略引用的ACL的rule之间不能存在交集。例如引用的ACL3001和ACL3002存在交集： acl number 3001 rule 5 permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255acl number 3002 rule 5 permit ip source 10.1.0.0 0.0.255.255 destination 10.1.0.0 0.0.255.255协商响应方采用策略模板方式IPSec安全策略时： 响应方可不定义需要保护的数据流，此时表示接受发起方定义的需要保护的数据流范围；如果响应方要指定需要保护的数据流，则需要与发起方镜像配置或者包含发起方指定的保护的数据流范围。 IPSec隧道建立成功后，在安全策略模板视图下，ACL规则同时配置为Permit和Deny时，规则为Deny的功能不生效。 如果应用IPSec安全策略的接口同时配置了NAT，由于设备先执行NAT，会导致IPSec不生效，此时需要：
操作步骤- 执行命令system-view，进入系统视图。
- 执行命令acl [ number ] acl-number [ match-order { config | auto } ]，创建一个高级ACL（acl-number为3000～3999）并进入其视图。
- 根据实际需求，任意选择如下配置之一：
- 执行命令rule [ rule-id ] { deny | permit } ip [ destination { destination-address destination-wildcard | any } | source { source-address source-wildcard | any } | dscp dscp | vpn-instance vpn-instance-name ] *，在ACL视图下配置针对IP协议的ACL规则。
- 执行命令rule [ rule-id ] { deny | permit } tcp [ destination { destination-address destination-wildcard | any } | destination-port eq port | source { source-address source-wildcard | any } | source-port eq port | dscp dscp | vpn-instance vpn-instance-name ] *，在ACL视图下配置针对TCP协议的ACL规则。
- 执行命令rule [ rule-id ] { deny | permit } udp [ destination { destination-address destination-wildcard | any } | destination-port eq port | source { source-address source-wildcard | any } | source-port eq port | dscp dscp | vpn-instance vpn-instance-name ] *，在ACL视图下配置针对UDP协议的ACL规则。
- 执行命令rule [ rule-id ] { deny | permit } gre [ destination { destination-address destination-wildcard | any } | source { source-address source-wildcard | any } | [ dscp dscp | [ tos tos | precedence precedence ] * ] | time-range time-name | logging | vpn-instance vpn-instance-name ] *，在ACL视图下配置针对GRE协议的ACL规则。
 如果需要保护的数据流带有VPN，则配置ACL规则时必须指定相应的vpn-instance-name。
配置小窍门不同场景下rule规则的配置方法大不相同，详细配置方法请参见下面样例。 网关到网关IPSec VPN 在两个网关之间建立点到点的IPSec隧道，假设网关A需要保护的网段为10.1.1.0/24，网关B需要保护的网段为192.168.196.0/24。 网关A的配置如下： [Huawei] acl 3001 [Huawei-acl-adv-3001] rule permit ip source 10.1.1.0 0.0.0.255 destination 192.168.196.0 0.0.0.255 网关B的配置如下： [Huawei] acl 3001 [Huawei-acl-adv-3001] rule permit ip source 192.168.196.0 0.0.0.255 destination 10.1.1.0 0.0.0.255总部到分支IPSec VPN 总部网关和多个分支机构网关之间建立点到多点的隧道，假设总部内网网段为192.168.196.0/24，分支A内网网段为10.1.1.0/24，分支B内网网段为10.1.2.0/24。 - 若仅分支和总部之间需要相互访问，分支之间不需要相互访问，则分支机构ACL的配置参考点到点IPSec VPN即可；总部的ACL的源地址没有变化，目的地址应包含所有分支机构内网网段。
总部ACL配置如下： [Huawei] acl number 3001[Huawei-acl-adv-3001] rule permit ip source 192.168.196.0 0.0.0.255 destination 10.1.1.0 0.0.0.255[Huawei-acl-adv-3001] rule permit ip source 192.168.196.0 0.0.0.255 destination 10.1.2.0 0.0.0.255[Huawei-acl-adv-3001] quit - 若分支和总部之间、分支之间都需要相互访问（分支之间不直接建立隧道，通过总部互相访问），则总部源地址应定义为包括总部和分支的所有网段，目的地址应定义为各个分支机构的内网网段；分支机构的源地址没有变化，目的地址需要包含总部和其它分支内网网段。
总部ACL配置如下： [Huawei] acl number 3001[Huawei-acl-adv-3001] rule permit ip source 192.168.196.0 0.0.0.255 destination 10.1.1.0 0.0.0.255[Huawei-acl-adv-3001] rule permit ip source 192.168.196.0 0.0.0.255 destination 10.1.2.0 0.0.0.255[Huawei-acl-adv-3001] rule permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255[Huawei-acl-adv-3001] rule permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255[Huawei-acl-adv-3001] quit分支A的ACL配置如下： [Huawei] acl number 3001[Huawei-acl-adv-3001] rule permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255[Huawei-acl-adv-3001] rule permit ip source 10.1.1.0 0.0.0.255 destination 192.168.196.0 0.0.0.255[Huawei-acl-adv-3001] quit分支B的ACL配置如下： [Huawei] acl number 3001[Huawei-acl-adv-3001] rule permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255[Huawei-acl-adv-3001] rule permit ip source 10.1.2.0 0.0.0.255 destination 192.168.196.0 0.0.0.255[Huawei-acl-adv-3001] quit
IPSec网关兼作NAT网关 若A端做NAT转换的数据流直接上网，不需要进入IPSec VPN，配置NAT策略时应拒绝IPSec的数据流。 假设A端需要IPSec保护的内网网段为10.1.1.0/24，B端需要IPSec保护的内网网段为192.168.196.0/24。此时A端网关的ACL和NAT策略配置如下： # 定义本端需保护的数据流。[Huawei] acl 3001 [Huawei-acl-adv-3001] rule permit ip source 10.1.1.0 0.0.0.255 destination 192.168.196.0 0.0.0.255 [Huawei-acl-adv-3001] quit
# 在NAT引用的ACL中需要拒绝IPSec保护的地址段。[Huawei] acl 3005 [Huawei-acl-adv-3005] rule deny ip source 10.1.1.0 0.0.0.255 destination 192.168.196.0 0.0.0.255 [Huawei-acl-adv-3005] quit
网关B的配置如下： [Huawei] acl 3001 [Huawei-acl-adv-3001] rule permit ip source 192.168.196.0 0.0.0.255 destination 10.1.1.0 0.0.0.255- 若A、B两端私网地址重叠，A端数据流需要先做NAT转换，再进入IPSec VPN。
假设A端需要IPSec保护的内网网段为10.1.1.0/24，B端需要IPSec保护的内网网段也为10.1.1.0/24，则要求A端进入VPN的数据流先进行私网地址到私网地址的转换，假设转换后的私网地址为10.1.2.1，此时两端ACL配置如下： A端配置： [Huawei] acl 3001 [Huawei-acl-adv-3001] rule permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255[Huawei-acl-adv-3001] quitB端配置： [Huawei] acl 3001 [Huawei-acl-adv-3001] rule permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255[Huawei-acl-adv-3001] quit
GRE over IPSec 当采用ACL方式建立GRE over IPSec隧道时，IPSec保护的数据流为GRE封装后的数据流。ACL的源和目的网段为GRE隧道的源端地址和GRE隧道的目的端地址，即隧道两端网关接口地址。 假设A端公网地址为1.1.1.1/24，B端公网地址为1.2.1.1/24。 A端配置：[Huawei] acl number 3001[Huawei-acl-adv-3001] rule permit ip source 1.1.1.1 0 destination 1.2.1.1 0[Huawei-acl-adv-3001] quit
B端配置：[Huawei] acl number 3001[Huawei-acl-adv-3001] rule permit ip source 1.2.1.1 0 destination 1.1.1.1 0[Huawei-acl-adv-3001] qui
| 
简体中文
英语
日语
韩语
法语
西班牙语
越南语
泰语
阿拉伯语
俄语
葡萄牙语
德语
意大利语
希腊语
荷兰语
波兰语
保加利亚语
爱沙尼亚语
丹麦语
芬兰语
捷克语
罗马尼亚语
斯洛文尼亚语
瑞典语
匈牙利语
繁体中文
文言文
成长值: 64660
发表于 2021-10-11 14:05:43
置顶卡
喧嚣卡
变色卡
千斤顶
发表于 2021-10-11 14:30:23
