IPSec的NAT穿越详细介绍

IPSec的NAT穿越详细介绍
IPSec的NAT穿越详细介绍

IPSec的NAT穿越详细介绍

1. 前言

IPSec提供了端到端的IP通信的安全性,但在NAT环境下对IPSec的支持有限,AH协议是肯定不能进行NAT的了,这和AH设计的理念是相违背的;ESP协议在NAT环境下最多只能有一个VPN主机能建立VPN通道,无法实现多台机器同时在NAT环境下进行ESP通信。关于IPSec在NAT环境下的需求问题在RFC3715中进行了描述。

NAT穿越(NATTraversal,NAT-T)就是为解决这个问题而提出的,在RFC3947,3948中定义,在RFC4306中也加入了NAT-T的说明,但并没废除RFC3947,3948,只是不区分阶段1和阶段2。该方法将ESP协议包封装到UDP包中(在原ESP协议的IP包头外添加新的IP头和UDP 头),使之可以在NAT环境下使用的一种方法,这样在NAT的内部网中可以有多个IPSec 主机建立VPN通道进行通信。

2. IKE协商使用UDP封装

RFC3947主要描述如何检测是否存在NAT设备,并如何在IKE中协商使用UDP来封装IPSec 数据包。

本帖隐藏的内容

2.1 检测

功能是检测通信中是否存在NAT设备和对方是否支持NAT-T。

正常的IKE协商使用的UDP包的源和目的端口都是500,如果存在NAT设备,大多数情况下该UDP包的源端口部分会改变,只有少数情况不改。接收方如果发现UDP源端口不是500,那可以确定数据是经过了NAT设备。另外,确定NAT的位置也是重要的,在检测对方失效(DPD)时,应该尽量由在NAT设备后面的一方主动进行DPD探测,而从另一方探测有可能会失败。检测对方是否支持NAT-T是通过交换vendor ID载荷来实现的,如果自身支持NAT-T,在IKE 开始交互就要发送这种载荷,载荷内容是“RFC 3947”的MD5值,也就是十六进制的“4a131c81070358455c5728f20e95452f”。

判断是否在NAT设备后面是通过发送NAT-D(NAT-Discovery)载荷来实现的,载荷内容是IP 地址和UDP端口的HASH值,NAT-D载荷格式如下,载荷类型值是20:

1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8

+---------------+---------------+---------------+---------------+

| Next Payload | RESERVED | Payload length |

+---------------+---------------+---------------+---------------+

~ HASH of the address and port ~

+---------------+---------------+---------------+---------------+

HASH值的计算方法如下,具体HASH是根据协商来确定的:

HASH = HASH(CKY-I | CKY-R | IP | Port)

CKY-I和CKY-R是协商发起方和响应方的cookie。

协商中双方各自至少要发送两个NAT-D载荷,第一个载荷是对方的地址和端口的HASH,后面的载荷是自己的地址和端口,如果本地有多个地址,则要发送多个载荷,包括所有地址和

端口的HASH,对方接收到载荷后重新根据收到的包的实际地址端口来计算HASH值后进行比较,就可以知道是否有NAT 设备以及哪一方在NAT设备之后了。

有些的NAT设备具有端口固定的功能,也就是进行NAT转换后只改变地址而不改变端口,而且针对IKE通信使用cookie来区分内部各个 IPSec设备的IKE连接,后续IKE协商如果继续用500端口协商就会出现问题。对于这类设备,解决方法是改变IKE协商端口从500到4500,因为这些设备只对500端口进行特殊处理而不对4500端口处理。在协商时,发现了自己在NAT设备之后的一方立即要将协商端口从500该为4500,源和目的端口都是4500,此时协商数据包格式为:

IP UDP(4500,4500) HDR*, IDii, [CERT, ] SIG_I

其中“non-ESP marker”为4字节,在后面介绍其值。

