HQY 一个和谐有爱的空间

一、IPSEC简介：

IPSec（IP Security）是IETF制定的三层隧道加密协议，它为Internet上传输的数据提供了高质量的、可互操作的、基于密码学的安全保证，是一种传统的实现三层VPN（Virtual Private Network，虚拟专用网）的安全技术。特定的通信方之间通过建立IPSec隧道来传输用户的私有数据，并在IP层提供了以下安全服务：

1） 数据机密性（Confidentiality）：IPSec发送方在通过网络传输包前对包进行加密。

2） 数据完整性（Data Integrity）：IPSec接收方对发送方发送来的包进行认证，以确保数据在传输过程中没有被篡改。

3） 数据来源认证（Data Authentication）：IPSEC在接收端可以认证发送IPSec报文的发送端是否合法。

4） 防重放（Anti-Replay）：IPSec接收方可检测并拒绝接收过时或重复的报文。

IPSec具有以下优点：

1）支持IKE（Internet Key Exchange，因特网密钥交换），可实现密钥的自动协商功能，减少了密钥协商的开销。可以通过IKE建立和维护SA（Security Association，安全联盟）的服务，简化了IPSec的使用和管理。

2）所有使用IP协议进行数据传输的应用系统和服务都可以使用IPSec，而不必对这些应用系统和服务本身做任何修改。

3）对数据的加密是以数据包为单位的，而不是以整个数据流为单位，这不仅灵活而且有助于进一步提高IP数据包的安全性，可以有效防范网络攻击。

二、组网需求：

当使用IKE进行IPSec参数动态协商时，有可能会出现两端参数配置不一致，导致IPSec协商失败，下面通过具体信息讲解排错方法。

三、组网图：

图 1

四、排查方法：

IPSec通过IKE协商，建立IPSec加密隧道，当隧道成功建立时，可以通过命令查看建立的情况。当IPSec无法正常建立时，也可通过命令，从IKE SA到IPSec SA，一步步进行排查，下面对各个要点逐个讲解：

1. IKE SA

IKE SA 是IPSec隧道的第一阶段，当VPN业务不正常，首先要查看IKE SA是否正常建立，可以通过以下三条命令简单查看：

<H3C>display ike sa //查看设备上的ike信息

total phase-1 SAs: 2880

connection-id peer flag phase doi

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

<H3C>display ike sa verbose //查看设备上的ike的详细信息

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

transmitting entity: responder

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

local ip: 211.100.28.14

local id type: FQDN

local id: vpn-cnpc-center

remote ip: 125.92.114.164

remote id type: FQDN

remote id: vpn-cnpc-branch

authentication-method: PRE-SHARED-KEY

authentication-algorithm: HASH-SHA1

encryption-algorithm: DES-CBC

life duration(sec): 86400

remaining key duration(sec): 86072

exchange-mode: AGGRESSIVE

diffie-hellman group: GROUP1

nat traversal: NO

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

<H3C>dis ike sa verbose remote-address 125.92.114.164 //同时可以按照对端地址查看ike的详细信息

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

transmitting entity: responder

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

local ip: 211.100.28.14

local id type: FQDN

local id: vpn-cnpc-center

remote ip: 125.92.114.164

remote id type: FQDN

remote id: vpn-cnpc-branch

authentication-method: PRE-SHARED-KEY

authentication-algorithm: HASH-SHA1

encryption-algorithm: DES-CBC

life duration(sec): 86400

remaining key duration(sec): 85990

exchange-mode: AGGRESSIVE

diffie-hellman group: GROUP1

nat traversal: NO

2. 当IKE SA正常建立后，可以通过查看设备上的IPSec SA，确认IPSec SA是否正常，具体可参考如下命令：

IPSec tunnel中会显示加密保护的流量，需要确定IPSec分支和中心保护的流量必须是一致的，即FLOW中字段中心侧和分支侧需为镜像关系。

<H3C>display IPSec tunnel

total tunnel : 1698

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

Perfect forward secrecy: None

SA's SPI :

Tunnel :

