【防火墙技术连载26】强叔侃墙 VPN篇 IPSec携手IKE,珠联璧合显神威

digest [复制链接]
发表于 : 2014-7-10 12:08:09 最新回复:2018-04-04 10:17:54
35273 34
强叔侃墙
强叔侃墙 官方号

密钥管家IKE登场

上回说到手工方式的IPSec VPN帮助天地会解决了总舵和分舵之间秘密通信的问题,但随着分舵数量的增加新的问题又出现了。手工方式下防火墙的加密和验证所使用的密钥都是手工配置的,为了保证IPSec VPN的长期安全,需要经常修改这些密钥。分舵数量越多,密钥的配置和修改工作量越大。随着天地会的壮大,IPSec VPN的维护管理工作越来越让人吃不消了。
为了降低IPSec VPN管理工作量,天地会总舵主再访高人寻求灵丹妙药。灵丹已练,妙药天成――原来IPSec协议框架中早就考虑了这个问题――智能的密钥管家IKE(Internet Key Exchange)协议可以帮助解决这个问题。IKE综合了三大协议:ISAKMP(Internet Security Association and Key Management Protocol)、Oakley协议和SKEME协议。ISAKMP主要定义了IKE伙伴(IKE Peer)之间合作关系(IKE SA,跟IPSec SA类似)的建立过程。Oakley协议和SKEME协议的核心是DH(Diffie-Hellman)算法,主要用于在Internet上安全地分发密钥、验证身份,以保证数据传输的安全性。有了IKE加盟,IPSec VPN的安全和管理问题不再困扰天地会,各地分舵申请建立VPN的流程终于可以进入“实施”状态了。

揭开ISAKMP本来面目

IKE协议的终极目标是通过协商在总舵和分舵之间动态建立IPSec SA,并能够实时维护IPSec SA。为建立IPSec SA而进行的IKE协商工作是由ISAKMP报文来完成的,所以在部署IKE之前,强叔先领大家认识一下ISAKMP报文。ISAKMP报文封装如下:


 IP报文头

  • 源地址src:本端发起IKE协商的IP地址,可能是接口IP地址,也可能是通过命令配置的IP地址。
  • 目的IP地址Dst:对端发起IKE协商的IP地址,由命令配置。

UDP报文头
IKE协议使用端口号500发起协商、响应协商。在总舵和分舵都有固定IP地址时,这个端口在协商过程中保持不变。当总舵和分舵之间有NAT设备时(NAT穿越场景),IKE协议会有特殊处理(后续揭秘)。
ISAKMP报文头

  • Initiator’s Cookie(SPI)和responder’s Cookie(SPI):在IKEv1版本中为Cookie,在IKEv2版本中Cookie为IKE的SPI,唯一标识一个IKE SA。
  • Version:IKE版本号1
  • Exchange Type:IKE定义的交互类型2。交换类型定义了ISAKMP消息遵循的交换顺序。
  • Next Payload:标识消息中下一个载荷的类型。一个ISAKMP报文中可能装载多个载荷,该字段提供载荷之间的“链接”能力。若当前载荷是消息中最后一个载荷,则该字段为0。
  • Type Payload:载荷类型,ISAKMP报文携带的用于协商IKE SA和IPSec SA的“参数包”。载荷类型有很多种,不同载荷携带的“参数包”不同。不同载荷的具体作用我们后面会结合抓包过程逐一分析。
    说明:
    1:IKE诞生以来,有过一次大的改进。老的IKE被称为IKEv1,改进后的IKE被称为IKEv2。二者可以看做是父子关系,血脉相承,基本功能不变;但青胜于蓝,后者有了长足的进步。
    2:IKEv1版本中可以在交换类型字段查看协商模式,阶段1分为两种模式:主模式和野蛮模式,阶段2采用快速模式。主模式是主流技术,野蛮模式是为解决现实问题而产生的。IKEv2版本中定义了查看创建IKE SA和CHILD SA(对应IKEv1的IPSec SA)的IKE_SA_INIT、IKE_AUTH(创建第一对CHILD SA)、CREATE_CHILD_SA(创建后续的CHILD SA)。
    IKEv1和IKEv2的精华之处正是本文的重点,各位看官莫急,容强叔一一道来。

