IPSec

 一、IPSec 基础 

 AH或者ESP约定了通信双方使用的认证算法和加密算法,算法使用的密钥既可以手工指定,也可以使用ike协商产生。

AH(Authentication Header)安全协议格式

ESP(Encapsulating Security Payload)安全协议格式

组合:
安全协议:AH  ESP  AH-ESP             封装模式:传输模式  隧道模式
❶AH+传输模式/❷AH+隧道模式/❸ESP+传输模式/❹ESP+隧道模式
❺AH-ESP+传输模式/❻AH-ESP+隧道模式

 

 二、IKE 

 因特网密钥交换IKE(Internet Key Exchange)协议建立在Internet安全联盟和密钥管理协议ISAKMP定义的框架上,是基于UDP(User Datagram Protocol的应用层协议,它为IPSec提供了自动协商密钥、建立IPSec SA服务,能够简化IPSec使用和管理,大大简化IPSec的配置和维护工作。

IKE具有一套自保护机制,可以在不安全的网络上安全地认证身份、分发密钥、建立IPsec SA

1身份认证

身份认证确认通信双方的身份(对等体的IP地址或名称),包括预共享密钥PSK(pre-sharedkey)认证数字证书RSA(rsa-signature)认证数字信封认证

IKE支持的认证算法有:MD5SHA1SHA2-256SHA2-384SHA2-512AES-XCBC-MAC-96SM3

2身份保护-身份数据在密钥产生之后加密传送,实现了对身份数据的保护。

IKE支持的加密算法有:DES、3DES、AES-128、AES-192、AES-256、SM1和SM4。

3DH

DH是一种公共密钥交换方法,它用于产生密钥材料,并通过ISAKMP消息在发送和接收设备之间进行密钥材料交换。然后,两端设备各自计算出完全相同的对称密钥。该对称密钥用于计算加密和验证的密钥

MD5SHA1DES3DESAES等算法都可以采用DH算法计算出来的共享对称密钥

4PFS-指一个密钥被破解,并不影响其他密钥的安全性,因为这些密钥间没有派生关系

 IKEv1

 IKEv1分两个阶段,第一阶段有分为两种模式:主模式(Main Mode)和野蛮模式(Aggressive Mode)。

第一阶段,通信双方 协商和建立IKE本身使用的安全通道,建立一个IKE SA

IKE SA建立后对等体间的所有ISAKMP消息都 将通过加密和验证,这条安全通道可以保证IKEv1第二阶段的协商能够安全进行

 主模式包含三次双向交换,用到了六条ISAKMP信息:

1.消息用于提议交换

发起方发送一个或多个IKE安全提议,响应方查找最先匹配的IKE安全提议,并将 这个IKE安全提议回应给发起方。匹配的原则为协商双方具有相同的加密算法、认 证算法、认证方法和Diffie-Hellman组标识。

2.消息用于密钥信息交换

双方交换Diffie-Hellman公共值和nonce值,用于IKE SA的认证和加密密钥在这个阶 段产生。

3.消息用于身份和认证信息交换(双方使用生成的密钥发送信息),双方进 行身份认证和对整个主模式交换内容的认证。

野蛮模式只用到三条信息,前两条消息用于协商IKE安全提议,交换Diffie- Hellman公共值、必需的辅助信息以及身份信息,并且消息中还包括响应方发送身份 信息供发起方认证,消息③(被加密了)用于响应方认证发起方。

IKEv1第二阶段利用第一阶段已 通过了认证和安全保护的安全通道,建立一对IPSec SA

这一阶段采用快速模式(Quick Mode

该模式使用IKEv1协商阶段1生成的密钥ISAKMP消息的完整性和身份进行验证,并对ISAKMP消息进行加密,故保证了 交换的安全性。

IKEv1协商阶段2通过三条ISAKMP消息完成双方IPSec SA的建立

1.协商发起方发送本端的安全参数和身份认证信息。

安全参数包括被保护的数据流和IPSec安全提议等需要协商的参数。身份认证信息包括第一阶段计算出的密钥和第二阶段产生的密钥材料等,可以再次认证对等 体

2. 协商响应方发送确认的安全参数和身份认证信息并生成新的密钥。

IPSec SA数据传输需要的加密、验证密钥由第一阶段产生的密钥、SPI、协议等参数衍生得出,以保证每个IPSec SA都有自己独一无二的密钥。

如果启用PFS,则需要再次应用DH算法计算出一个共享密钥,然后参与上述计算,因此在参数协商时要为PFS协商DH密钥组。

3. 发送方发送确认信息,确认与响应方可以通信,协商结束

IKEv2

在一次协商中可直接生成IPSec的密钥并建立IPSec SA

 IKEv2正常情况使用2次交换共4消息 可以完成一对IPSec SA建立

IKEv2定义了三种交换:初始交换(Initial Exchanges创建子SA交换(Create_Child_SA Exchange)以及通知交换Informational Exchange)

1初始交换Initial Exchanges):

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

消息属于第一次交换(称为IKE_SA_INIT交换),以明文方式完成IKE SA参数协商,包括协商加密和验证算法,交换临时随机数和DH交换IKE_SA_INIT交换后生成一个共享密钥材料,通过这个共享密钥材料可以衍生出IPSec SA的所有密钥

消息属于第二次交换(称为IKE_AUTH交换),以加密方式完成身份认证、对前两条信息的认证和IPSec SA的参数协商。

IKEv2支持RSA签名认证、预共享密钥认证 以及扩展认证方法EAPExtensible Authentication Protocol)。

