IP Sec基本原理.docx

IP Sec基本原理.docx

《IP Sec基本原理.docx》由会员分享，可在线阅读，更多相关《IP Sec基本原理.docx（11页珍藏版）》请在冰豆网上搜索。

IPSec基本原理

IPSec基本原理

IPSec 是一项标准的安全技术，它通过在数据包中插入一个预定义头部的方式，来保障OSI上层协议数据的安全性。

IPSec主要用于保护网络层（IP）数据，因此它提供了网络层的安全性。

IPsec 能够起到的功能有：

数据源认证（Dataoriginauthentication）

保护数据完整性（Dataintegrity）

保证数据私密性（Dataconfidentiality ）

防止中间人攻击（Man-in-the-Middle）

防止数据被重放（Anti-Replay ）

为IPsec 服务的总共有三个协议：

IKE （InternetKeyExchange） （ IKE 是针对密钥安全的，是用来保证密钥的安全传输、交换以及存储，主要是对密钥进行操作，并不对用户）

ESP（EncapsulatingSecurityProtocol ） （对用户数据封装）

AH（AuthenticationHeader）    （对用户数据封装）

IKE 的认证方式有三种：

Pre-SharedKeys（PSK）

PublicKeyInfrastructure（PKI）usingX.509DigitalCertificates  （PKI 是使用第三方证书做认证，叫做 CertificateAuthority（CA））

RSAencryptednonce  

虽然总共是三个协议，但分为两类：

1、IKE 是个混合协议，其中包含部分Oakley 协议以及内置在 ISAKMP 协议中的部分 SKEME 协议，所以 IKE 也可

写为ISAKMP/Oakley，它是针对密钥安全的，是用来保证密钥的安全传输、交换以及存储，主要是对密钥进行

操作，并不对用户的实际数据进行操作。

2、ESP（EncapsulatingSecurityProtocol ）和 AH（AuthenticationHeader ）主要工作是如何保护数据安全，

也就是如何加密数据，是直接对用户数据进行操作的。

  ESP 对用户数据包的封装过程如下：

（ESP 包头中使用 IP 协议号 50来标识）

AH对用户数据包的封装过程如下：

 （AH包头中使用IP 协议号51来标识）

注：

★IPSec 目前只支持 IPv4Unicast （IPv4  单播），不支持其它任何协议。

IPsecMode 分两种：

Tunnelmode  （隧道模式）

  IPsec 中的Tunnelmode 就拥有着与 GRE 相同的隧道功能，那就是将数据包原来的私有IP 地址先隐藏起来，在外部封装上公网 IP 。

Transportmode  （传输模式）

  IPsec 除了作为安全协议来为隧道提供数据保护之外，也可以自己单独作为隧道协议来提供隧道的建立，如果IPsec 不需要实现隧道功能，而只需要实现保护数据的安全功能，就只

要工作在Transportmode 即可，因为 Transport 模式的IPsec 只有安全功能而没有隧道功能，所以还要再配合其它隧道协议，最终实现完整的VPN 功能。

当数据进入路由器后，路由器是怎么工作的？

如下图

思考 那如果出接口上面有NAT地址转换  那到底是先匹配NAT还是IPSECVPN？

？

？

答：

当出接口上启用nat的时候首先会匹配nat 所以说IPSECVPN本路由器上时不能穿nat  因为当出接口匹配NAT之后就把地址转换为公网地址，

此时地址已不满足感兴趣流。

隧道分离（SplitTunneling ）

SplitTunneling 只在远程VPN（remoteVPN ）时才有，因为当远程VPN 用户的VPN

隧道建立之后，该用户的所有流量都将被发送到隧道之上，这样一来，原本用户正

常的用户，比如发往 Internet 的流量也被发到隧道上，结果就会造成远程 VPN 用户

与Internet 失去连接；为了让用户需要走 VPN 隧道的流量才被发送到隧道上，而其

它流量，还是从原来的接口发送而不被 IPsec 封装，所以需要将用户的流量分为两