IKEv1小试牛刀

IKE最适合于在总舵和众多分舵之间建立IPSec VPN的场景,分舵越多IKE的优势越能凸显。为了讲解方便,这里仅给出总舵和一个分舵之间建立IPSec VPN的组网图。


 
相比手工方式,IKE方式仅增加了两步:配置IKE安全提议和IKE对等体。IKE安全提议主要用于配置建立IKE SA用到的加密和验证算法。IKE对等体主要配置IKE版本、身份认证和交换模式。 

 

配置项

网关A

网关B

IKE安全提议

ike proposal 10

ike proposal 10

IKE对等体

ike peer b

 ike-proposal 10

 undo version 2      //IKEv1

exchange-mode main//主模式(缺省)

 remote-address 2.2.3.2//对端发起IKE协商的地址

 pre-shared-key tiandihui2

ike peer a

 ike-proposal 10

undo version 2      //IKEv1

exchange-mode main//主模式(缺省)

remote-address 1.1.1.1//对端发起IKE协商的地址

 pre-shared-key tiandihui2

ACL

acl number 3001

rule 5 permit ip source 192.168.0.0 0.0.0.255 destination 172.16.2.0 0.0.0.255

acl number 3000

rule 5 permit ip source 172.16.2.0 0.0.0.255 destination 192.168.0.0 0.0.0.255

IPSec安全提议

ipsec proposal a

transform esp

 encapsulation-mode tunnel

 esp authentication-algorithm md5

 esp encryption-algorithm des

ipsec proposal a

transform esp

 encapsulation-mode tunnel

 esp authentication-algorithm md5

 esp encryption-algorithm des

IPSec安全策略

ipsec policy policy1 11 isakmp

 security acl 3001

 proposal a

 ike-peer b

ipsec policy policy1 1 isakmp

 security acl 3000

 proposal a

 ike-peer a

应用IPSec安全策略

interface GigabitEthernet0/0/1

ip address 1.1.1.1 255.255.255.0

ipsec policy policy1

interface GigabitEthernet0/0/1

ip address 2.2.3.2 255.255.255.0

ipsec policy policy1

 

说明:两条红色命令表示本例采用了IKEv1版本主模式。缺省同时开启IKEv1和IKEv2,关闭IKEv2后采用IKEv1版本进行协商。
配置完成之后,总舵和分舵之间有互访数据流时即可触发建立IPSec VPN隧道,下面强叔通过抓包来为大家详解一下IKEv1的精妙之处。

IKEv1招式拆解

IKEv1版本分两个阶段来完成动态建立IPSec SA的任务:
阶段1-建立IKE SA:阶段1采用主模式或野蛮模式协商。
阶段2-建立IPSec SA:阶段2此采用快速模式协商。
下面先介绍主模式+快速模式下的IPSec SA建立过程。

阶段1-建立IKE SA(主模式)

主模式下IKEv1采用3个步骤6条ISAKMP消息建立IKE SA。下面以网关A主动发起IKE协商为例进行讲解。
 

 


 
1. 协商IKE安全提议。
协商分两种情况:

  • 发起方的IKE Peer中引用了IKE Proposal
  • 发起方的IKE peer中没有引用IKE Proposal

二种情况下响应方都会在自己配置的IKE安全提议中寻找与发送方相匹配的IKE安全提议,如果没有匹配的安全提议则协商失败。IKE Peer双方安全提议匹配的原则为协商双方有相同的加密算法、认证算法、身份认证方法和DH组标识(不包括IKE SA生存周期)。
说明:通过IKEv1协议协商建立IPSec安全联盟时,采用本地生存周期和对端生存周期中较小的一个,不必保证隧道两端设备配置的生存周期相同(sa duration)。
通过抓包可以看出ISAKMP消息的SA载荷中携带用于协商的IKE安全提议。以消息1为例:


 
2. 使用DH算法交换密钥材料,并生成密钥。
网关A和B利用ISAKMP消息的Key Exchange和nonce载荷交换彼此的密钥材料。Key Exchange用于交换DH公开值,nonce用于传送临时随机数。由于DH算法中IKE Peer双方只交换密钥材料,并不交换真正的共享密钥,所以即使黑客窃取了DH值和临时值也无法计算出共享密钥,这一点正是DH算法的精髓所在。从抓包中可以看到IKE Peer双方交换密钥材料,以消息3为例:


 
密钥材料交换完成后,IKE Peer双方结合自身配置的身份验证方法各自开始复杂的密钥计算过程(预共享密钥或数字证书都会参与到密钥计算过程中),最终会产生三个密钥:

  • SKEYID_a:ISAKMP消息完整性验证密钥――谁也别想篡改ISAKMP消息了,只要消息稍有改动,响应端完整性检查就会发现!
  • SKEYID_e:ISAKMP消息加密密钥――再也别想窃取ISAKMP消息了,窃取了也看不懂!