发起者通过在消息3省去认证载荷来表明需要使用EAP认证。

2 创建子SA交换Create_Child_SA Exchange) :

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

创建子SA交换包含一个交换两条消息,对应IKEv1协商阶段2,交换的发起者可以是初始交换的协商发起方,也可以是初始交换的协商响应方。

创建子SA交换必须在初始交 换完成后进行,交换消息由初始交换协商的密钥进行保护。

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

3 通知交换Informational Exchange) :

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

通知交换必须在IKE SA保护下进行,也就是说通知交换只能发生在初始交换之后

控制信息可能是IKE SA的,那么通知交换必须由该IKE SA来保护进行;

也可能是某子SA ,那么该通知交换必须由生成该子SAIKE SA来保护进行。

  三、IPSec 应用场景

点到点 VPN-IPsec

  到点 VPN-L2TP over IPSec

到点 VPN-GRE over IPSec

 点到点 VPN-IPSec over GRE

 VPN-Hub-Spoke VPN

移动用户远程安全接入

四、IPSec 隧道建立方式

1通过 ACL方式建立 IPSec隧道

ACL来指定要保护的数据流范围,通过配置安全策略并将安全策略绑定在实际的接口上来完成 IPSec配置

采用ACL方式建立IPSec隧道包括 手工方式和IKE动态协商方式

手工方式:SA所需的全部信息都必须手工配 置。

步骤:

定义需要保护的数据流

acl  3000(-3999)

rule  { deny | permit } {ip | tcp | udp | gre} destination source

配置 IPSec 安全提议-包括IPSec使用的安全协 议、认证/加密算法以及数据的封装模式

ipsec proposal proposal-name

transform { ah | esp | ah-esp },配置安全协议

encapsulation-mode { transport | tunnel },配置封装模式

ah authentication-algorithm,配置ah认证算法

esp authentication-algorithm ,配置esp认证算法

esp encryption-algorithm ,配置加密算法

❸ 配置 IPSec 安全策略 

通过引用前面定义的ACL和IPSec安全提议,将ACL定义的数据流和IPSec安全 提议定义的保护方法关联起来,并指定SA的参数、IPSec隧道的起点和终点、 所需要的密钥和SA的生存周期等

ipsec policy policy-name seq-number manual

security acl acl-number IPSec安全策略中引用ACL

proposal proposal-name IPSec安全策略中引用IPSec安全提议

tunnel local ip-address 配置IPSec隧道的本端地址

tunnel remote ip-address 配置IPSec隧道的对端地址

sa spi outbound { ah | esp } spi-number 配置出方向SASPI

sa spi inbound { ah | esp } spi-number 配置入方向SA的SPI

安全协议采用AH协议时,配置认证密钥。

sa string-key { inbound | outbound } ah { simple | cipher } string-key 配 置AH协议的认证密钥(以字符串方式输入)

sa authentication-hex { inbound | outbound } ah { simple | cipher } hex- string 配置AH协议的认证密钥(以16进制方式输入)。

安全协议采用ESP协议时,配置ESP协议的认证密钥。

sa string-key { inbound | outbound } esp { simple | cipher } string-key配 置ESP协议的认证密钥(以字符串方式输入)。

安全协议采用ESP协议时,配置ESP协议的认证密钥和加密密钥。

sa authentication-hex { inbound | outbound } esp { simple | cipher } hex- string,配置ESP协议的认证密钥(以16进制方式输入)。