接收方接收此包解密并认证通过后,要改变自己的状态将原来处理500端口状态改为处理4500端口,后续的协商过程都使用4500端口进行,以后500端口收到的不是新协商的包都将被丢弃,协商过程为:

Initiator Responder

------------ ------------

UDP(500,500) HDR, SA, VID -->

<-- UDP(500,X) HDR, SA, VID

UDP(500,500) HDR, KE, Ni,

NAT-D, NAT-D -->

<-- UDP(500,X) HDR, KE, Nr,

NAT-D, NAT-D

UDP(4500,4500) HDR*#, IDii,

[CERT, ]SIG_I -->

<-- UDP(4500,Y) HDR*#, IDir,

[ CERT, ], SIG_R

如果支持NAT-T,在ID载荷中的端口值要设置为0。

2.2 UDP封装协商

UDP封装方式有两种,一种是UDP通道模式封装,一种是UDP传输模式封装,取值为:

UDP-Encapsulated-Tunnel 3

UDP-Encapsulated-Transport 4

当发现存在NAT设备后,就要选择这两者模式中的一种,而一般正常的通道模式封装和传输模式封装取值分别为1和2。在协商封装模式时,提议一方或者是提议NAT模式下的3、4,或者是提议非NAT下的1、2,而不应该同时提议1、2、3、4这四种模式。

由于在计算TCP/UDP校验和的时候要用到IP地址部分,因此需要知道对方的实际原始地址值,因此协商时双方要发送各自的原始地址,使用 NAT-OA (NAT Original Address)载荷进行发送,对应发起方来说,NAT-OA载荷中的地址就是自己实际地址和对方的公网地址,而对于响应方来说,NAT-OA载荷中的对方的公网地址和自己的实际地址。

NAT-OA载荷格式为,这种载荷的类型为21:

1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8

+---------------+---------------+---------------+---------------+

| Next Payload | RESERVED | Payload length |

+---------------+---------------+---------------+---------------+

| ID Type | RESERVED | RESERVED |

+---------------+---------------+---------------+---------------+

| IPv4 (4 octets) or IPv6 address (16 octets) |

+---------------+---------------+---------------+---------------+

其中ID Type只能为ID_IPV4_ADDR或者ID_IPV6_ADDR,保留字段值都要置0。

值得注意的是只是在传输模式下需要传NAT-OA载荷,但通道模式下就没必要传了,具体原因看下节UDP封装方法后再说明。

交换过程如下:

Initiator Responder

------------ ------------

HDR*, HASH(1), SA, Ni, [, KE]

[, IDci, IDcr ]

[, NAT-OAi, NAT-OAr] -->

<-- HDR*, HASH(2), SA, Nr, [, KE]

[, IDci, IDcr ]

[, NAT-OAi, NAT-OAr]

HDR*, HASH(3) -->

3. UDP封装通信数据

RFC3948描述如何对ESP包进行UDP封装和解封装,主要面向实际的通信数据处理。

封装ESP包的UDP包所用的端口和IKE协商的端口是相同的,一般都是4500,这样NAT设备也不需要处理两个端口了,区分一个UDP封装包的是IKE协商数据还是实际ESP数据是根据ESP头中的SPI字段来进行的,SPI为0表示是IKE数据,否则为实际ESP数据。

3.1. UDP封装ESP包格式

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Source Port | Destination Port |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Length | Checksum |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| ESP header [RFC4303] |

~ ~

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

所定义的UDP头是由RFC768定义的标准UDP头,源端口和目的端口都必须是相同的,校验和字段应该设为0,ESP本身有完整性认证功能,不需要UDP的校验和,ESP头的最开始4个字节是SPI字段,该字段绝不能是0。

因此传输模式下一个TCP上层包被封装为:

应用ESP/UDP之前

----------------------------

IPv4 |orig IP hdr | | |

|(any options)| TCP | Data |

----------------------------

应用ESP/UDP之后

