第6章安全VPN及拨号业务故障排除.docx

上传人:b****3 文档编号:4010119 上传时间:2022-11-27 格式:DOCX 页数:100 大小:5.94MB
下载 相关 举报
第6章安全VPN及拨号业务故障排除.docx_第1页
第1页 / 共100页
第6章安全VPN及拨号业务故障排除.docx_第2页
第2页 / 共100页
第6章安全VPN及拨号业务故障排除.docx_第3页
第3页 / 共100页
第6章安全VPN及拨号业务故障排除.docx_第4页
第4页 / 共100页
第6章安全VPN及拨号业务故障排除.docx_第5页
第5页 / 共100页
点击查看更多>>
下载资源
资源描述

第6章安全VPN及拨号业务故障排除.docx

《第6章安全VPN及拨号业务故障排除.docx》由会员分享,可在线阅读,更多相关《第6章安全VPN及拨号业务故障排除.docx(100页珍藏版)》请在冰豆网上搜索。

第6章安全VPN及拨号业务故障排除.docx

第6章安全VPN及拨号业务故障排除

第6章安全VPN及拨号业务故障排除

第6章安全VPN及拨号业务故障排除

第6章安全VPN及拨号业务故障排除

6.1IPSec和IKE故障排除综述

6.1.1IPSec和IKE知识简介

1.IPSec简介

IPSec就是IP安全,也就是安全的IP。

IPSec在网络层起作用,为上层协议提供安全服务。

IPSec提供的安全服务包括:

●完整性:

确保接收到的数据在传送过程中没有被中间人篡改过。

●真实性:

确保接收到的数据是由所声称的发送方发送的,防止地址欺骗。

●机密性:

发送方在发送前将数据进行加密,确保数据的私有性。

●防重放:

IPsec报文的接收方可以检测到并拒绝重放的报文。

IPSec安全协议包括:

AH和ESP。

●AH协议提供了完整性、真实性、以及防重放服务,没有提供机密性服务。

但是AH协议的完整性和真实性服务比ESP协议的保护范围更大。

●ESP协议提供了完整性、真实性、机密性以及防重放服务。

IPSec使用的主要算法目前有:

●验证算法:

MD5和SHA1,用于提供完整性和真实性。

●加密算法:

DES、3DES、Blowfish、CAST等,用于提供机密性。

2.IKE简介

与IPSec密不可分的一个协议是IKE,它用于IPSec安全联盟及密钥的自动化管理,定时为IPSec协商密钥,创建、删除安全联盟等。

IKE使用两个阶段的ISAKMP:

●第一阶段:

协商创建一个通信信道,并对该信道进行认证,为双方进一步的IKE通信提供机密性、消息完整性以及消息源认证服务。

●第二阶段,使用已建立的IKESA建立IPSecSA。

从下图我们可以看出IKE和IPSec之间的关系。

图6-1IKE和IPSec之间的关系图

6.1.2IPSec和IKE配置的一般步骤

1.IPSec和IKE故障排除的一般步骤

IPSec和IKE的配置过程比较复杂,需要配置的命令较多。

IPSec配置的三个要素如下,熟练掌握将有助于安全配置:

●what:

哪些数据需要保护,用ACL去定义你要保护的数据流。

●where:

在传输路径的哪一段实施保护,定义隧道的两个端点。

●how:

如何保护这些数据,定义安全提议proposal。

2.手工模式IPSec基本配置

手工方式和协商方式的配置过程稍有不同:

对于手工方式,配置步骤如下:

1).明确要保护什么(what),也就是定义ACL。

2).明确实施保护的位置(where)。

3).明确如何保护(how),定义安全提议proposal。

4).定义安全策略(ipsecpolicy)。

5).定义安全策略的模式为manual。

6).将上面三个要素捆绑到安全策略中。

7).定义安全联盟所用的密钥。

8).在合适的接口上应用安全策略。

3.协商模式IPSec基本配置

对于协商方式,由于安全联盟的参数是协商出来的,而不是手工配置的,所以只有第5)步与手工方式不同,其余几步基本相同。

配置步骤如下:

1).明确要保护什么(what),也就是定义ACL。

2).明确实施保护的位置(where)。

3).明确如何保护(how),定义安全提议Proposal。

4).定义安全策略(ipsecpolicy)。

5).定义安全策略的模式为isakmp。

6).将上面三个要素捆绑到安全策略中。