sa encryption-hex { inbound | outbound } esp { simple | cipher } hex- string配置ESP协议的加密密钥(以16进制方式输入

将策略应用在对应网络接口上

IKE动态协商方式:由IKE协议完成密钥的自动协商,实现动态协商来创建和维护SA。

定义需要保护的数据流

acl  3000(-3999)

rule  { deny | permit } {ip | tcp | udp | gre} destination source

配置 IPSec 安全提议-包括IPSec使用的安全协 议、认证/加密算法以及数据的封装模式

ipsec proposal proposal-name

transform { ah | esp | ah-esp },配置安全协议

encapsulation-mode { transport | tunnel },配置封装模式

ah authentication-algorithm,配置ah认证算法

esp authentication-algorithm ,配置esp认证算法

esp encryption-algorithm ,配置加密算法

❸ 配置 IKE 安全提议

ike proposal proposal-number,创建一个IKE安全提议

authentication-method { pre-share | rsa-signature | digital-envelope },配置认证方法

authentication-algorithm { md5 | sha1 | sha2-256 | sha2-384 | sha2-512 |sm3 },配置IKE协商时所使用的认证算法

encryption-algorithm { des | 3des | aes-128 | aes-192 | aes-256 | sm4 | sm1 },配 置IKE协商时所使用的加密算法

dh { group1 | group2 | group5 | group14 | group19 | group20 | group21 },配置 IKE协商时采用的DH组

配置 IKE 对等体

ike peer peer-name,创建IKE对等体并进入IKE对等体视图

version { 1 | 2 },配置IKE对等体使用的IKE协议版本号

exchange-mode { main | aggressive },配置IKEv1阶段1协商模式

local-address ipv4-address,配置IKE协商时的本端IP地址

remote-address { [ vpn-instance vpn-instance-name ] { ipv4-address | host-name host-name } | authentication-address start-ipv4-address [ end-ipv4-address ] }, 配置IKE协商时的对端IP地址或域名

ike-proposal proposal-number,引用IKE安全提议

pre-shared-key key,配置对等体IKE协商采用预共享密钥 认证时,IKE用户所使用的预共享密钥

配置 IPSec 安全策略

ipsec policy policy-name seq-number isakmp创建ISAKMP方式IPSec安全策 略

security acl acl-number IPSec安全策略中引用ACL

proposal proposal-nameIPSec安全策略中引用IPSec安全提议

ike-peer peer-nameIPSec安全策略中引用IKE对等体

将策略应用在对应网络接口上

2通过虚拟隧道接口方式建立IPSec隧道

采用虚拟隧道接口建立IPSec隧道是基于路由方式。这种方式下,由路由来选择需要保护的数据流

通过配置安全框架并在虚拟隧道接口上应用安全框架来完成IPSec的配置。所有路由到IPSec虚拟隧道接口的报文都将进行IPSec保护。

配置 IPSec 安全提议

ipsec proposal proposal-name

transform { ah | esp | ah-esp },配置安全协议

encapsulation-mode  tunnel ,配置封装模式

ah authentication-algorithm,配置ah认证算法

esp authentication-algorithm ,配置esp认证算法

esp encryption-algorithm ,配置加密算法

❷ 配置 IKE 安全提议

ike proposal proposal-number,创建一个IKE安全提议

authentication-method { pre-share | rsa-signature | digital-envelope },配置认证方法

authentication-algorithm { md5 | sha1 | sha2-256 | sha2-384 | sha2-512 |sm3 },配置IKE协商时所使用的认证算法

encryption-algorithm { des | 3des | aes-128 | aes-192 | aes-256 | sm4 | sm1 },配 置IKE协商时所使用的加密算法

dh { group1 | group2 | group5 | group14 | group19 | group20 | group21 },配置 IKE协商时采用的DH组

配置 IKE 对等体

ike peer peer-name,创建IKE对等体并进入IKE对等体视图

version { 1 | 2 },配置IKE对等体使用的IKE协议版本号

exchange-mode { main | aggressive },配置IKEv1阶段1协商模式

local-address ipv4-address,配置IKE协商时的本端IP地址

remote-address { [ vpn-instance vpn-instance-name ] { ipv4-address | host-name host-name } | authentication-address start-ipv4-address [ end-ipv4-address ] }, 配置IKE协商时的对端IP地址或域名

ike-proposal proposal-number,引用IKE安全提议

pre-shared-key key,配置对等体IKE协商采用预共享密钥 认证时,IKE用户所使用的预共享密钥

配置 IPSec 安全框架

一个IPSec安全框架相当于一 个IPSec安全策略,与IPSec安全策略不同的是,安全框架由名称唯一确定,且只能通过 IKE协商方式配置

ipsec profile profile-name,创建安全框架,并进入安全框架视图

proposal proposal-name,在安全框架中引用IPSec安全提议

ike-peer peer-name,在安全框架中引用IKE对等体

match ike-identity identity-name引用身份过滤集

pfs { dh-group1 | dh-group2 | dh-group5 | dh-group14 | dh-group19 |dh-group20 | dh-group21 },配置本端发起协商时使用的PFS特性

IPSec安全框架无需通过ACL定义数据流,而是保护所有路由到IPSec虚拟隧道接口的数 据流。在IPSec虚拟隧道接口下应用IPSec安全框架后只会生成一条IPSec隧道,并对所 有路由到该隧道接口的数据流进行IPSec保护,简化了安全策略管理的复杂度

配置虚拟隧道接口,并在接口上应用安全框架

interface tunnel interface-number,进入Tunnel接口视图

tunnel-protocol { gre [ p2mp ] | ipsec },配置隧道接口的封装模式

ip address ip-address { mask | mask-length } [ sub ],手工配置 Tunnel接口的IPv4私网地址

ip address ike-negotiated, 配置通过IKEv2协商为Tunnel接口申请IPv4地址

source { [ vpn-instance vpn-instance-name ] source-ip-address |interface-type interface-number },配置Tunnel接口的源地址或源接口

destination [ vpn-instance vpn-instance-name ] dest-ip- address,配置Tunnel接口的目的地址

tunnel pathmtu enable,使能IPSec隧道的路径MTU(Maximum Transmission Unit)值学习功能

ipsec profile profile-name在Tunnel接口上应用IPSec安全框架,使其具有IPSec的保护功能。

五、举例说明ipsec对包的封装-sa手工指定,不使用IKE协商

1、未部署IPSec VPN时,原始报文(ping测试) 

 

 2、部署IPSec VPN(安全协议AH,传输模式)时,原始报文(ping测试)被封装:

 

 

 RA对包进行封装(AH+传输模式),包不添加新的ip包头,源为10.1.1.2,目的为10.1.2.2。

RB收到包后,不解封(包的目的地址不是自己),直接转发给10.1.2.2。10.1.2.2不能识别ipsec包,丢弃。

3、部署IPSec VPN(安全协议AH,隧道模式)时,原始报文(ping测试)被封装:

 

 

 原始报文除了添加AH头,还另外添加的新的ip头,目的地址为RB,因此RB能够解封ipsec包后将原始报文路由到真实的目的地址。

4、部署IPSec VPN(安全协议ESP,传输模式)时,原始报文(ping测试)被重新封装:

 

 传输模式不添加新的ip头,导致RB不解封ipsec包,让最终站点去解封,导致解封失败,丢弃包。

5、部署IPSec VPN(安全协议ESP,隧道模式)时,原始报文(ping测试)被重新封装:

 

6、部署IPSec VPN(安全协议AH-ESP,传输模式)时,原始报文(ping测试)被重新封装:

 

 

 

 传输模式下:存在和以上一样的问题

7、部署IPSec VPN(安全协议AH-ESP,隧道模式)时,原始报文(ping测试)被重新封装:

 

 

 

总结:在网关对网关的ipsec vpn下,需要使用隧道模式的封装。

传输模式适用于端到端的ipsec 。

手工设置sa参数,工作量大,容易出错,且一经建立,永久不变,会导致安全性降低,所以不推荐使用。

 六、IPSec实例-基本

点到点VPN-IPSec

 1、通过 ACL方式建立 IPSec隧道

A、手动创建隧道 

RA:

acl number 3000 

 rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255

#

ipsec proposal pro1

 transform ah-esp

encapsulation-mode tunnel

 ah authentication-algorithm sha1

 esp authentication-algorithm sha1

 esp encryption-algorithm 3des

#

ipsec policy p1 10 manual

 security acl 3000

 proposal pro1

 tunnel local 1.1.1.1

 tunnel remote 2.1.1.1

 sa spi inbound ah 4321

 sa string-key inbound ah simple 123

 sa spi outbound ah 1234

 sa string-key outbound ah simple 123

 sa spi inbound esp 54321

 sa string-key inbound esp simple 124

 sa spi outbound esp 12345

 sa string-key outbound esp simple 124

#

int g1/0/0

ip add 1.1.1.1 24

ipsec policy p1

 B、ike动态协商创建隧道

RA:

acl number 3000 

 rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255

#

ipsec proposal pro1

 transform ah-esp

encapsulation-mode tunnel

 ah authentication-algorithm sha1

 esp authentication-algorithm sha1

 esp encryption-algorithm 3des

#

ike proposal 5

authentication-algorithm sha1

authentication-method pre-shared

 encryption-algorithm 3des-cbc

 dh group14

#

ike peer PA v1

 pre-shared-key simple 123

 ike-proposal 5

 remote-address 2.1.1.1

#

ipsec policy p1 10 isakmp

 security acl 3000

 ike-peer PA

 proposal pro1

#

int g1/0/0

ip add 1.1.1.1 24

ipsec policy p1

ike动态协商生成的ipsec sa

 

 

  2、通过虚拟隧道接口方式建立IPSec隧道

 RA:

ipsec proposal pro1

 transform ah-esp

encapsulation-mode tunnel

 ah authentication-algorithm sha1

 esp authentication-algorithm sha1

 esp encryption-algorithm 3des

#

ike proposal 5

 encryption-algorithm 3des-cbc

 dh group14

#

ike peer PA v1

 pre-shared-key simple 123

 ike-proposal 5

#

ipsec profile pf1

 ike-peer PA

 proposal pro1

#

interface Tunnel0/0/0

 ip address 192.168.1.1 255.255.255.0

 tunnel-protocol ipsec

 source 1.1.1.1

 destination 2.1.1.1

 ipsec profile pf1

#

ip route-static 10.1.2.0 24 Tunnel 0/0/0

 ike动态协商生成的ipsec sa

 

  七、IPSec实例-增强-GRE over IPSec

 【点到点VPN-GRE over IPSec

先GRE封装,后IPSec封装 

1、通过ACL方式建立GRE over IPSec (AH+传输模式)

A、手动创建隧道 -不推荐,略

 B、ike动态协商创建隧道 

RA:

acl number 3000 

 rule 5 permit ip source 1.1.1.1 0 destination 2.1.1.1 0

或者

acl number 3000 

 rule 10 permit gre source 1.1.1.1 0 destination 2.1.1.1 0

#

ipsec proposal pro1

 encapsulation-mode transport

 transform ah

 ah authentication-algorithm sha2-512

#

ike proposal 5

 encryption-algorithm 3des-cbc

 dh group14

 authentication-algorithm md5

#

ike peer ra v1

 pre-shared-key simple 123

 ike-proposal 5

 remote-address 2.1.1.1

#

ipsec policy p1 10 isakmp

 security acl 3000

 ike-peer ra

 proposal pro1

#

interface Tunnel0/0/0

 ip address 192.168.1.1 255.255.255.0

 tunnel-protocol gre

 source 1.1.1.1

 destination 2.1.1.1

#

interface GigabitEthernet0/0/2

 ip address 1.1.1.1 255.255.255.0

 ipsec policy p1

#

ip route-static 10.1.2.0 255.255.255.0 Tunnel0/0/0

注:去往10.1.2.0的报文,被路由到gre隧道,做gre封装,添加上新的ip头,源地址为1.1.1.1,目的地址为2.1.1.1。新封装的报文,路由下一跳,从GigabitEthernet0/0/2接口转发,GigabitEthernet0/0/2接口启用ipsec策略,先做ipsec封装,再从GigabitEthernet0/0/2接口路由转发出去。

RA-IKE SA

 RB-IKE SA

 RA-IPSec SA

  RB-IPSec SA

 2、通过虚拟隧道接口方式建立GRE over IPSec (AH-ESP+隧道模式)

RA:

ipsec proposal pro1

 transform ah-esp

encapsulation-mode tunnel

 ah authentication-algorithm sha1

 esp authentication-algorithm sha1

 esp encryption-algorithm 3des

#

ike proposal 5

 encryption-algorithm 3des-cbc

 dh group14

 authentication-algorithm md5

#

ike peer PA v1

 pre-shared-key simple 123

 ike-proposal 5

#

ipsec profile pf1

 ike-peer PA

 proposal pro1

#

interface Tunnel0/0/0

 ip address 192.168.1.1 255.255.255.0

 tunnel-protocol gre

 source 1.1.1.1

 destination 2.1.1.1

 ipsec profile pf1

ip route-static 10.1.2.0 255.255.255.0 Tunnel0/0/0

虚拟隧道接口上应用ipsec 安全框架profile pf1。

点到点VPN-GRE over IPSec 不同安全协议和封装模式下包的封装格式展示

虚拟隧道接口方式为例:

interface Tunnel0/0/0

 ip address 192.168.1.1 255.255.255.0

 tunnel-protocol gre

 source 1.1.1.1

 destination 2.1.1.1

 ipsec profile pf1

ip route-static 10.1.2.0 255.255.255.0 Tunnel0/0/0

先GRE封装:

再IPSec封装:

1、AH+传输模式

 

 

2、AH+隧道模式

3、ESP+传输模式

 

4、ESP+隧道模式

由于ESP头后面的数据被加密了,因此 ESP+传输模式和ESP+隧道模式的封装显示格式一样。

5、AH-ESP+传输模式

6、AH-ESP+隧道模式

 由于ESP头后面的数据被加密了,因此AH-ESP+传输模式和AH-ESP+隧道模式的封装显示格式一样。

八、IPSec实例-增强-IPSec over GRE

原始数据包先经过IPSec封装后,再经过GRE隧道封装。

1、通过ACL方式建立IPSec over GRE

A、手动创建隧道 -不推荐,略

B、ike动态协商创建隧道 

R1:

acl number 3000 

 rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255

#

ipsec proposal pro1

 transform ah

 ah authentication-algorithm sha1

 esp authentication-algorithm sha1

 esp encryption-algorithm 3des

#

ike proposal 5

 encryption-algorithm 3des-cbc

 dh group14

#

ike peer PA v1

 pre-shared-key simple 123

 ike-proposal 5

 remote-address 192.168.1.2      

#

ipsec policy p1 10 isakmp

 security acl 3000

 ike-peer PA

 proposal pro1

#

interface Tunnel0/0/0

 ip address 192.168.1.1 255.255.255.0

 tunnel-protocol gre

 source 1.1.1.1

 destination 2.1.1.1

ipsec policy p1(软件版本低,不支持在gre隧道接口应用ipsec策略)

ip route-static 10.1.2.0 255.255.255.0 Tunnel0/0/0

虚拟隧道接口使用的策略、安全框架及本身协议的先后顺序:

ipsec policy>gre>ipsec profile


h3c实现方式 -acl方式:

interface Tunnel0 mode gre

 ip address 192.168.1.1 255.255.255.0

 source 1.1.1.1

 destination 2.1.1.1

 ipsec apply policy p1

#

ipsec transform-set pro1

 protocol ah    //默认为隧道模式

 ah authentication-algorithm sha256

#

ipsec policy p1 10 isakmp

 transform-set pro1

 security acl 3000

 remote-address 192.168.1.2

#

ike keychain key1

 pre-shared-key address 192.168.1.2 255.255.255.0 key simple 123

ike对等体不再是物理接口的公网地址了。 

  


 2、通过虚拟隧道接口方式建立IPSec over GRE

R1:

ipsec proposal pro1

encapsulation-mode tunnel

 transform ah

 ah authentication-algorithm sha1

 esp authentication-algorithm sha1

 esp encryption-algorithm 3des

#

ike proposal 5

 encryption-algorithm 3des-cbc

 dh group14

#

ike peer PA v1

 pre-shared-key simple 123

 ike-proposal 5

#

ipsec profile pf1

 ike-peer PA

 proposal pro1

#

interface Tunnel0/0/0

 ip address 192.168.1.1 255.255.255.0

 tunnel-protocol gre

 source 1.1.1.1

 destination 2.1.1.1

#

interface Tunnel0/0/1

 ip address 192.168.2.1 255.255.255.0

 tunnel-protocol ipsec

 source Tunnel0/0/0

 destination 192.168.1.2

 ipsec profile pf1

ip route-static 10.1.2.0 255.255.255.0 Tunnel0/0/1 

原始数据表路由到ipsec隧道接口,先做ipsec。profile pf1使用ipsec隧道的source做ike协商的源,使用ipsec隧道的destination做ike协商的目的,即ike协商源192.168.1.1,ike协商目的192.168.1.2,隧道模式下,添加新的ip头,新的IP包头源和目的分别为ike对等体的源和目的地址,即192.168.1.1-192.168.1.2

192.168.1.1->192.168.1.2,需要经过gre封装,封装的源和目的为gre隧道的source和destination,也即物理接口的地址。

(软件版本低,导致ike对等体192.168.1.1和192.168.1.2 ike协商失败。)

ikev1阶段一, ike对等体之间相互发送消息1,但是对等体收到消息1后都不做处理,以至于ike协商超时。

九、IKE协商过程分析

前面用例虽然使用了ike动态协商ike sa和ipsec sa创建ipsec 隧道,但是其协商过程不甚了了,现在结合用例,分析ike协商的详细过程。

1、IKE对等体之间发送的用于协商报文格式:

IP报文头:

源地址:为发起IKE协商的IP地址。

目的IP地址:为对端设备的IP地址。

UDP报文头:IKE协议使用端口号500发起协商、响应协商。

ISAKMP报文头:

Initiator's Cookie(SPI):发起端唯一标识一个IKE SA的数值,不能为0。

Responder's Cookie(SPI):响应端唯一标识一个IKE SA的数值,第一条消息中SPI为0,后续均不为0。

Next Payload:标识消息中下一个载荷的类型。当后面没有载荷时,该值为0。

Maj Ver/Min Ver:主版本/副版本,ISAKMP版本的标识是用主版本和副版本的字段中的主/副编号来进行的。在IKE中,两个字段合为一个字段。

Version:IKEv1版本该字段值为1.0,IKEv2版本该字段值为2.0。

Exchange Type:交换类型,该字段限制消息的载荷内容和交换消息的顺序。

 IKEv1的交换类型

IKEv2的交换类型

Flags:标志表示特定的选项,用于设定ISAKMP交换。以下在标志字段中指定的标志,从最低有效位开始:

IKEv1:第0位为加密位,为1表示有效载荷已被加密;

第1位为提交位,为1表示确保建立SA之后才能收到加密的内容;

第2位为认证位,为1表示只对有效载荷进行验证,而不进行加密。

其他剩余位没有被定义,必须在传输前设为0。

IKEv2:第3位为1表示发起方,第4为IKEv2应设为0,第5位为1表示响应方。其他剩余位没有被定义,必须在传输前设为0。

Message ID:第一阶段中该字段为0,在第二阶段为发起方生成的随机数。

它作为惟一的消息标志,用于在第二阶段的协商中标识协议状态。

Message Length:标识ISAKMP消息的全长(包含消息头和载荷)。

2、测试用例-acl方式

配置:

#

acl number 3000 

 rule 10 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255

#

ipsec proposal pro1

 transform ah

 ah authentication-algorithm sha2-384

#

ike proposal 5

 encryption-algorithm 3des-cbc

 dh group14

 authentication-algorithm md5

#

ike peer ra v1

 pre-shared-key simple 123

 ike-proposal 5

 remote-address 2.1.1.1 2.1.1

#

ipsec policy p1 10 isakmp

 security acl 3000

 ike-peer ra

 proposal pro1

ike协商结果:

RB对应上图中的RouterA,RA对应上图中的RouterB 

过程分析:RouterA和RuouterB之间抓包

 IKEv1 阶段1-主模式

 

消息1:

消息①:发起方发送封装有IKE安全提议的SA载荷进行安全提议协商,SA中参数包括加密算法、认证方法、认证算法、DH组、IKE SA生存周期等。

消息2:

消息②:响应方查找最先匹配的IKE安全提议,发送一个SA载荷,表明接受协商的IKE安全提议。

消息3:

消息4:

消息(③、④:发起者和接受者交换DH公开值(KE载荷)和临时随机数(Ni、Nr)

Ni、Nr是计算共享密钥(用来生成加密密钥和认证密钥)所必须的。

消息5:

消息6:

消息⑤、⑥:双方交换身份ID(ID载荷)和验证Hash值(AUTH载荷)

IKEv1 阶段1-野蛮模式-两端的模式必须一致

RB:

ike peer ra v1

 exchange-mode aggressive

 pre-shared-key simple 123

 ike-proposal 5

 remote-address 2.1.1.1

RA:

ike peer rb v1

 exchange-mode aggressive

 pre-shared-key simple 123

 ike-proposal 5

 remote-address 1.1.1.1

 

消息1:

消息①:发起端发送封装有IKE安全提议的SA载荷。在野蛮模式中,只带有一个安全提议(加密算法、认证方法、认证算法、DH组、IKE SA生存周期等),响应者可以选择接受或拒绝该安全提议。DH公开值(KE载荷)、临时随机数(Ni载荷)和身份ID(ID载荷)也在其中发送。野蛮模式下,身份信息未经加密,故获取报文头能够看到。

消息2:

消息②:响应者发送SA载荷,包含推荐的ike安全提议。DH公开值(KE载荷)、临时随机数(Nr载荷)和身份ID(ID载荷)、验证Hash值(AUTH载荷)也在其中发送。

消息3:

消息③:发起端发送验证Hash值确认协商成功。 

IKEv1 阶段2-快速模式

消息1:

消息2:

消息①、②:协商IPSec安全提议(SA载荷),为PFS功能协商DH密钥组(KE载荷)。交换身份ID(ID载荷为可选)和完整性验证Hash值(AUTH载荷)。

消息3:

消息③:发送完整性验证Hash值确认协商成功

快速模式的三条消息都被加密了。

IKEv2-两端的版本必须一致

RB:

ike peer ra v2

 pre-shared-key simple 123

 ike-proposal 5

 remote-address 2.1.1.1

RA:

ike peer rb v2

 pre-shared-key simple 123

 ike-proposal 5

 remote-address 1.1.1.1

消息1:

消息2:

消息①、②:IKE_SA_INIT交换。协商IKE安全提议(SA载荷),交换临时随机数(Ni、Nr载荷)和DH公开值(KE载荷)。

消息3:

消息4:

消息③、④:IKE_AUTH交换。双方继续交换身份ID(ID载荷)和Hash值(AUTH载荷),协商IPSec安全提议(SA载荷)、待保护数据流(TS载荷)。Notify载荷用于错误通知。协商通过后建立IKE SA和一对IPSec SA。 

3、测试用例-虚拟隧道接口方式

ike peer ra v1

 pre-shared-key simple 123

 ike-proposal 5

#

ipsec profile pf1

 ike-peer ra

 proposal pro1

#

interface Tunnel0/0/10

 ip address 192.168.1.1 255.255.255.0

 tunnel-protocol ipsec

 source 1.1.1.1

 destination 2.1.1.1

 ipsec profile pf1

 ikev1阶段一:主模式

消息1:

消息2:

消息3:

消息4:

消息5:

消息6:

ikev1阶段二:快速模式

消息1:

消息2:

消息3:

总结:acl方式和虚拟隧道接口(框架profile)方式,两种方式下,ike协商过程一致,无区别。

ikev1野蛮模式和ikev2协商过程不再赘述 

4、测试用例-gre over ipsec ike协商-acl方式

 acl number 3000 

 rule 5 permit ip source 1.1.1.1 0 destination 2.1.1.1 0

或者

acl number 3010 

 rule 10 permit gre source 1.1.1.1 0 destination 2.1.1.1 0

#

ike peer ra v1

 pre-shared-key simple 123

 ike-proposal 5

 remote-address 2.1.1.1

#

ipsec policy p2 10 isakmp

 security acl 3010

 ike-peer ra

 proposal pro1

#

interface Tunnel0/0/0

 ip address 192.168.1.1 255.255.255.0

 tunnel-protocol gre

 source 1.1.1.1

 destination 2.1.1.1

#

interface GigabitEthernet0/0/2

 ip address 1.1.1.1 255.255.255.0

 ipsec policy p2

#

ip route-static 10.1.2.0 255.255.255.0 Tunnel0/0/0

gre封装,然后将1.1.1.1<->2.1.1.1之间的ip或者gre流量ipsec封装

ike协商的对等体为1.1.1.12.1.1.1

gre over ipsec ike协商-acl方式:与前面ike协商过程一样。 

5、测试用例-gre over ipsec ike协商-虚拟隧道接口方式

#

ike peer ra v1

 pre-shared-key simple 123

 ike-proposal 5

#

ipsec profile pf1

 ike-peer rb

 proposal pro1

#

interface Tunnel0/0/0

 ip address 192.168.1.1 255.255.255.0

 tunnel-protocol gre

 source 1.1.1.1

 destination 2.1.1.1

ipsec profile pf1

#

ip route-static 10.1.2.0 255.255.255.0 Tunnel0/0/0

gre封装,然后将1.1.1.1<->2.1.1.1之间的流量ipsec封装

ike协商的对等体为1.1.1.12.1.1.1

gre over ipsec ike协商-虚拟隧道接口方式:与前面ike协商过程一样。 

6、测试用例-ipsec over gre ike协商-ACL方式

软件版本低,不支持在虚拟隧道接口上应用ipsec策略,使用h3c来测试验证

interface Tunnel0 mode gre

 ip address 192.168.1.1 255.255.255.0

 source 1.1.1.1

 destination 2.1.1.1

 ipsec apply policy p1

#

ipsec transform-set pro1

 protocol ah

 ah authentication-algorithm sha256

#

ipsec policy p1 10 isakmp

 transform-set pro1

 security acl 3000

 remote-address 192.168.1.2

#

ike keychain key1

 pre-shared-key address 192.168.1.2 255.255.255.0 key simple 123

 

ikev1第一阶段只有一个消息报文 

 ikev1阶段2快速模式的的三个消息报文类似,略。

7、测试用例-ipsec over gre ike协商-虚拟隧道接口方式

ipsec proposal pro1

encapsulation-mode tunnel

 transform ah

 ah authentication-algorithm sha1

 esp authentication-algorithm sha1

 esp encryption-algorithm 3des

#

ike proposal 5

 encryption-algorithm 3des-cbc

 dh group14

#

ike peer PA v1

 pre-shared-key simple 123

 ike-proposal 5

#

ipsec profile pf1

 ike-peer PA

 proposal pro1

#

interface Tunnel0/0/0

 ip address 192.168.1.1 255.255.255.0

 tunnel-protocol gre

 source 1.1.1.1

 destination 2.1.1.1

#

interface Tunnel0/0/1

 ip address 192.168.2.1 255.255.255.0

 tunnel-protocol ipsec

 source Tunnel0/0/0

 destination 192.168.1.2

 ipsec profile pf1

ip route-static 10.1.2.0 255.255.255.0 Tunnel0/0/1

数据包路由到ipsec隧道接口Tunnel0/0/1,先做ipsec。profile pf1使用ipsec隧道的source做ike协商的源,使用ipsec隧道的destination做ike协商的目的,即ike协商源192.168.1.1,ike协商目的192.168.1.2,隧道模式下,添加新的ip头,新的IP包头源和目的分别为ike对等体的源和目的地址,即192.168.1.1-192.168.1.2

192.168.1.1->192.168.1.2,需要经过gre封装,封装的源和目的为gre隧道的source和destination,也即物理接口的地址。

ike对等体192.168.1.1与192.168.1.2之间的isakmp消息报文封装在gre报文中,然后封装公网ip头。

ikev1第一阶段,ike发起方发送消息1,响应方收到消息1后,不做处理,然后也发送消息1,发起方收到消息后,也不做处理。

可能原因:不能使用虚拟接口地址作为ike对等体的响应方-----------软件版本低 

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值