-------------------------------------------------------

IPv4 |orig IP hdr | UDP | ESP | | | ESP | ESP|

|(any options)| Hdr | Hdr | TCP | Data | Trailer |Auth|

-------------------------------------------------------

|<----- encrypted ---->|

|<------ authenticated ----->|

数据包经过NAT设备后,只修改外部IP头和UDP头中的数据,TCP头中的数据是不可能修改的(实际NAT设备也根本看不到TCP头数据,因为是被 ESP加密了的),经过ESP/UDP协议解封装处理,到达应用层时的数据包剩下修改后的外部IP头和原始TCP头,因此TCP头中的校验和必须和修改后的IP头中的地址匹配,否则在应用层看来就是错误的,因此IKE 时必须交换NAT-OA载荷,使ESP/UDP处理层知道如何修改TCP校验和,而对于上层的UDP 协议,可以简单的将校验和置0即可。

通道模式下数据封装为:

应用ESP/UDP前

----------------------------

IPv4 |orig IP hdr | | |

|(any options)| TCP | Data |

----------------------------

应用ESP/UDP后

--------------------------------------------------------------

IPv4 |new h.| UDP | ESP |orig IP hdr | | | ESP | ESP|

|(opts)| Hdr | Hdr |(any options)| TCP | Data | Trailer |Auth|

--------------------------------------------------------------

|<------------ encrypted ----------->|

|<------------- authenticated ------------>|

内部IP头也是ESP载荷的一部分,因此TCP校验和已经是根据内部IP头计算的了,因此在IKE时不用交换NAT-OA载荷,解封处理只需要按顺序依次解开UDP和ESP就能还原原始数据包。

3.2 UDP封装IKE包格式

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Source Port | Destination Port |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Length | Checksum |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Non-ESP Marker |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| IKE header [RFC4306] |

~ ~

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

源和目的端口是4500;UDP校验和可以计算也可以不用设,没作限定,但该字段绝不能作为判断包类型的依据;Non-ESP Marker字段必须设置为0,该字段位置等价于ESP头的SPI 字段,因此该字段为0表示是IKE数据,不为0表示是ESP数据。

3.3. NAT连接保持包

NAT连接保持包是为了检查NAT映射是否一直存在,或者是在没有其他包发送给对方是发送此包用来保持连接,但接收到该包不能用作连接有效的判据。

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Source Port | Destination Port |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Length | Checksum |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| 0xFF |

+-+-+-+-+-+-+-+-+

源和目的端口是4500;UDP校验和字段应该设为0;数据部分就一个字节0xff,接收方不进行回应。

4. 冲突

在某些情况下NAT-T会导致一些冲突,如在通道模式下,对于下面的拓扑结构:

+----+ \ /

| |-------------|----\

+----+ / \ \

A NAT 1 \

\

10.1.2.3 \

+----+ \ / \ +----+ +----+

| |-------------|----------+------| |----------| |

+----+ / \ +----+ +----+

B NAT 2 远程VPN网关远程服务器

10.1.2.3

A和B具有相同的内部IP都通过NAT后访问远程服务器,但对于远程VPN网关和服务器来说,解开包后看到的内部IP都是相同的,因此就不知道该将数据发给谁,这时就会发生冲突,解决方法是VPN通信的内部IP完全由VPN网关来进行分配,而不是本地设置,这样VPN 网关就能区分不同的远程 VPN客户的访问,在IKEv2(RFC4306)中已经包括了内部IP分配的内容。

在传输模式下更容易发生问题,对于下面的拓扑结构:

+----+

| |

+----+ \

A \

10.1.2.3 \

\

+----+ \ / +----+

| |-----+-----------------| |

+----+ / \ +----+

B NAT 服务器

10.1.2.4 /

/

/

+----+ /

| |/

+----+

C

10.1.2.5