Local Address: 211.100.28.14 Remote Address : 61.180.99.185

Flow :

Sour Addr : 10.0.0.0/255.0.0.0 Port: 0 Protocol : IP

Dest Addr : 10.92.237.32/255.255.255.224 Port: 0 Protocol : IP

Current Encrypt-card : None

IPSec statistics中包含了大量的统计信息，通过统计信息可以查看到每一个被丢弃的IPSec报文的具体原因，通过此信息可以了解到IPSec隧道成功建立后业务到达防火墙后丢包或不通的原因 。

<H3C>display ipsec statistics

the security packet statistics:

dropped security packet detail:

not enough memory: 0

queue is full: 0

authentication has failed: 56866

wrong length: 0

replay packet: 5517

packet too long: 0

wrong SA: 0

同时,可以按照IPSec 的tunnel-id具体查看每一个对应IPSEC的加解密情况。

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

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

the security packet statistics:

input/output security packets: 15086/6302

input/output dropped security packets: 0/0

dropped security packet detail:

not enough memory: 0

queue is full: 0

authentication has failed: 0

wrong length: 0

replay packet: 0

packet too long: 0

wrong SA: 0

3. IPSec流量在防火墙上进行转发时，会有对应的会话表项，用以标识此数据流经过通过了防火墙转发：

当业务数据不通，或者没有IKE SA和IPSec SA信息时，可以通过此命令，判断报文是否到达了防火墙设备，中间链路是否存在丢包，具体查看方法为：

首先确认一条IKE SA

<H3C>display ike sa verbose remote-address 124.116.109.165

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

vpn-instance:

transmitting entity: responder

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

local ip: 211.100.28.14

local id type: FQDN

local id: vpn-cnpc-center

remote ip: 124.116.109.165

remote id type: FQDN

remote id: vpn-cnpc-branch

authentication-method: PRE-SHARED-KEY

authentication-algorithm: HASH-SHA1

encryption-algorithm: DES-CBC

life duration(sec): 86400

remaining key duration(sec): 55971

exchange-mode: AGGRESSIVE

diffie-hellman group: GROUP1

nat traversal: NO

然后基于此目的地址进行会话的查询：

<H3C>display session table source-ip 124.116.109.165 verbose

Initiator:

Source IP/Port : 124.116.109.165/500

Dest IP/Port : 211.100.28.14/500

VPN-Instance/VLAN ID/VLL ID:

Responder:

Source IP/Port : 211.100.28.14/500

Dest IP/Port : 124.116.109.165/500

VPN-Instance/VLAN ID/VLL ID:

Pro: UDP(17) App: ISAKMP State: UDP-READY

Start time: 2011-08-02 16:53:12 TTL: 47s

Root Zone(in): Untrust

Zone(out): Local

Received packet(s)(Init): 7 packet(s) 784 byte(s)

Received packet(s)(Reply): 7 packet(s) 784 byte(s)

Initiator:

Source IP/Port : 124.116.109.165/0

Dest IP/Port : 211.100.28.14/0

VPN-Instance/VLAN ID/VLL ID:

Responder:

Source IP/Port : 211.100.28.14/0

Dest IP/Port : 124.116.109.165/0

VPN-Instance/VLAN ID/VLL ID:

Pro: RAWIP(ESP) App: unknown State: RAWIP-READY

Start time: 2011-08-02 16:54:21 TTL: 57s

Root Zone(in): Untrust

Zone(out): Local

Received packet(s)(Init): 18 packet(s) 2160 byte(s)

Received packet(s)(Reply): 18 packet(s) 2160 byte(s)

Total find: 2

同时注意，ike会有发起方和响应方，在这个例子中，因为本端的ike为responder,所以本端为应答方，查找会话的时候按照源地址是对端地址进行查找，如果本端为发起端，查找会话的时候，应该按对端ip地址为目的地址查找。

在中间有nat穿越设备的时候，上面显示的会话可能就只有一条UDP，按照两端支持的nat穿越的draft标准不同。会话有可能是500端口，也有可能是4500端口。

五、抓包和DEBUG详解：

