HTML/JavaScript

2016年12月26日星期一

【Cisco】【安全】【CCNA】GRE Over IPSec VPN

GRE Over IPSec VPN

GRE Over IPSec VPN

介绍

  1. GRE Over IPSec VPN 介绍
  2. 配置GRE Over IPSec VPN
  3. 传输模式和隧道模式GRE Over IPSec VPN

GRE Over IPSec VPN 介绍

在传统IPSec VPN中需要配置多条access-list来匹配感兴趣的流,从而触发建立IPSec VPN SA,来加密业务流量,这样当流量变得复杂的时候就不利于管理,需要创建很多条access-list配置量大不容易维护。并且没有相应的接口,去维护这些流量,使得不可进行策略管理。
但是GRE拥有良好的隧道特性,但是不具备加密、可靠性、认证功能。所以,有没有一种可能将IPSes VPN应用在GRE tunnel上呢?一方面提供了接口可以进行策略管理,另外一方面GRE tunnel 可以运行组播,保证了动态路由协议的运行,还提供的逻辑的tunnel接口可以进行策略管理。 这就是将要介绍的GRE Over IPSec VPN。

GRE相比传统IPSes VPN提供了以下特性:
1. IP组播支持
2. 提供逻辑接口进行策略控制
3. 仅需配置一条感兴趣的流用于IPSec VPN建立。

配置GRE Over IPSec VPN

需求:
1.R2和R5 之间通过GRE Tunnel建立ospf,并且传递彼此1.1.1.1和6.6.6.6的路由
2.建立ospf更新路由表,在tunnel上的这些路由匹配ipsec vpn,进行加密,无需单独配置感兴趣的流

配置GRE Over IPSec VPN主要分为以下三个步骤:

  1. 创建GRE Tunnel
  2. 配置基础IPSec 策略包括(isakmp policy、isakmp key、ipsec transform-set、crypto map)
  3. 配置感兴趣的流(permit gre),并且在物理接口下应用crypto map

拓扑图如下。

enter image description here

关键配置:

R2:
crypto isakmp policy 10
 encr aes
 hash md5
 authentication pre-share
 group 16
crypto isakmp key ccie43413 address 192.168.45.5   
!
crypto ipsec transform-set ipsec-police esp-aes esp-sha512-hmac 
 mode transport
!
crypto map vpn 10 ipsec-isakmp 
 set peer 192.168.45.5
 set transform-set ipsec-police 
 match address vpn
!
ip access-list extended vpn
 permit gre host 192.168.23.2 host 192.168.45.5
!
interface Tunnel1
 ip address 192.168.25.2 255.255.255.0
 ip ospf 2 area 0
 tunnel source 192.168.23.2
 tunnel destination 192.168.45.5
!       
interface Ethernet0/1
 ip address 192.168.23.2 255.255.255.0
 ip ospf 1 area 0
 crypto map vpn
!
end

R5:
crypto isakmp policy 10
 encr aes
 hash md5
 authentication pre-share
 group 16
crypto isakmp key ccie43413 address 192.168.23.2   
!
crypto ipsec transform-set ipsec-police esp-aes esp-sha512-hmac 
 mode transport
!
crypto map vpn 10 ipsec-isakmp 
 set peer 192.168.23.2
 set transform-set ipsec-police 
 match address vpn
!
interface Tunnel1
 ip address 192.168.25.5 255.255.255.0
 ip ospf 2 area 0
 tunnel source 192.168.45.5
 tunnel destination 192.168.23.2
!
interface Ethernet0/3
 ip address 192.168.45.5 255.255.255.0
 ip ospf 1 area 0
 crypto map vpn
!
ip access-list extended vpn
 permit gre host 192.168.45.5 host 192.168.23.2
!
end

需要注意:
1. 在配置感兴趣流的时候使用的是permit gre ,而非permit ip
2. crypto应用在物理接口上,而非tunnel接口。

匹配感兴趣的流,需要使用permit gre而非permit ip,这是因为在进行GRE封装之后permit ip匹配的是原始IP,而非new gre ip,所以如果使用permit ip是匹配不到业务流量去触发进行SA建立的。
第二之所以应用在物理接口上,因为如果应用在tunnel接口上,原始数据会先进行加密,再进行GRE封装,显然这样的流程是不对的。因为先加密必然需要先出去匹配感兴趣的流,这样相当于又走回之前逐条匹配感兴趣流的方式了。所以必须先进行GRE封装得到原始报文,再使用这个原始报文进行加密流程。下图列出了内部的处理流程,参考IPSec VPN实战指南。在原有的基础上加入了一些自己的理解。