7).配置IKE的参数(IKE的proposal和共享密钥)。

8).在合适的接口上应用安全策略。

6.1.3手工方式下IPSec功能和性能的常见问题

1.手工方式下安全联盟不能建立

当用displayipsecsa或displayipsecsapolicy命令检查安全联盟时发现没有看到相应的安全联盟,检查以下配置:

●检查相应的安全策略是否应用到了接口上。

●检查安全策略是否设置了要保护的数据流。

检查securityacl命令是否引用了正确的ACL号,该ACL号是否已经定义。

●检查安全策略是否设置了安全提议。

检查proposal命令是否引用了安全提议(proposal),而且该proposal已经被定义。

●检查安全策略是否设置了隧道端点。

检查tunnellocal命令和tunnelremote命令是否配置。

●检查安全联盟的SPI。

检查在安全策略中是否设置了安全联盟的SPI,是否进入和外出两个方向都设置了,SPI的值是否唯一。

●检查安全联盟的密钥是否设置正确。

如果在引用的安全提议中采用了加密算法,则应该设置加密密钥;如果在安全提议中采用了验证算法,则应该设置验证密钥。

如果采用十六进制方式指定密钥,则要分别指定加密密钥和验证密钥;如果采用字符串方式指定密钥,则只需配置一个string-key参数。

需要注意的是,外出和进入两个方向的密钥都要设置。

●如果以十六进制指定密钥,还要检查密钥的长度是否与算法要求的相同。

在接口应用IPSec安全策略或改变安全策略参数时会给出一定的提示信息,用户可以根据这些信息来定位问题。

参数配置了但不符合算法需要时(例如引用的proposal中选择的是sha1算法,而配置的验证密钥不足20个字节)的提示信息如下:

CreateSAFailed#(NewESPProtocol):

keylength16doesn'tmatchalgorithmHMAC-SHA1-96usKeySize(20)

2.手工方式下建立了安全联盟,但不能通信

如果用displayipsecsa或displayipsecsapolicy命令检查安全联盟时看到相应的安全联盟已经建立,但不能通信,则检查以下配置:

●安全联盟两端的配置的ACL是否互为镜像

●选用的安全协议是否一样

●选用的算法是否一致

●SPI是否匹配

●密钥是否匹配

●定义的隧道端点是否相同

由于通信是双方面的,一方虽然建立了安全联盟,但其双方的参数无法匹配起来,同样不能通信。

3.手工方式下建立了安全联盟,有些数据流能通信,但有些不通

出现这种情况时,可检查两端的安全策略所定义的数据流是否互为镜像。

图6-1数据流部分重叠

上图所示的就是两个数据流不是互为镜像,造成双方只有部分数据流是相同的。

例如:

[RTA]aclnumber3000

[RTA-acl-300]rulepermitipsource10.1.1.00.0.0.255destinationany

[RTB]aclnumber3000

[RTB-acl-3000]rulepermitipsource10.1.2.00.0.0.255destinationany

这时,双方定义的数据流的集合只有网段10.1.1.0和网段10.1.2.0之间的数据流是重叠的(也就是图中的C部分),其余不相同(上图中的A、B两部分)。

这样只能保证相交部分的数据流能通信,其它部分的数据流不能通信。

注意:

采用手工方式创建安全联盟,由于手工方式的数据、安全联盟是静态的,诊断相对容易些,只要注意以下几点便可排除常见的故障:

(1)参数是否配齐

(2)参数是否匹配

(3)ACL是否互为镜像

6.1.4协商方式下IPSec和IKE功能和性能的常见问题

协商方式的IPSec安全联盟是由IKE协商生成的。

要诊断此类的故障,首先要清楚安全联盟的建立过程。

其处理过程如下:

图6-1安全联盟建立过程

当一个报文从某接口外出时,如果此接口应用了IPSec,会进行安全策略的匹配。

如果找到匹配的安全策略,会查找相应的安全联盟。

如果安全联盟还没有建立,则触发IKE进行协商。

IKE首先建立阶段1的安全联盟,或称为IKESA。

在阶段1安全联盟的保护下协商阶段2的安全联盟,也就是IPSecSA。

用IPSecSA保护通讯数据。

当出现故障时,首先要知道是在哪个阶段出现的问题,然后再根据相应的阶段进行诊断。

1.阶段1的SA没有建立。

如果是阶段1的SA没有建立,应该对实施IPSec通信的双方都进行检查。