在了解了排查步骤后，当遇到IKE协商无法通过，需要判断是哪个参数出现了问题时，就需要学会看懂DEBUG信息，首先我们先了解IKE协商时的交互过程：

对IPSEC而言，已定义的密钥交换就是IKE—即Internet密钥交换。IKE利用ISAKMP语言来定义密钥交换，是对安全服务进行协商的手段。事实上， IKE定义了为数众多的交换方式，以及相关的选项。IKE交换的最终结果是一个通过验证的密钥以及建立在双方同意基础上的安全服务—亦即所谓的“IPSEC安全联盟（IPSEC SA）”。

IKE使用了两个阶段的ISAKMP。第一阶段建立IKE安全联盟，第二阶段利用这个既定的安全联盟，为IPSEC协商具体的安全联盟。

在IKE阶段1交换中，两个ISAKMP端点建立一个安全的、经过认证的通道。该通道常常称为ISAKMP SA或IKE SA。当阶段1完成时，两个IPSEC中只建立一个单独的SA。该IKE SA可以用两种方式来创建：主模式（main mode）或野蛮模式(aggressive mode)，但不能同时使用。

主模式包含6个报文类型。通过下面交换来建立IKE SA:

（1）发送消息1、2的准备：

在消息被发送前，协商发起者和响应者必须计算产生cookie，用于唯一的标识每个单独的协商交换，cookie使用源/目的IP地址、随机数字、日期和时间进行MD5运算得出，并且将其放入消息1的ISAKMP头中，用以标识一个单独的协商交换。

（2）发送消息1、2

在消息1、2中通过转换载荷双方协商IKE的散列类型、加密算法、认证方法、IKE SA协商的时间限制。

（3）发送消息3、4的准备:

需要生成用于在它们之间产生Diffie-Hellman共享密钥的DH值，生成方法是双方各自使用一个随机数字，通过DH算法对随机数字进行运算得出一个DH值Xa和Xb(Xa是发起方的DH值，Xb是响应方的DH值)，然后双方再根据DH算法各得出一个临时值Ni和Nr(Ni是发起方的临时值，Nr是响应方的临时值。这个临时值用于以后的密钥计算)，双方交换这个DH值以后通过自己计算的DH值和交换得到的DH值进行运算就可以产生一个只有双方知道的密钥，注意密钥并不进行传输，传输的是DH值，即使第三方得到了这个DH值也无法计算出密钥。

（4）发送消息3

消息3为发起方发送的。消息3的ISAKMP头和消息1、2相同，但是载荷不同，消息3的载荷为密钥交换载荷和临时值载荷，其中密钥交换载荷包含了Xa或者Xb，临时值载荷包含了Ni或者Nr。

（5）发送消息4

消息4是响应方发送的，格式和消息3相同，只是Xa换成了Xb，Ni换成了Nr。

（6）发送消息5、6的准备

双方根据Xa和Xb计算出双方的DH共享密钥，基于Ni和Nr计算出的DH秘密，以及两个IKE对等体的事先配置的预共享密钥组成了三组密钥，这三组密钥用于两个IKE对等体的认证和后续IKE交换的加密。每个对等体产生3个密钥，对等体的密钥是相同的，这些密钥被称为会话密钥(SKey)。

（7）发送消息5

消息5是发起者发送的，消息5的ISAKMP头还是和前面的一样，但是载荷不同，消息5中的载荷包含标识载荷和散列载荷。标识载荷包含了发起者的标识信息，IP地址或者主机名。散列载荷包含对上一过程中产生的三组密钥进行Hash运算得出的值。这两个负载使用SKEY_e进行加密。

（8）发送消息6

消息6是响应者发送的，信息和消息5一样，包含了响应者相应的信息。

（9）使用预共享的密钥完成IKE阶段1

如果双方在消息5和消息6中的散列载荷中的hash值相同，那么双方的认证成功。IKE第一阶段也就完成了。

IKE阶段2使用快速模式来建立IPSEC隧道，每个端点可以发起阶段2交换。

（1）发送消息1