enter image description here

可以看到,流量从入接口进入之后先去查找路由表,发现下一跳是tunnel接口,tunnel是GRE,于是先进行GRE封装,打上IP之后准备从出接口发送出去,然后因为出接口有crypto map ,正好match上了GRE的流量,执行crypto流程。完成加密和封装操作之后最后将加密后的报文从出接口发送出去。
由此可以看到,过去进行match的时候是匹配的内网上的主机到主机。而引入了gre之后,我们只需匹配GRE 头部上的IP地址即可。这样减轻了配置压力。

传输模式和隧道模式GRE Over IPSec VPN

在前面介绍过因为通信点与加密点的不同所以要使用传输模式或隧道模式。然而在GRE Tunnel中引入了新的GRE Head 和GRE IP Head错误的选择可能会造成不必要的开销。如下列出了在GRE Tunnel中传输模式和隧道模式的报文。

enter image description here

这里或许会有疑问,在GRE over ipsec 隧道模式中,会有三个IP头,分别是 ESP封装 NEW-IP-Head ,GRE IP和原始IP Head。那么这三者的ip地址分别是多少呢?
笔者通过使用ESP-null 的方式获取到了数据得出如下解包。发现GRE IP和原始IP部分是一致的,所以在实际使用中如果不涉及NAT的问题,就可以使用传输模式这样可以节约24个字节的带宽,以免造成不必要的浪费。具体详见如下。

ESP-null IPSec HeadIPsec Head

参考文献

  1. 《IPSec VPN实战指南》
  2. IPSec Overhead Calculator Tool

2017年10月13日更新

2016年12月11日星期日

【Cisco】【安全】【CCNA】IPSec VPN Troubleshooting

IPSec VPN Troubleshooting

IPSec VPN Troubleshooting

介绍

  1. IPSec debug(参考)
  2. IPSes Troubleshooting视频

IPSec debug

这里主要介绍“debug crypto isakmp sa”,由于篇幅的问题,直接粘贴出来并不便于查看。所以请在此查看debug信息,当中做了简要注释。点击此处查看

如下部分是我自己依据debug信息所作出的状态机变迁图。由于没有找到官方的状态机的图,也没有找到状态机的介绍,所以在此不做解释。仅供参考。

enter image description here

IPSes Troubleshooting视频

参见:https://www.youtube.com/watch?v=0PqtbHQGt2U

2017年10月13日 更新

2016年12月5日星期一

【Cisco】【安全】【CCNA】IPSec VPN 报文介绍以及协商建立过程

IPSec VPN 报文介绍以及协商建立过程

IPSec VPN 报文介绍以及协商建立过程

介绍

  1. ISAKMP报文介绍
  2. IPSec VPN协商建立过程(IKEv1)

ISAKMP报文介绍

ISAKMP头部信息如下。

enter image description here

Nitiator Cookie(Initiator SPI)(8 octets):发起SA建立实体Cookie,SA通知或SA删除
Responder Cookie(Responder SPI)(8 octets):响应SA建立请求的实体的Cookie,SA通知或SA删除
Next Payload (1 octet):表示第一有效负荷的消息中的类型

 Next Payload Type           Value
 NONE                        0
 Security Association (SA)   1
 Proposal (P)                2
 Transform (T)               3
 Key Exchange (KE)           4
 Identification (ID)         5
 Certificate (CERT)          6
 Certificate Request (CR)    7
 Hash (HASH)                 8
 Signature (SIG)             9
 Nonce (NONCE)               10
 Notification (N)            11
 Delete (D)                  12
 Vendor ID (VID)             13
 RESERVED                    14 - 127
 Private USE                 128 - 255

Major Version (4 bits):标识正在使用的ISAKMP协议的主要版本。
Minor Version (4 bits):标识正在使用的ISAKMP协议的次要版本
Exchange Type(1 octet):标识使用的交换(exchange) 的类型

 Exchange Type          Value
 NONE                   0
 Base                   1
 Identity Protection    2 
 Authentication Only    3
 Aggressive             4
 Informational          5
 ISAKMP Future Use      6 - 31
 DOI Specific Use       32 - 239
 Private Use            240 - 255