类，从而区分对待，这就是隧道分离（SplitTunneling ）；其实 SplitTunneling 和非远

程VPN 有某些相同之处，非远程VPN 也有定义感兴趣流量的功能，这个功能就是指

定什么样的流量通过 VPN 传输，什么样的流量正常传输；在最终的结果是，这两个

功能在配置上是一样的

互联网密钥交换协议（IKE）:

两个阶段三个模式

  主模式          

  第一阶段：

  准备工作

  在前2条消息发送以前,发送者和接受者必须先计算出各自的cookie（可以防重放和DOS攻击）,这些cookie用于标识每个单独的协商交换消息

cookie---RFC建议将源目IP,源目端口,本地生成的随机数,日期和时间进行散列操作.cookie成为留在IKE协商中交换信息的唯一标识,实际上cookie是用来防止DOS攻击的，它把和其他设备建立IPSEC所需要的连接信息不是以缓存的形式保存在路由器里，而是把这些信息HASH成个cookie值

1&2消息

消息1---发送方向对等体发送一条包含一组或多组策略提议,在策略提议中包括5元组（加密算法,散列算法,DH,认证方法,IKESA寿命）

消息2---接受方查看IKE策略消息,并尝试在本地寻找与之匹配的策略,找到后,则有一条消息去回应

注意!

!

!

发起者会将它的所有策略发送给接受者,接受者则在自己的策略中寻找与之匹配的策略（对比顺序从优先级号小的到大的）（默认策略实际就是个模版没作用，如果认证只配置预共享的话，其他参数就会copy默认策略里的）

在1&2消息中报错可能出现的原因

1，peer路由不通

2，cryptoiskmpkey没有设置

3，一阶段的策略不匹配

3&4消息

这2条消息,用于交换DH的公开信息和随机数

两个对等体根据DH的公开信息都算出了双方相等的密植后,两个nonce连通预共享密钥生成第一个skeyID

随后便根据SKEY__ID来推算出其他几个skeyID

skeyID_d---用来协商出后续IPSECSA加密使用的密钥的

skeyID_a---为后续的IKE消息协商以及IPSECSA协商进行完整性检查（HMAC中的密钥）

skeyID_e---为后续的IKE消息协商以及IPSECSA协商进行加密

5&6消息

这2条消息用于双方彼此验证,这个过程是受skeyID_e加密保护的

为了正确生成密钥,每一个对等体必须找到与对方相对应的预共享密钥,当有许多对等体连接时,每一对对等体两端都需要配置预共享密钥,每一对等体都必须使用ISAKMP分组的源IP来查找与其对等体对应的预共享密钥（此时由于ID还没到,彼此先用HASH来彼此验证对方）

HASH认证成分－－－SKEYID_a,cookieA,cookieB，preshare_key,SApaload,转换集，策略

在5&6消息中报错可能出现的原因

1，cryptoiskmpkey设置错了

消息6--接受者处理过程

1,用skeyID_e对消息进行加密  2,用ID（源IP）查找出与共享密钥 3,skeyID_a和preshare-key等一堆东西一起来计算HASH4,和收到的HASH做比较

  第二阶段（3条）

phase2的目标是协商IPSECSA,而且只有一种模式,快速模式,快速模式的协商是受IKESA保护的

1&2消息

消息1---发送方发送一条报文,其中包含HASH,IPSEC策略提议,NONCE和可选的DH,身份ID

HASH:

是用于给接受方作完整性检查的,用于再次认证对等体（必须）HASH的成分和5－6阶段一样

IPSEC策略提议:

其中包括了安全协议,SPI,散列算法,隧道模式,IPSECSA生命周期（必须）

NONCE:

用于防重放攻击,还被用作密码生成的材料,仅当启用PFS时用到

ID:

描述IPSECSA是为哪些地址,协议和端口建立的

PFS（利用DH交换,可选）:

用了PFS后就会在第二阶段重新DH出个数据加密KEY,这个KEY和以前IKE协商出来的KEY没有任何关系,然后由这个新KEY来加密数据，只有到这个IPSECSA的生命周期后,会再次DH出新的KEY,这样,安全性就提高了（普通等ipecSA过期或密钥超时时，重新生成的数据加密密钥还是根据以阶段DH出来的skeyID_d衍生出来的）（PFS启用后，数据加密部分使用的密钥就没有了衍生的过程）

DH:

重新协商IPSECSA实使用的密钥（正常情况下IPSEC阶段使用的密钥都是由skeyID_d衍生而来,密钥之间都有一定的关系,就算IPSECSA超时,新的KEY还是和skeyID_d有一定的关系）

在1&2消息中报错可能出现的原因

1，ipsectrasport不匹配

2，感兴趣流不对称

消息2---使用相同的消息进行相应

3消息

发送方发送第三条消息,其中包含一个HASH,其作用时确认接受方的消息以及证明发送方处于Active状态（表示发送方的第一条消息不是伪造的）

管理连接的状态

状态 解释

MM_NO_STATE     当使用主模式的时候，ISAKMPSA处于早期状态，还没有完成；

MM_SA_SETUP 当使用主模式的时候，这个策略参数已经成功地在对等设备之间协商了

MM_KEY_EXCH 当使用主模式的时候，对等体设备已经执行了DH，并建立了一个共享的密钥，但是设备验证还没有发生

MM_KEY_AUTH     当使用主模式的时候，对等体设备已经通过了验证，将会过渡到QM_IDLE状态

AG_NO_STATE 当使用积极模式的时候，ISAKMPSA处于早期状态，还没有完成；

AG_INIT_EXCH     积极模式的第一个阶段已经完成，但是设备验证还没有执行

AG_AUTH 当使用积极模式的时候，对等体设备已经通过了验证，将会过渡到QM_IDLE状态

QM_IDLE 管理连接已经被构建，可以用于ISAKMP/IKE阶段2期间来构建数据连接。

主模式和野蛮模式

两种模式的区别

1、野蛮模式协商比主模式协商更快。

主模式需要交互6个消息，野蛮模式只需要交互3个消息。

2、主模式协商比野蛮模式协商更严谨、更安全。

因为主模式在5、6个消息中对ID信息进行了加密。

而野蛮模式由于受到交换次数的限制，ID信息在1、2个消息中以明文的方式发送给对端。

即主模式对对端身份进行了保护，而野蛮模式则没有。

3、两种模式在确定预共享密钥的方式不同。

主模式只能基于IP地址来确定预共享密钥。

而积极模式是基于ID信息（主机名和IP地址）来确定预共享密钥。

两种模式的应用场合

在实际应用中，一般情况下，如果两端设备都是公网固定IP地址（至少一端是固定IP地址）这种接入方式、且要实现设备之间点对点的环境，就采用主模式来协商。

对于两端IP地址不是固定的情况（如ADSL拨号上网），并且双方都希望采用预共享密钥验证方法来创建IKESA，就采用野蛮模式。

另外如果发起者已知回应者的策略，采用野蛮模式能够更快地创建IKESA。

为什么两边都是主机名的时候，就一定要用野蛮模式来协商呢？

在两边都是主机名的时候，如果用主模式的话，就会出现根据源IP地址找不到预共享密钥的情况，以至于不能生成SKEYID。

1、因为主模式在交换完3、4消息以后，需要使用预共享密钥来计算SKEYID，但是由于双方的ID信息在消息5、6中才会被发送，此时主模式的设备只能使用消息3、4中的源IP地址来找到与其对应的预共享密钥；如果主模式采用主机名方式，主机名信息却包含在消息5、6中，而IPSEC双方又必须在消息5、6之前找到其相应的预共享密钥，所以就造成了矛盾。

2、在野蛮模式中，ID信息（IP地址或者主机名）在消息1、2中就已经发送了，对方可以根据ID信息查找到对应的预共享密钥，从而计算出SKEYID。