●接口是否应用了安全策略;

●是否有匹配的数据流触发;

●是否为对方配置了共享密钥,以及共享密钥是否一致(采用pre-share验证方式时)。

2.阶段2的SA没有建立

在阶段1的SA建立后,影响阶段2的SA建立的因素主要有:

●ACL是否匹配,按照前面所叙述的匹配原则进行检查;

●安全提议是否一致;

●设置的隧道对端地址是否匹配;

●应用的接口是否正确。

3.两个阶段的SA都建立起来了,但不能通信

在这种情况下,一般都是由于ACL的配置不当引起的。

应该检查ACL的配置是否符合要求。

6.1.5IPSec和IKE配置过程的注意事项

1.确定要保护的数据流时的注意事项

需要保护10.1.1.0/24与10.1.2.0/24子网之间的所有IP通信。

如下图所示:

图6-1IPSec和IKE典型组网图

用3000~3999之间的扩展ACL来表示,规则编号为3000,正确数据流过滤规则为:

[RTA]aclnumber3000

[RTA-acl-3000]rulepermitipsource10.1.1.00.0.0.255destination10.1.2.00.0.0.255

[RTB]aclnumber3000

[RTB-acl-3000]rulepermitipsource10.1.2.00.0.0.255destination10.1.1.00.0.0.255

注意事项:

对于IPSec要保护的数据流,我们只定义外出方向的数据流,不需要定义进入方向的数据流。

进入方向的数据流与外出方向数据流的源和目的正好相反。

如果只需要保护某一类数据,而非所有的IP数据,则可以在acl的定义中明确指出,如指定具体的端口号或端口号范围。

IPSec提供的是端到端的安全。

参与IPSec通信的两个对等体所定义的数据流的集合必须完全重合。

否则会造成一部分通信能通,而有些通信不能通。

所谓数据流完全重合也就是两个对等体所定义的数据流互为映射。

也就是说RTA定义的数据流的源就是RTB定义的数据流的目的,RTA定义的数据流的目的就是RTB定义的数据流的源。

ACL的定义应该准确反映实际需求,不能用any关键词简单代替。

2.确定实施保护位置时的注意事项

报文在传输路径的哪一段实施安全保护呢?

或换句话说,IPSec安全隧道的两个端点定义在哪里?

IPSec安全隧道是用来保护需要保护的通讯数据的,应该是在要保护的数据进入不信任网络前就要实施IPSec保护,在离开不信任网络后才可解除IPSec保护。

一般情况下是连接公网的接口处,或者说是连接不信任网络的接口处。

可以在两个子网的网关间实施安全保护,也可以在主机与网关,或主机与主机间实施保护,如下图所示:

图6-1IPSec实施保护的位置

IPSec实施保护的位置分为:

对于第一种情况,数据在两个网关间是受到保护的,在子网中是不受保护的,这种配置的前提是双方对于子网是信任的。

隧道的端点即是两个路由器连接公网的接口。

对于第二种情况,数据在主机和对方的网关间受到保护。

这时隧道的端点是主机和路由器。

主机不相信自己所在的子网内部,而相信对方所在网络的子网,在数据发出主机前,就对数据进行了IPSec保护。

这种情况一般多用于移动办公的用户连到总部的网关的情况。

第三种情况是由主机到主机的情况。

对于主机与主机间的情况,由于与路由器没太大关系,只要保证路由器能允许IPSec数据流和IKE协商报文通过即可。

3.确定如何保护数据时的注意事项

我们知道了要保护哪些数据,以及在哪里需要保护,那么又如何保护呢?

也就是说,需要什么样的安全服务:

是否需要机密性?

是否需要数据源验证?

以及保护的强度如何?

等等。

如果数据不怕被中间人看到,但需要防止中间人篡改数据、或伪造数据,则需要数据源验证功能。

AH协议和ESP协议都提供了数据源验证功能,但ESP协议没有对报文头进行验证。

一般情况下,如果只需要验证功能,建议选择AH协议。

如果即需要验证功能,还需要数据的机密性,则必须采用ESP协议来完成。

ESP即提供了验证功能,也提供了数据加密功能。

使用什么样的安全协议、什么样的加密算法、什么样的验证算法。

这些由安全提议(proposal)来定义。

当只需要验证功能时,使用AH协议;当需要对数据进行加密和验证时,使用ESP协议。

不推荐用法:

●使用ESP只做加密,而不做验证:

这种方式被证明是危险的;

●使用ESP加密,AH进行验证:

使用这种方法比直接用ESP对数据进行加密和验证处理复杂,并且在绝大多数情况下没有多少用途;

●用AH、ESP进行两次验证:

除特别想使用这种方式外,否则不要用,没有实际意义;

●只使用ESP的验证而不加密:

这在协议标准上称作“NULL加密”,推荐使用AH替代这种方式。

注意:

(1)没有验证的加密是不安全的。

在安全中,第一位的是验证。

如果没有验证,无法得知数据的真实性和可靠性。

(2)在Porposal定义时要注意封装模式的选择,如果保护的数据的源和目的不与IPsec隧道重合不能使用传输(transport)模式,只能使用隧道(tunnel)模式。

否则,无法对数据实施IPSec保护。

4.定义安全策略时的注意事项

在确定了三个要素后,用安全策略(ipsecpolicy)将它们联系到一起。

安全策略包括:

●需要保护的数据流(即What),用securityacl命令来指定ACL。

●如何保护(即How),用proposal命令来指定所使用的安全提议。

●安全隧道建立在哪里(即Where),用tunnelremote命令指定隧道的对端地址。

对于手工建立安全联盟的安全策略,隧道的本端地址需用命令tunnellocal来指定;对协商方式建立安全联盟的安全策略,采用IPSec安全策略应用的接口地址,不需要指定本端的隧道地址。

对于手工方式创建的安全策略,由于协议算法所需要的密钥和一些参数需要手工指定,所以还必须配置其它的参数,这些参数包括:

●安全联盟的安全参数索引SPI

●算法所使用的密钥。

如果使用了验证算法就必须指定验证算法所使用的密钥;如果使用了加密算法,就必须指定加密算法所使用的密钥。

而且位数必须符合算法的要求。

在手工配置密钥时,需要注意以下几点:

IPSec安全联盟是单向的,分为外出数据流的安全联盟和进入数据流的安全联盟。

所以在配置时需要分别配置入方向和出方向的安全联盟。

SPI参数是安全参数索引,严格讲,对于每一个安全联盟,应该是唯一的,不应该与其它的安全联盟的SPI相同。

同一个隧道的两个方向的安全联盟也不应该相同。

对于一个安全隧道的两端,其参数应该是匹配的。

匹配的含义就是一端的出方向的安全联盟的参数应该与另一端的入方向的安全联盟的参数相同;一端入方向的安全联盟的参数应该与另一端出方向的安全联盟参数相同。

手工方式下,可以用两种方式来指定安全联盟的密钥:

字符串或十六进制形式。

如果使用字符串方式,只需为每个方向的安全联盟指定一个字符串,便可为协议所使用的算法派生出相应的密钥。

如果用十六进制形式指定密钥,则必须严格按照算法的要求指定协议所有算法所需的密钥。

注意:

对于手工方式的安全策略,其安全联盟的密钥需要在安全策略定义中指定,以上的配置就足够了;而对于自动协商方式的安全策略,由其产生的安全联盟的密钥、SPI等一些参数是由IKE协商产生的。

所以,对于协商方式的安全策略,还需要一些IKE的配置工作。

5.IKE的配置

在进行完上面的几步后,IPSec的安全策略已经配置完成。

如果采用自动协商方式的安全策略,就应该进行相关的IKE配置。

如果采用手工方式的安全策略,则不需要这一步。

IKE的配置主要有两方面:

●IKE的安全策略(proposal)

●共享密钥(pre-sharedkey)

在配置IKE时,需要注意以下几点:

IKE的配置是基于整个路由器的,而IPSec的安全策略是基于接口的。

路由器有一个缺省的IKE安全策略。

其优先级最低,当参与IKE协商的双方配置的IKE安全策略都不匹配时,会采用此缺省的IKE安全策略。

所以,即使没有配置IKE的proposal,双方也会有匹配的IKE安全策略,因为有一个缺省的proposal。

如果在一台路由器上定义了好几个参数相同的IKEproposal,其效果与配置一个IKEproposal是相同的。

6.应用所定义的安全策略组

最后一步就是应用所定义的安全策略组。

在接口配置模式下,执行ipsecpolicy命令在指定接口应用此安全策略组。

如果所应用的安全策略是手工方式建立安全联盟,会立即生成安全联盟。