A和B通过VPN通道和服务器连接,如果都访问服务器上的相同服务,由于传输模式没有原始IP头信息,因此服务器包无法区分包到底是来自A还是 B的,因此不能确定使用哪个SA 来加密通信;如果增加第3个客户端C,使用的是明文访问服务器,服务器将更抓瞎了。解决方法还是需要用通道模式进行通信。

5. 结论

NAT-T技术解决了IPSec在NAT环境下的使用异常的问题,虽然也可能会引起一些新问题,但都是可以解决的。

IPSec协议

IPSec协议 IPSec协议 1 IP Sec协议概述 2 IPSec VPN工作原理 4.2.1 隧道建立方式 2.2 数据保护方式 2.3 IPSEC 协议体系结构 3 IP Sec的优点 1 IP Sec协议概述 IPSec是一系列基于IP网络(包括Intranet、Extranet和Internet)的,由IETF 正式定制的开放性IP安全标准,是虚拟专网的基础,已经相当成熟可靠。 IPSec可以保证局域网、专用或公用的广域网及Internet上信息传输的安全。 ①保证Internet上各分支办公点的安全连接:公司可以借助Internet或公用的广域网搭建安全的虚拟专用网络。这使得公司可以不必耗巨资去建立自己的专用网络,而只需依托Internet即可以获得同样的效果。 ②保证Internet上远程访问的安全:在计算机上装有IPSec的终端用户可以通过拨入所在地的ISP的方式获得对公司网络的安全访问权。这一做法降低了流动办公雇员及远距离工作者的长途电话费用。 ③通过外部网或内部网建立与合作伙伴的联系:IPSec通过认证和钥匙交换机制确保企业与其它组织的信息往来的安全性与机密性。 ④提高了电子商务的安全性:尽管在电子商务的许多应用中已嵌入了一些安全协议,IPSec的使用仍可以使其安全级别在原有的基础上更进一步,因为所有由网络管理员指定的通信都是经过加密和认证的。 IPSec的主要特征在于它可以对所有IP级的通信进行加密和认证,正是这一点才使IPSec可以确保包括远程登录、客户/服务器、电子邮件、文件传输及Web 访问在内多种应用程序的安全。 IPSec在传输层之下,对于应用程序来说是透明的。当在路由器或防火墙上安装IPSec时,无需更改用户或服务器系统中的软件设置。即使在终端系统中执行IPSec,应用程序一类的上层软件也不会被影响。 IPSec对终端用户来说是透明的,因此不必对用户进行安全机制的培训。 如果需要的话,IPSec可以为个体用户提供安全保障,这样做就可以保护企业内部的敏感信息。 IPSec正向Internet靠拢。已经有一些机构部分或全部执行了IPSec。IAB的前任总裁Christian Huitema认为,关于如何保证Internet安全的讨论是他所见过的最激烈的讨论之一。讨论的话题之一就是安全是否在恰当的协议层上被使用。

ipsec原理介绍

Ipsec VPN调研总结 一、Ipsec原理 Ipsec vpn指采用IPSec协议来实现远程接入的一种VPN技术,IPSec全称为Internet Protocol Security,是由Internet Engineering Task Force (IETF) 定义的安全标准框架,用以提供公用和专用网络的端对端加密和验证服务。 Ipsec是一个协议集,包括AH协议、ESP协议、密钥管理协议(IKE协议)和用于网络验证及加密的一些算法。 1、IPSec支持的两种封装模式 传输(transport)模式:只是传输层数据被用来计算AH或ESP头,AH或ESP头以及ESP加密的用户数据被放置在原IP包头后面。 隧道(tunnel)模式:用户的整个IP数据包被用来计算AH或ESP头,AH或ESP头以及ESP加密的用户数据被封装在一个新的IP数据包中。

2、数据包结构 ◆传输模式:不改变原有的IP包头,通常用于主机与主机之间。 ◆隧道模式:增加新的IP头,通常用于私网与私网之间通过公网进行通信。