以上两个密钥保证了后续交换的ISAKMP消息的安全性!

  • SKEYID_d:用于衍生出IPSec报文加密和验证密钥――最终是由这个密钥保证IPSec封装的数据报文的安全性!

整个密钥交换和计算过程在IKE SA超时时间的控制下以一定的周期进行自动刷新,避免了密钥长期不变带来的安全隐患。
3. 身份认证
IKE Peer通过两条ISAKMP消息(5、6)交换身份信息,进行身份认证。目前有两种身份认证技术比较常用:

  • 预共享密钥方式(pre-share):设备的身份信息为IP地址或名称。
  • 数字证书方式:设备的身份信息为证书和通过证书私钥加密的部分消息Hash值(俗称签名)。

以上身份信息都由SKEYID_e进行加密,所以在抓包中我们只能看到标识为“Encrypted”的ISAKMP消息,看不到消息的内容(身份信息)。以消息5为例:


 
预共享密钥是最简单、最常用的身份认证方法。这种方式下设备的身份信息可以用IP地址或名称(包括FQDN和USER-FQDN两种形式)来标识。当IKE Peer两端都有固定IP地址的时候,一般都用IP地址作为身份标识;当一端为动态获取IP地址的时候,没有固定IP地址的一端只能用名称来标识。本篇强叔给大家展示的案例为前者,后者晚些再讲。
这里有个小问题提醒大家关注:
总舵收到分舵1发来的身份信息后,需要用密钥(SKEYID_a和SKEYID_e)进行完整性验证和解密,只有先找到正确的预共享密钥才能计算出这两个密钥。但总舵网关为每个IKE Peer都配置了一个预共享密钥。怎么找呢?此时只能根据IKE Peer发来的ISAKMP报文的源IP地址(src)来查找预共享密钥,只要报文源地址与本端IKE Peer视图下remote-address命令配置的IP地址一致,就认为该视图下配置的pre-shared-key是分舵1的预共享密钥。
以上是IPSec协议内部处理过程,不需要大家操心。大家只要记住在IKE Peer两端都有固定IP地址的场景下,remote-address命令配置的IP地址要跟对端发起IKE协商的IP地址保持一致即可。这个IP地址的作用不仅仅是指定了隧道对端的IP地址,还参与了预共享密钥的查找。
阶段1协商完成后,进入阶段2。

阶段2-建立IPSec SA

在阶段2中IKEv1采用快速交换模式通过3条ISAKMP消息建立IPSec SA。由于快速交换模式使用IKEv1阶段1中生成的密钥SKEYID_e对ISAKMP消息进行加密,所以我们抓到的报文都是加密的,看不到载荷里面的具体内容。故下面只能文字介绍一下每一步的作用。
下面以网关A发起IPSec协商为例进行讲解。
 


 
1. 发起方发送IPSec安全提议、被保护的数据流(ACL)和密钥材料给响应方。
2. 响应方回应匹配的IPSec安全提议、被保护的数据流,同时双方生成用于IPSec SA的密钥。
IPSec对等体两端协商IPSec安全提议的过程跟协商IKE安全提议的过程类似,不再赘述。
IKEv1不协商ACL规则,建议两端设备配置的ACL规则互为镜像,避免IPSec SA协商失败。
IPSec对等体两端交换密钥材料(SKEYID_d、SPI和协议1、nonce等参数),然后各自进行密钥计算生成用于IPSec SA加密验证的密钥,这样可以保证每个IPSec SA都有自己独一无二的密钥。由于IPSec SA的密钥都是由SKEYID_d衍生的,一旦SKEYID_d泄露将可能导致IPSec VPN受到侵犯。为提升密钥管理的安全性,IKE提供了PFS(完美向前保密)功能。启用PFS后,在进行IPSec SA协商时会进行一次附加的DH交换,重新生成新的IPSec SA密钥,提高了IPSec SA的安全性。
说明:1、协议指AH和/或ESP协议。
3. 发起方发送确认结果。
协商完成后发送方开始发送IPSec(ESP)报文。
 