消息1中的头部和其他消息头部一样，载荷有了很大区别。

负载中包含了如下的载荷(部分载荷)：

散列载荷：第一阶段计算出的SKEYID_a以及第二阶段产生的Xa’等信息组成，这样可以再次认证对等体。

SA载荷：包含DOI和环境信息。

安全提议和转换对：安全提议包含用于协商IPSEC所使用的安全协议(AH、ESP)、以及包含SPI。转换用于协商模式(隧道还是传输)，算法是SHA还是MD5以及IPSEC SA生存期。

Key载荷：包含要交换的Xa’

Nonce载荷：包含要交换的Ni’

ID载荷：由ACL定义的需要保护的感兴趣流，响应方要求该ID载荷必须是本地配置ACL的子集或者镜像，如果是交集或者没有交集，则响应方回应ID错误的错误消息。

（2）发送消息2

消息2是响应者回应的数据

（3）发送消息3的准备

对等体双方通过交换的Xa’和Xb’生成一个新的DH共享密钥，将其和IKE第一阶段生成的SKEYID_d共享密钥以及Ni’和Nr’还有SPI等信息生成最终用于IPSEC加密的密钥。此时发送者和接受者各有两个SA。

（4）发送消息3

发起者发送消息3，用于验证响应者是否可以通信，相当于确认信息，响应者收到该信息以后就知道发起者已经接受到它在IKE第二阶段发送的消息2，然后IPSECIKE第二阶段结束。(在不可靠的网络中，该机制容易导致IPSEC协商的错误)

下面就对主模式IKE交互过程的抓包和DEBUG信息进行详细的解释说明：

主模式第一个报文：

图 2

如图2所示，IKE协商报文中，第一个数据包基于UDP协议，源目的端口号均为500。在通过抓包软件，打开上层信息后，可以清晰了解对端发送过来的参数：

Initiator Cookie和Responder Cookie这两个参数唯一标识了IKE对等体（IKE的发起方和响应方），第一个报文中Responder Cookie数值不置位，响应报文中置位后，在通信过程中始终不变；

Exchange type标识IKE协商模式，如此协商过程中为主模式；Message ID标识一次第二阶段SA协商；

Domain of interpretation说明IKE SA在二阶段所应用的协议；

Proposal payload用于协商IKE使用的安全提议，其中Protocol ID标识提议类型。

对应此抓包信息，在我设备上的DEBUG关键信息如下：

IKE/8/DEBUG:message_send: message 2739aae4 //发送IKE协商报文

IKE/8/DEBUG: ICOOKIE: 0x062ec3b12c531a81 //发起方cookie

IKE/8/DEBUG: RCOOKIE: 0x0000000000000000 //响应方cookie

IKE/8/DEBUG: EXCH_TYPE: ID_PROT //IKE协商模式

主模式第二个报文：

图 3

如图3显示，在响应端回复报文时，将Responder cookie置位，自此在后续报文交互过程中，Initiator cookie和Responder cookie保持不变。

Transform payload中显示协商成功的IKE参数。

对应DEBUG关键信息：

IKE/8/DEBUG:message_recv: message 2739a304 //接收到的IKE协商报文

IKE/8/DEBUG: ICOOKIE: 0x062ec3b12c531a81

IKE/8/DEBUG: RCOOKIE: 0xae8673e9da0eebba //响应报文中Responder cookie已经置位

IKE/8/DEBUG: Attribute ENCRYPTION_ALGORITHM : DES_CBC //IKE安全提议加密算法为DES_CBC

IKE/8/DEBUG: Attribute HASH_ALGORITHM : SHA //IKE安全提议验证算法为SHA

IKE/8/DEBUG: Attribute AUTHENTICATION_METHOD : PRE_SHAR //鉴定方式为预共享密钥方式

IKE/8/DEBUG: Attribute GROUP_DEION : MODP_768 //DH组1

主模式第三个报文：

图 4