3、场景应用图

4、网关到网关交互图

5、Ipsec体系结构: 6、ipsec中安全算法 ●源认证 用于对对等体的身份确认,具体方法包含:PSK(pre-share key);PK3(public key infrustructure公钥基础设施)数字证书,RSA等,后两种为非对称加密算法。 ●数据加密 对传输的数据进行加密,确保数据私密性,具体对称加密算法包含:des(data encrypt standard)共有2种密钥长度40bits,56bits,3des密钥长度为56bits的3倍;aes(advanced encrypted standard)AES 加密共有三种形式,分为AES 128(128-bit 长度加密),AES 192(192-bit 长度加密)以及AES 256(256-bit 长度加密)。 ●完整性校验 对接收的数据进行检查,确保数据没有被篡改,主要使用hash算法(HMAC hashed message authentication code),包含MD5(message digest输出128bit校验结 果);SHA-1(secure hash algorithm 1)输出160bits校验结果。 ●密钥交换算法

第九章 IPSec及IKE原理

第九章IPSec及IKE原理 9.1 IPSec概述 IPSec(IP Security)是IETF制定的为保证在Internet上传送数据的安全保密性能的三层隧道加密协议。IPSec在IP层对IP报文提供安全服务。IPSec协议本身定义了如何在IP数据包中增加字段来保证IP包的完整性、私有性和真实性,以及如何加密数据包。使用IPsec,数据就可以安全地在公网上传输。IPsec提供了两个主机之间、两个安全网关之间或主机和安全网关之间的保护。 IPSec包括报文验证头协议AH(协议号51)和报文安全封装协议ESP(协议号50)两个协议。AH可提供数据源验证和数据完整性校验功能;ESP除可提供数据验证和完整性校验功能外,还提供对IP报文的加密功能。 IPSec有隧道(tunnel)和传送(transport)两种工作方式。在隧道方式中,用户的整个IP 数据包被用来计算AH或ESP头,且被加密。AH或ESP头和加密用户数据被封装在一个新的IP数据包中;在传送方式中,只是传输层数据被用来计算AH或ESP头,AH或ESP头和被加密的传输层数据被放置在原IP包头后面。 9.2 IPSec的组成 IPSec包括AH(协议号51)和ESP(协议号50)两个协议: AH(Authentication Header)是报文验证头协议,主要提供的功能有数据源验证、数据完整性校验和防报文重放功能,可选择的散列算法有MD5(Message Digest ),SHA1(Secure Hash Algorithm)等。AH插到标准IP包头后面,它保证数据包的完整性和真实性,防止黑客截断数据包或向网络中插入伪造的数据包。AH采用了hash算法来对数据包进行保护。AH没有对用户数据进行加密。 ESP(Encapsulating Security Payload)是报文安全封装协议,ESP将需要保护的用户数据进行加密后再封装到IP包中,证数据的完整性、真实性和私有性。可选择的加密算法有DES,3DES等。 9.3 IPSec的安全特点 数据机密性(Confidentiality):IPSec发送方在通过网络传输包前对包进行加密。 数据完整性(Data Integrity):IPSec接收方对发送方发送来的包进行认证,以确保数据在传输过程中没有被篡改。

ipsec协议的应用

竭诚为您提供优质文档/双击可除 ipsec协议的应用 篇一:ipsec协议 ipsec协议 ipsec协议 1ipsec协议概述 2ipsecVpn工作原理 4.2.1隧道建立方式 2.2数据保护方式 2.3ipsec协议体系结构 3ipsec的优点 1ipsec协议概述 ipsec是一系列基于ip网络(包括intranet、extranet 和internet)的,由ietF正式定制的开放性ip安全标准,是虚拟专网的基础,已经相当成熟可靠。ipsec可以保证局域网、专用或公用的广域网及internet上信息传输的安全。 ①保证internet上各分支办公点的安全连接:公司可以借助internet或公用的广域网搭建安全的虚拟专用网络。这使得公司可以不必耗巨资去建立自己的专用网络,而只需依