如果所应用的是自动协商方式的安全联盟,不会立即建立安全联盟,只有当符合某IPSec安全策略的数据流从该接口外出时,才会触发IKE去协商IPSec安全联盟。

安全策略应该应用到要保护的数据流的外出接口上。

应该强调三点:

●外出接口;

●确保保护的数据流应该从此接口出去,而不是其它的接口;

●对方实施了措施,确保保护的数据应该从此接口进来。

7.IPSec和IKE的其它配置

IKE的keepalive机制可以判断对端是否还能正常通讯。

IKE的keepalive需要配置两个参数:

●interval:

发送keepalive报文的时间间隔。

●timeout:

超时检测的时间间隔,建议时间间隔为interval的3倍左右。

注意:

(1)在一台路由器上应该同时配置这两个参数,并且参数要匹配。

(2)interval和timeout要成对出现,即在一个路由器上配置了timeout参数,那么在对端就要配置interval参数。

(3)interval的参数应该小于对端的timeout参数值,而不应该与本端进行比较。

6.2与IPSec和IKE故障相关的dispaly、debugging命令介绍

Quidway中低端路由器上用于排除IPSec和IKE故障的的常用命令在下面分别介绍。

6.2.1displayacl

【命令】

displayacl[all|aclt-number]

【视图】

所有视图

【参数】

all:

显示所有的ACL规则。

acl-number:

以数字表示的ACL。

i

 

【描述】

命令displayacl用来显示配置的访问控制列表的规则。

默认情况下,规则的匹配顺序为config(配置顺序),display命令将不会显示该匹配顺序;而如果匹配顺序为auto时,display命令则会显示出该顺序。

【举例】

#显示当前所使用的序号为2000的ACL规则。

[Quidway]displayacl2000

Basicacl 2000,2rules,

 rule1permit(0timesmatched)

 rule2permitsource1.1.1.10(0timesmatched)

 

6.2.2displayikeproposal

【命令】

displayikeproposal

【视图】

所有视图

【描述】

displayikeproposal命令用来显示每个IKE提议配置的参数。

IKE提议按照优先级的先后顺序显示。

相关配置可参考命令authentication-method,ikeproposal,encryption-algorithm,authentication-algorithm,dh,saduration。

【举例】

[Quidway]displayikeproposal

priorityauthenticationauthenticationencryptionDiffie-Hellmanduration

             method      algorithm   algorithm    group      (seconds)

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

 10      PRE_SHARED    SHA           DES_CBC   MODP_1024     5000

 11      PRE_SHARED    MD5           DES_CBC   MODP_768      50000

 default PRE_SHARED    SHA           DES_CBC   MODP_768      86400

displayikesa

 

6.2.3displayikesa

【命令】

displayikesa

【视图】

所有视图

【描述】

displayikesa命令用来显示由IKE建立的安全隧道。

displayikesa显示安全通道列表,内容包括对端地址(peer)、通道状态(flags)、协商阶段(phase)和DOI。

安全通道与安全联盟是完全不同的两个概念,安全通道是一个两端可以互通的通道,而IPSecSA则是一个单向的连接,所以安全通道是由一对或几对安全联盟组成的。

【举例】

[Quidway]displayikesa

Connect-IDPeerFlagPhaseDoi

211.0.0.2RD2IPSEC

111.0.0.2RD1IPSEC

Flagmeaning

RD--READYST--STAYALIVERL--REPLACEDFD--FADINGTO--TIMEOUT

displayikesa命令域参数描述

域名

描述

Connect-ID

安全通道的标识符

Peer

此安全联盟的对端的IP地址

Flag

显示此安全联盟的状态

NONE表示此SA正在建立中

READY表示此SA已建立成功

STAYALIVE表示此方为SA发起方,在软超时(即SA到达生存周期前的某个时间,此时开始新SA的协商)的时候将由此方发起重新协商

REPLACED表示此SA已经被新的SA替换,不再被使用,并将在10秒后被删除

FADING表示此SA发生了软超时,但当前还可以使用,等待新的SA协商好后进行替换或待硬超时(即SA延续整个生存周期直到时间或流量超时)被删除

Phase

SA所属的阶段

Doi

SA所属解释域

6.2.4displayipsecpolicy

【命令】

displayipsecpolicy{brief|namepolicy-name[sequence-number]}

【视图】

所有视图

【参数】

brief:

显示所有的安全联盟的简要信息。

name:

表示显

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 工程科技 > 能源化工

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1