如图4所示，在第三个交互报文中，Key Exchange payload字段表示用于传送DH公共值Xa；Nonce payload字段用于传送临时值Ni（除用于密钥生成外，还可以用于防重放攻击），Vendor ID payload包含一个由厂商自定义的Hash值，用于厂商实现自己的新特性并且向后兼容，如此交互过程中，Vendor ID特性支持DPD功能。

对应的DEBUG信息：

IKE/8/DEBUG:message_send: message 2739aae4 //发送第三个IKE协商报文

IKE/8/DEBUG: ICOOKIE: 0x062ec3b12c531a81

IKE/8/DEBUG: RCOOKIE: 0xae8673e9da0eebba

主模式第四个报文：

图 5

如图5所示，Key Exchange Data标识DH公共值Xb；Nonce Data标识临时值Nr，Vendor ID中支持DPD功能。

对应DEBUG信息：

IKE/8/DEBUG:message_recv: message 273b6a44 //接收第四个IKE协商报文

IKE/8/DEBUG: ICOOKIE: 0x062ec3b12c531a81

IKE/8/DEBUG: RCOOKIE: 0xae8673e9da0eebba

对于主模式，后续交互报文载荷部分进行了加密，所以只能通过DEBUG信息进行分析查看。

主模式第五个报文：

IKE/8/DEBUG:message_send: message 2739aae4 //发送第五个IKE协商报文

IKE/8/DEBUG: ICOOKIE: 0x062ec3b12c531a81

IKE/8/DEBUG: RCOOKIE: 0xae8673e9da0eebba

IKE/8/DEBUG: NEXT_PAYLOAD: ID

IKE/8/DEBUG: VERSION: 16

IKE/8/DEBUG: EXCH_TYPE: ID_PROT

主模式第六个报文：

IKE/8/DEBUG:message_recv: message 273b6c84 //接收第六个IKE协商报文

IKE/8/DEBUG: ICOOKIE: 0x062ec3b12c531a81

IKE/8/DEBUG: RCOOKIE: 0xae8673e9da0eebba

QUICK MODE第一个报文：

IKE/8/DEBUG:message_send: message 273b6a44

IKE/8/DEBUG: ICOOKIE: 0x062ec3b12c531a81

IKE/8/DEBUG: RCOOKIE: 0xae8673e9da0eebba

IKE/8/DEBUG: NEXT_PAYLOAD: HASH

IKE/8/DEBUG: VERSION: 16

IKE/8/DEBUG: EXCH_TYPE: QUICK_MODE

QUICK MODE第二个报文：

IKE/8/DEBUG:message_recv: message 2739ac04

IKE/8/DEBUG: ICOOKIE: 0x062ec3b12c531a81

IKE/8/DEBUG: RCOOKIE: 0xae8673e9da0eebba

IKE/8/DEBUG: NEXT_PAYLOAD: HASH

IKE/8/DEBUG: VERSION: 16

IKE/8/DEBUG: EXCH_TYPE: QUICK_MODE

IKE/8/DEBUG: Attribute SA_LIFE_TYPE : SECONDS //IPSEC相关参数

IKE/8/DEBUG: Attribute SA_LIFE_DURATION : 3600

IKE/8/DEBUG: Attribute SA_LIFE_TYPE : KILOBYTES

IKE/8/DEBUG: Attribute ENCAPSULATION_MODE : TUNNEL

IKE/8/DEBUG: Attribute AUTHENTICATION_ALGORITHM : HMAC_SHA

QUICK MODE第三个报文：

IKE/8/DEBUG:message_send: message 273b6c84

IKE/8/DEBUG: ICOOKIE: 0x062ec3b12c531a81

IKE/8/DEBUG: RCOOKIE: 0xae8673e9da0eebba

IKE/8/DEBUG: NEXT_PAYLOAD: HASH

IKE/8/DEBUG: VERSION: 16

IKE/8/DEBUG: EXCH_TYPE: QUICK_MODE

至此，IPSEC隧道已经成功建立，可以正常交互报文数据。

推荐本站淘宝优惠价购买喜欢的宝贝:

本文链接：https://hqyman.cn/post/5762.html 非本站原创文章欢迎转载，原创文章需保留本站地址！

休息一下~~