托internet即可以获得同样的效果。 ②保证internet上远程访问的安全:在计算机上装有ipsec的终端用户可以通过拨入所在地的isp的方式获得对公司网络的安全访问权。这一做法降低了流动办公雇员及远距离工作者的长途电话费用。 ③通过外部网或内部网建立与合作伙伴的联系:ipsec 通过认证和钥匙交换机制确保企业与其它组织的信息往来 的安全性与机密性。 ④提高了电子商务的安全性:尽管在电子商务的许多应用中已嵌入了一些安全协议,ipsec的使用仍可以使其安全级别在原有的基础上更进一步,因为所有由网络管理员指定的通信都是经过加密和认证的。 ipsec的主要特征在于它可以对所有ip级的通信进行加密和认证,正是这一点才使ipsec可以确保包括远程登录、客户/服务器、电子邮件、文件传输及web访问在内多种应用程序的安全。 ipsec在传输层之下,对于应用程序来说是透明的。当在路由器或防火墙上安装ipsec时,无需更改用户或服务器系统中的软件设置。即使在终端系统中执行ipsec,应用程序一类的上层软件也不会被影响。 ipsec对终端用户来说是透明的,因此不(ipsec协议的应用)必对用户进行安全机制的培训。如果需要的话,ipsec

ipsec工作原理

一、IPSec如何工作的 1,定义interesting traffic 如access-list 101 permit ip 10.0.1.0 0.0.0.255 10.0.2.0 0.0.0.255 2,IKE Phase 1 IKE Phase 1的目的是鉴别IPsec对等体,在对等体之间设立安全通道,以使IKE能够进行信息交换。 IKE Phase 1执行以下的功能: 鉴别和保护IPSec对等体的身份 在对等体之间协商一个相匹配的IKE安全关联策略。 执行一个被认证过的Diffie-Hellman交换,其结果是具有匹配的共享密钥。 建立安全的通道,以协商IKE Phase 2中的参数 IKE Phase 1有两种模式: master mode aggressive mode 3,IKE Phase 2 IKE Phase 2的目的是协商IPSec安全关联(SA),以建立IPSec通道。IKE Phase 2执行以下功能: 协商受已有IKE SA 保护的IPSec SA参数 建立IPSec SA 周期性的重新协商IPSec SA 以确保安全性 4,IPSec 加密隧道 在IKE Phase 2结束之后,信息就通过IPSec隧道被交换 5,隧道终止 当被删除或生存期超时后,IPSec就终止了。当指定的秒数过去或指定的字节数通过隧道后,安全关联 将超时。当SA终结后,密钥会被丢弃。当一个数据流需要后续的IPSEC SA时,IKE就执行一个新的IKE Phase 2和IKE Phase 1协商,产生新的SA密钥,新的SA密钥可以在现有的SA超时之前被建立。 二IPSec安全关联(SA) IPSec 提供了许多选项用于网络加密和认证。每个IPSec连接能够提供加密、完整性、认证保护或三者 的全部。两个IPSEC必须精确确定要使用的算法(如DES或3DES用于加密,MD5或SHA用于完整性验证)。在 确定算法事,两个设备必须共享会话密钥。用于IPSEC 的安全关联是单向的。双向通信由两个安全关联 组成。

IPSec-VPN中隧道模式和传输模式区别

