强叔侃墙 VPN篇 IPSec携手IKE,珠联璧合显神威

转载 2015年05月15日 10:38:19

密钥管家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的精彩之处还在于不出招则已、出招即能克敌;招招有戏、变化无穷,欲听详解请见下回分解。

思科认证CCNPv2.0详解第3部分 IPSEC VPN技术

-
  • 1970年01月01日 08:00

ipsec 及IKE原理

  • 2016年04月06日 10:33
  • 1MB
  • 下载

IKE SA和IPSec SA的区别

http://blog.csdn.net/jiangwlee/article/details/7395903
  • bytxl
  • bytxl
  • 2014-06-30 17:37:26
  • 2485

IPSec及IKE原理

  • 2014年11月14日 17:40
  • 691KB
  • 下载

IPSEC VPN连接建立(IKE)详解

IPSEC构建站点到站点连接的基本过程 对于站点到站点的会话,构建连接的基本过程如下: 一个VPN网关对等体发起了到另外一个远程的VPN网关对等体的会话(触发流量) 如果没有存在VP...
  • Galdys
  • Galdys
  • 2012-07-09 15:10:14
  • 3942

野蛮模式的相关种种:

作用: 对于两端IP地址不是固定的情况(如ADSL拨号上网),并且双方都希望采用预共享密钥验证方法来创建IKE SA,就需要采用野蛮模式。另外如果发起者已知回应者的策略,采用野蛮模式也能够更快地...
  • cuiyifang
  • cuiyifang
  • 2012-08-18 08:37:16
  • 2000

IKE创建SA步骤

IPsec SA 创建步骤概述 IPsec SA creation steps There are two steps on the IPsec SA creation, phas...
  • jeason29
  • jeason29
  • 2015-04-27 13:53:06
  • 1523

IPsec SA 创建步骤——IKE协议

http://hi.baidu.com/wjjuseezugdgkre/item/08e82ce8dade97226dabb80e IPsec SA creation steps There ar...
  • bytxl
  • bytxl
  • 2013-09-16 09:00:14
  • 2781

IKEv1 主模式证书方法协商的载荷交互流程

INITIATOR                                                         RESPONDER SA V-xauth V-dpd V-na...
  • xingyeping
  • xingyeping
  • 2015-12-08 19:15:39
  • 690

pluto实现分析(1)——前言、IKEv1概述、源文件概述

本文档的Copyleft归yfydz所有,使用GPL发布,可以自由拷贝,转载,转载时请保持文档的完整性,严禁用于任何商业用途。 msn: yfydz_no1@hotmail.com 来源:http:/...
  • bytxl
  • bytxl
  • 2015-09-25 10:47:48
  • 962
收藏助手
不良信息举报
您举报文章:强叔侃墙 VPN篇 IPSec携手IKE,珠联璧合显神威
举报原因:
原因补充:

(最多只允许输入30个字)