Flags (1 octet):标识为ISAKMP交换设置的特定选项
··· E(ncryption Bit) (1 bit):如果设置(1),则使用在ISAKMP SA中标识的加密算法对报头之后的所有有效载荷进行加密。对于第4.1节中描述的所有ISAKMP交换,加密应该在双方交换密钥交换有效载荷之后开始。 如果E(ncryption Bit)未设置(0),则有效载荷不加密。
···C(ommit Bit) (1 bit) :该位用于通知密钥交换同步。它用于确保在完成SA建立之前没有接收到加密材料。这个bit可以在双方任意一端设置,并且在isakmp建立的两个阶段上均可以使用。这个值必须在第一阶段协商完成之后复位。
···A(uthentication Only Bit) (1 bit) :需要和Notify Payload一起使用,具有完整性检查,但是没有加密的信息传输。第4.8节规定,第二阶段信息交换必须在ISAKMP SA的保护下发送。 这是该策略的唯一例外。如果设置了Authentication Only位(1),那么只有认证安全服务将应用于信息交换的整个Notify有效负载,并且有效负载不会被加密。

Length (4 octets):以八位字节为单位的消息总长(报头+有效载荷)。 加密可以扩展ISAKMP消息的大小。

在ISAKM中可以添加一个或多个有效负载(Payloads),由于负载较多就不一一列举了,具体详见RFC2408。

enter image description here

IPSec VPN协商建立过程

建立过程主要分为两步,首先是主模式(Main mode)的建立,然后是快速模式(Quick mode)的建立。

enter image description here

enter image description here

数据包在此下载。

之前IPSec vpn谈到过,VPN的目的就是为了保证私密性、完整性、源认证。然而在公网上显然不能将加密信息明目张胆的发送出去,所以在传递这些业务信息之前,需要预先建立起一个安全可靠的连接来传递这些加解密的信息。而主模式就是预先建立的这个连接。

主模式(Main mode)

主模式主要的目的是建立ISAKMP SA(Internet Security Association and Key Management Protocol Security association)。为了建立起ISAKMP SA,在IKEv1 Main mode 中需要交互6个报文。这6个报文会在下面有所介绍。由于ISAKMP的建立并不像OSPF邻居认证一样,只需要password正确就能建立,而是有一整套协商的条件。所以单一的预共享密钥相同也不一定就能保证ISAKMP的建立。

主模式第1个和第2个数据包

主模式的第一个和第二个数据包主要用来协商ISAKMP策略信息,这些策略信息包括。
· 加密类型(Encryption-Algorithm)
· 密钥长度(Key-Length)
· 散列算法(Hash-Algorithm)
· DH强度(Group-Description)
· 认证模式(Authentication-Method)
· 密钥更新时间单位(Life-Type)
· 密钥时间(Life-Time)
如上部分在报文中体现如下,如果对端发送过来的ISAKMP协商信息与本地信息不符,那么将协商失败,且不会反馈本端ISAKMP配置信息。

enter image description here

主模式第3个和第4个数据包

第1和第2个数据包确认了策略之后和散列函数之后,要想加密数据还需要一个关键的参数(密钥),这个密钥正是通过DH交换而得来的。有关DH算法工作原理已超出笔者能力,有兴趣的可以参见。Diffie–Hellman key exchangeDiffie-Hellman Key Agreement Method
在报文中体现如下。

enter image description here

主模式第5个和第6个数据包

获取到彼此的密钥信息之后,就可以开始进行认证了,这部分就是加密的报文。

enter image description here

总的来说,主模式首先协商ISAKMP策略,确定双方策略一致的时候,开始使用非对称密钥算法来交换彼此的预共享密钥,当预共享密钥匹配的时候来交换彼此的加密密钥,使用这个加密的密钥来完成第5和第6的数据包的认证功能。这样就保证了私密性(数据加密),源认证(加密认证来实现),完整性(如果报文有修改ISAKMP SA无法建立)

快速模式(Quick mode)

在快速模式下主要用来建立IPSec SA,协商以下参数
· 封装方式(ESP或AH)
· 认证算法
· 传输模式(隧道模式或传输模式)
· 加密算法(业务报文的加密算法)
· DH信息
· IPSec生命周期信息
另外需要注意的就是密钥更新,密钥更新主要使用的是PSF,虽然 有周期性更新密钥的这个功能,但是如果没有启用PSF那么新生成的密钥与之前的密钥存在衍生关系,思科默认没有启用PSF功能,如果启用了PSF那么新生成的密钥与之前的密钥就不存在衍生关系,可以提供更安全的服务。
这一部分在报文中均以加密方式进行显示。

enter image description here

快速模式协商完成之后,建立起IPSec SA,开始传输加密数据。

参考文献

  1. Diffie–Hellman key exchange
  2. Diffie-Hellman Key Agreement Method
  3. Phase 1Phase 2
  4. IPSec Virtual Private Network Fundamentals–IKE and ISAKMP
  5. RFC2408
  6. RFC2409
  7. RFC4306

2017年10月13日更新