检查IPSec VPN状态信息
以总舵显示信息为例。

  • 在总舵和分舵上查看IKE SA的建立情况。
    <FW_A> display ike sa
    current ike sa number: 2
    ---------------------------------------------------------------------
    conn-id    peer                    flag          phase vpn
    ---------------------------------------------------------------------
    40129      2.2.3.2                 RD|ST         v1:2  public
    40121      2.2.3.2                 RD|ST         v1:1  public
    这里统一显示了IKE SA(v1:1)和IPSec SA(v1:2)的状态,RD表示SA状态为READY。IKE Peer之间只有一个IKE SA,IKE SA是双向逻辑连接(不区分源和目的)。
  • 在总舵和分舵上查看IPSec SA的建立情况。
    <FW_A> display ipsec sa brief
    current ipsec sa number: 2
    current ipsec tunnel number: 1
    ---------------------------------------------------------------------
    Src Address     Dst Address     SPI        Protocol  Algorithm
    ---------------------------------------------------------------------
    1.1.1.1         2.2.3.2         4090666525 ESP       E:DES;A:HMAC-MD5-96;
    2.2.3.2         1.1.1.1         2927012373 ESP       E:DES;A:HMAC-MD5-96;
    IPSec SA是单向的(区分源和目的),两个方向的IPSec SA共同组成一条IPSec隧道。
    说明:一般来说一条数据流对应一个IPSec SA。但当IPSec同时采用了ESP+AH封装时,一条数据流会对应两个IPSec SA。
  •  在总舵和分舵上查看会话表。
    <FW_A > display firewall session table
    11:01:45  2014/07/08
     Current Total Sessions : 6
      esp  VPN:public --> public 1.1.1.1:0-->2.2.3.2:0
      icmp  VPN:public --> public 172.16.2.2:7264-->192.168.0.2:2048
      icmp  VPN:public --> public 172.16.2.2:7520-->192.168.0.2:2048
      icmp  VPN:public --> public 172.16.2.2:7776-->192.168.0.2:2048
      icmp  VPN:public --> public 172.16.2.2:8032-->192.168.0.2:2048
      icmp  VPN:public --> public 172.16.2.2:8288-->192.168.0.2:2048
    防火墙会为IPSec VPN建立了会话表(1.1.1.1:0-->2.2.3.2:0)。

下面简单介绍一下野蛮模式

配置命令exchange-mode aggressive即可将IKEv1的协商模式改为野蛮模式。抓包看一下野蛮模式的情况:

 

野蛮模式只用了3条ISAKMP消息就完成了阶段1的协商过程,阶段2仍旧是快速模式不变。
 


发起方和响应方把IKE安全提议、密钥相关信息和身份信息一股脑地全放在一个ISAKMP消息中发送给对方,IKE协商效率提高了。但由于身份信息是明文传输,没有加密和完整性验证过程,IKE SA的安全性降低了。既然这样不够安全,为什么野蛮模式还会出现?
在IPSec VPN出现的早期,由于主模式+预共享密钥身份认证方式下,IPSec需要通过对端的IP地址来在本地查找预共享密钥(主模式中已经详细解释了这个问题)。这种密钥查找方式在对端没有固定IP地址的情况下(比如IPSec NAT穿越场景,网络出口动态获取IP地址场景)行不通。此时,野蛮模式可以“野蛮”地解决这个问题。野蛮模式中“身份信息”没有加密,IPSec就直接用对端发送来的身份信息来查找预共享密钥即可。所以在IPSec VPN应用初期,野蛮模式主要用于解决没有固定IP地址的节点部署IPSec VPN的问题。现在,IPSec VPN解决这个问题有很多方法,不安全的野蛮模式已经不是最好的选择了。具体方法待后续再呈现给大家。