IPSec VPN基本原理 IPSec VPN是目前VPN技术中点击率非常高的一种技术,同时提供VPN和信息加密两项技术,这一期专栏就来介绍一下IPSec VPN的原理。 IPSec VPN应用场景 IPSec VPN的应用场景分为3种: 1. Site-to-Site(站点到站点或者网关到网关):如弯曲评论的3个机构分布在互联网的3个不同的地方,各使用一个商务领航网关相互建立VPN隧道,企业内网(若干PC)之间的数据通过这些网关建立的IPSec隧道实现安全互联。 2. End-to-End(端到端或者PC到PC):两个PC之间的通信由两个PC之间的IPSec 会话保护,而不是网关。 3. End-to-Site(端到站点或者PC到网关):两个PC之间的通信由网关和异地PC之间的IPSec进行保护。 VPN只是IPSec的一种应用方式,IPSec其实是IP Security的简称,它的目的是为IP 提供高安全性特性,VPN则是在实现这种安全特性的方式下产生的解决方案。IPSec是一个框架性架构,具体由两类协议组成: 1. AH协议(Authentication Header,使用较少):可以同时提供数据完整性确认、数据来源确认、防重放等安全特性;AH常用摘要算法(单向Hash函数)MD5和SHA1实现该特性。 2. ESP协议(Encapsulated Security Payload,使用较广):可以同时提供数据完整性确认、数据加密、防重放等安全特性;ESP通常使用DES、3DES、AES等加密算法实现数据加密,使用MD5或SHA1来实现数据完整性。 为何AH使用较少呢?因为AH无法提供数据加密,所有数据在传输时以明文传输,而

H3C IPSec基本原理及配置指导

IPSec基本原理及配置指导 一、IPSec描述: 1、IPSec在RFC2401中描述了IP得安全体系结构IPSec,以便保证在IP网络数据传输的安全性。 2、IPSec在IP层对IP报文提供安全服务。 3、IPSec并非单一协议,而是由一系列的安全开放标准构成。 4、IPSec实现于OSI参考模型的网络层,因此,上层的协议都可以得到IPSec 的保护。 5、IPSec是一个可扩展的体系,不受任何一种算法的局限,可以引入多种开放的验证算法。 6、IPSec的缺点是难部署,协议体系复杂,不支持组播,只能对点对点的数据进行保护,不利于语音视频实时性高的应用。 二、IPSec体系结构 1、IPSec使用两种安全协议来提供通信安全服务: i.AH(验证头):AH提供完整性保护和数据源验证以及可选的抗重播 服务,但是不能提供机密性保护。 ii.ESP(封装安全载荷):ESP可以提供AH的所有功能,而且还可以提供加密功能。 2、AH和ESP可以单独使用,也可以一起使用,从而提供额外的安全性。 3、安全协议AH和ESP都具有两种工作模式: i.传输模式:用于保护端到端的安全性。 ii.隧道模式:用于保护点到点的安全性。

4、IPSec通过两种途径获得密钥: i.手工配置:管理员预先手工配置,这种方法不便于随时更改,安全 性较低,不易维护。 ii.通过IKE协商,通信双方可以通过IKE动态生成并交换密钥,获得更高的安全性。 5、IPSec SA(安全联盟) i.SA提供IPSec数据流安全服务的基础概念。 ii.SA是通信双方就如何保证通信安全达成的一个协定。具体确定了对IP报文进行处理。 iii.SA是单向的,入站数据流和出站数据流分别由入站SA和出站SA 处理。 iv.一个SA由(SPI,IP目的地址,安全参数索引)构成。 v.SA可以手工配置,也可以通过IKE自动协商生成。 vi.SA的生存时间有“以时间进行限制”和“以流量进行限制”。 vii.IPSec把类似“对哪些数据提供哪些服务”这样的信息储存在SPD (安全策略数据库)中,而SPD中的项指向SAD(安全联盟数据库), 如果,一个需要加密的出站数据包,系统会将他与SPD进行比较, 如果匹配一项,系统会使用该项对应的SA以及算法进行对数据包的 加密。否则,需要新建一个SA。 6、IKE i.无论是AH还是ESP,在对一个IP包进行操作之前,首先必须要建 立一个IPSec SA,IPSec SA可以手工建立,也可以通过IKE协商建

相关主题
相关文档
最新文档