IKEv2应运而生

IKEv1似乎已经很完美了,但用得久了仍旧会发现不尽人意之处。

  • 协商建立IPSec SA的时间太长

IKEv1主模式协商一对IPSec SA,需要6(协商IKE SA)+3(协商IPSec SA)=9条消息。
IKEv1野蛮模式协商一对IPSec SA,需要3(协商IKE SA)+3(协商IPSec SA)=6条消息。

  • 不支持远程用户接入

IKEv1不能对远程用户进行认证。若想支持远程用户接入,只能借助L2TP,通过PPP来对远程用户进行AAA认证。
这些问题怎么解决呢?办法总比问题多!IKEv2中完美的解决了这些问题。

IKEv2相比IKEv1: 

  • 协商建立IPSec SA的速度大大提升
    正常情况IKEv2协商一对IPSec SA只需要2(协商IKE SA)+2(协商IPSec SA)=4条消息。后续每建立一对IPSec SA只会增加2条消息。
  • 增加了EAP(Extensible Authentication Protocol)方式的身份认证。
    IKEv2通过EAP协议解决了远程接入用户认证的问题,彻底摆脱了L2TP的牵制。目前IKEv2已经广泛应用于远程接入网络中了。今天强叔只介绍IKEv2的基本协商过程,EAP认证留待后续再讲。

IKEv2的配置思路与IKEv1完全相同,只是细节稍有不同:

 

说明:红色命令与IKEv1不同。缺省情况下,防火墙同时开启IKEv1和IKEv2协议。本端发起协商时,采用IKEv2,接受协商时,同时支持IKEv1和IKEv2。可以不关闭IKEv1。
IKEv2协商IPSec SA的过程跟IKEv1有很大差别:
1. 初始交换4条消息同时搞定IKE SA和IPSec SA。
初始交换包括IKE安全联盟初始交换(IKE_SA_INIT交换)和IKE认证交换(IKE_AUTH交换)。


 
 
第一个消息对(IKE_SA_INIT):负责IKE安全联盟参数的协商,包括IKE Proposal,临时随机数(nonce)和DH值。

 
SA载荷主要用来协商IKE Proposal。


 
KE(Key Exchange)载荷和Nonce载荷主要用来交换密钥材料。


 
IKEv2通过IKE_SA_INIT交换后最终也生成三类密钥:
SK_e:用于加密第二个消息对。
SK_a:用于第二个消息对的完整性验证。
SK_d:用于为Child SA(IPSec SA)衍生出加密材料。
第二个消息对(IKE_AUTH):负责身份认证,并创建第一个Child SA(一对IPSec SA)。
目前三种身份认证技术比较常用:

  • 预共享密钥方式(pre-share):设备的身份信息为IP地址或名称。
  • 数字证书方式:设备的身份信息为证书和通过证书私钥加密的部分消息Hash值(签名)。
  • EAP方式:采用EAP认证的交换过程属于扩展交换的内容,将在后面讲解。

以上身份信息都通过SKEYID_e加密。
创建Child SA时,当然也要协商IPSec安全提议、被保护的数据流。IKEv2通过TS载荷(TSi和TSr)来协商两端设备的ACL规则,最终结果是取双方ACL规则的交集(这点跟IKEv1不同,IKEv1没有TS载荷不协商ACL规则)。
当一个IKE SA需要创建多对IPSec SA时,例如两个IPSec对等体之间有多条数据流的时候,需要使用创建子SA交换来协商后续的IPSec SA。
2. 子SA交换2条消息建立一对IPSec SA。
 


子SA交换必须在IKE初始交换完成之后才能进行,交换的发起者可以是IKE初始交换的发起者,也可以是IKE初始交换的响应者。这2条消息由IKE初始交换协商的密钥进行保护。
IKEv2也支持PFS功能,创建子SA交换阶段可以重新进行一次DH交换,生成新的IPSec SA密钥。

IKEv1和IKEv2大PK

IKEv1和IKEv2的细节写了这么多,现在总结一下二者的异同点吧: 

功能项

IKEv1

IKEv2

IPSec SA建立过程

分两个阶段,阶段1分两种模式:主模式和野蛮模式,阶段2为快速模式。

主模式+快速模式需要9条信息建立IPSec SA

野蛮模式+快速模式需要6条信息建立IPSec SA

不分阶段,最少4条消息即可建立IPSec SA

ISAKMP

二者支持的载荷类型不同

认证方法

预共享密钥

数字证书

数字信封(较少使用)

预共享密钥

数字证书

EAP

数字信封(较少使用)

IKE SA完整性算法

不支持

支持

PFS

支持

支持

远程接入

通过L2TP over IPSec来实现

支持

 

显然IKEv2以其更加快捷、更加安全的服务胜出,长江后浪推前浪又成为了没有任何悬念的事实。 

IPSec协议框架总结

安全协议(AHESP)、加密算法(DES3DESAES)、验证算法(MD5SHA1SHA2)、IKEDH,好多的缩写,大家搞清楚他们之间的关系了么?强叔做了一下总结,看看能否帮助大家:

l  安全协议(AHESP)――IP报文的安全封装。穿上AH/ESP马甲的IP报文称为IPSec报文。此“马甲”并非一般的马甲,是交织了“加密”和“验证”算法的刀枪不入的“软猬甲”。

说明:AH封装的验证范围实际要还更大一些,包括新的IP头。

l  加密算法(DES3DESAES)――IPSec报文的易容之术。IPSec数据报文采用对称加密算法进行加密,但只有ESP协议支持加密,AH协议不支持。另外,IKE协商报文也会进行加密。

l  验证(MD5SHA1SHA2)――IPSec报文的验明正身之法。加密后的报文经过验证算法处理生成数字签名,数字签名填写在AHESP报文头的完整性校验值ICV字段发送给对端;在接收设备中,通过比较数字签名进行数据完整性和真实性验证。

l  IKE――手握密钥管理大权的贴心管家。IPSec使用IKE协议在发送、接收设备之间安全地协商密钥、更新密钥。

l  DH算法――贴心管家的铁算盘。DH被称为公共密钥交换方法,它用于产生密钥材料,并通过ISAKMP消息进行交换,并最终在收发两端计算出加密密钥和验证密钥。

这些概念一一梳理过来,强叔不得不感叹IPSec协议设计者的强大――这么多新的老的协议、算法拼接起来如此天衣无缝,自此Internet的险恶被屏蔽在隧道之外!为了方便大家记忆这些缩写,强叔用一张简图概括之:

 

写到这里,强叔心情舒畅,暗自为天地会网络的顺利推动得意。可是问题又来了――将IKE应用于IPSec VPN之后,那些有固定公网IP地址的大中型分舵的通信问题很快就解决了。但一些小型分舵IP地址不固定或只有私网IP地址,用常规的IKE方式部署IPSec VPN行不通。这种情况下怎么办呢?别担心,IKE的精彩之处还在于不出招则已、出招即能克敌;招招有戏、变化无穷,欲听详解请见下回分解。

 

 

上一篇 VPN篇 Internet危机四伏,IPSec闪亮登场

下一篇 VPN篇 IPSec模板海纳百川,不定对端有容乃大

汇总贴】 

本帖被以下专题推荐:

  • x
  • 常规:

点评 回复

跳转到指定楼层
强叔侃墙
强叔侃墙 官方号 发表于 2014-8-13 11:19:44 已赞(1) 赞(1)

引用 11 楼

我明白了,其实关键一点就是用IKE就不用人工设置密钥了,密钥是自动生成和刷新的,人就不用关注了是这个意思吧?
m00117483 发表于 2014-07-23 16:57

是的,就是这个意思!
  • x
  • 常规:

点评 回复

强叔侃墙
强叔侃墙 官方号 发表于 2014-7-22 15:53:16 已赞(0) 赞(0)

引用 9 楼

手工方式下防火墙的加密和验证所使用的密钥都是手工配置的,为了保证IPSec VPN的长期安全,需要经常修改这些密钥。分舵数量越多,密钥的配置和修改工作量越大。随着天地会的壮大,IPSec VPN的维护管理工作越来越让人吃不消了。
请问楼主,IKE是如何解决上面说的这些问题的?似乎下文中依然看不明白
m00117483 发表于 2014-07-16 16:26

下文中没有重点讲这个问题。IKE方式下安全联盟跟密钥都是通过协商生成的。IKE安全联盟和IPSec安全联盟都只能在一定的时间内存在,这个时间被称为生存周期。在生存周期耗尽前IKE会重新协商IPSec安全联盟或重新协商IKE安全联盟和IPSec安全联盟,这个过程中自然也会重新协商安全联盟使用的加密和验证密钥。而手工配置的密钥是不会自动更新的,若觉得安全联盟存在时间太长了不安全,就只有手工修改了。

  • x
  • 常规:

点评 回复

m00342832
m00342832   发表于 2014-7-23 16:57:50 已赞(0) 赞(0)

Reply 10 #

我明白了,其实关键一点就是用IKE就不用人工设置密钥了,密钥是自动生成和刷新的,人就不用关注了是这个意思吧?
  • x
  • 常规:

点评 回复

周中斌
周中斌   发表于 2014-9-19 16:24:53 已赞(0) 赞(0)

以前只知道有ipsec的地方就有IKE这个东东,看完这个贴后,总算是对IKE有了入门级的了解

  • x
  • 常规:

点评 回复

shadowboy
shadowboy   发表于 2014-7-10 13:33:48 已赞(0) 赞(0)

支持强叔。。。。。。。。。。。。。。。
  • x
  • 常规:

点评 回复

安宁庄前街东口
安宁庄前街东口   发表于 2014-7-10 14:33:25 已赞(0) 赞(0)

支持强叔~~IKE这部分一直都搞不清楚,各种算法各种密钥,总感觉深奥无比。这次强叔结合抓包来讲,由浅入深,生动直观,迫不及待的先顶一下然后再慢慢学习!

  • x
  • 常规:

点评 回复

wangbenlie
wangbenlie   发表于 2014-7-10 22:07:46 已赞(0) 赞(0)

感谢分享!

  • x
  • 常规:

点评 回复

z00340711
z00340711   发表于 2014-7-11 17:18:08 已赞(0) 赞(0)

内容不错,但看上去仍有点雾里看花的感觉。IPSEC技术之所以复杂难懂,关键在于整个流程涉及多个协商步骤,多种信息交互,多个验证和加密过程,同时每个验证/加密的报文对象(服务对象)也都不完全一样。导致初学者很容易迷糊、似懂非懂。

所以,楼主能否用一个流程图或者分层结构图那样的方式,将IPSEC所涉及的这些协商步骤、信息交互,以及每个步骤报文验证/加密之间的逻辑关系说清楚。这些东西清楚之后,IPSEC基本就掌握了。

  • x
  • 常规:

点评 回复

强叔侃墙
强叔侃墙 官方号 发表于 2014-7-11 17:39:16 已赞(0) 赞(0)

回复 5 楼

首先感谢您的关注。您说的有道理,但IPSec中包括的内容太多,逻辑关系复杂,目前我们还不能驾驭用一张图来呈现IPSec中所有的元素,后面我们会尝试做一下。下面是IPSec协议框架的简版示意图,请您先参考。我们后面还会有一系列的贴子来讲述IPSec,也希望您继续关注,如有问题也就可以在论坛上和我们讨论,再次感谢。

 

  • x
  • 常规:

点评 回复

发表回复
您需要登录后才可以回帖 登录 | 注册

警告 内容安全提示:尊敬的用户您好,为了保障您、社区及第三方的合法权益,请勿发布可能给各方带来法律风险的内容,包括但不限于政治敏感内容,涉黄赌毒内容,泄露、侵犯他人商业秘密的内容,侵犯他人商标、版本、专利等知识产权的内容,侵犯个人隐私的内容等。也请勿向他人共享您的账号及密码,通过您的账号执行的所有操作,将视同您本人的行为,由您本人承担操作后果。详情请参看“隐私声明
如果附件按钮无法使用,请将Adobe Flash Player 更新到最新版本!
登录参与交流分享

登录参与交流分享

登录