|
|
IPsec VPN原理描述
1 IPsec VPN的分类
可以从多个角度给IPsec VPN分类,不过,看一下IPsec VPN试图解决的VPN二个主要设计问题是很有意义的.
--为把二个专用的网络组合成一个虚拟网络的无缝连接.
--将虚拟网络扩展成允许远程访问用户(也被称为road warriors)成为可信任网络的一部分.
<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
基于这二个设计的基础上, IPsec VPN可以被分为二类:
--LAN-to-LAN IPsec 实现(也被称作site-to-site VPN).
--远程访问客户端IPsec VPN实现.
2 IPsec VPN的组成
IPsec 结合了三个主要的协议从而组成了一个和谐的安全框架
--Internet密钥交换(IKE)协议----提供协商安全参数和创建认证密钥的框架
--ESP(负载安全封装)协议----提供加密,认证和保护数据的框架
在这些协议中,IKE和ESP在一起配置.尽管AH也是IPsec协议的一个重要成分.但不像使用IPsec时那样要做那么多的配置.一般情况下,AH的很多功能都被嵌入到ESP中了.
3 IKE介绍
IKE协议是负责在二个IPsec对等体间协商一条IPsec隧道的协议,IKE在隧道建立过程中主要完成以下任务:
--协商协议参数
--交换公共密钥
--对双方进行认证
--在交换后对密钥进行管理
IKE也是由三个协议组成
--SKEME----提供为认证目的使用公开密钥加密的机制
--Oakley----提供在二个IPsec对等体间达成相同加密密钥的基于模式的机制
--ISAKMP----定义了消息交换的体系结构,包括二个IPsec对等体间分组形式和状态转换.
IKE协议分为二个阶段.一条完整的IPsec隧道通过以下事件序列建立起来:
第一步: IPsec对等体收到感兴趣流量(即我们想被加密的流量)后,将产生IKE会话.
第二步: 使用IKE的主模式(6条消息)或主动模式(3条消息)协商来使二个IKE对等体的IKE安全联盟被创建.
第三步: 使用IKE的快速模式协商,创建二个IPsec对等体间的二个安全联盟.
第四步: 数据开始在加密的信道上传输,使用了ESP或是AH封装技术(或都采用了).
从第二步和第三步可以看出IKE协议分为二个阶段:
第一阶段使用主模式(6条消息)或主动模式(3条消息)来完成下面三个任务:
--协商形成用来认证二个对等体的一个参数集合并加密一部分主模式和所有的快速模式交换.如果协商中使用主动模式则没有主动模式被加密.
--二个对等体间相互认证.这里验证有三种方法:预共享,数字签名,加密临时值.
--当协商完成时产生密钥,该密钥用于生成实际加密数据的密钥资源.
第二阶段为快速模式(3条消息):
主要目标是允许二个对等协商一些用于产生IPsec安全联盟的属性,安全联盟可以加密二个主机间的数据(ESP).
4 IKE如何用来形成一条IPsec隧道的呢?
这一系列过程都是IKE这个协议来实现,IKE这个协议也存在着一些不足,“IKE之子”或第二版IKE正在开发之中.
主模式(6条消息)或主动模式(3条消息)
第一阶段三个任务,分别用6个消息(主模式)来完成,每二个为一组.
第一个消息由隧道的发起者发起,携带了如这样一些参数,如加密机制-DES,散列机制-MD5-HMAC,Diffie-Hellman组-2,认证机制-预共享.
第二个消息由响应者回应,内容基本一样,主要与发起者比较,是否与发起者匹配,不匹配就进行下一组的比较.如果最终都找不到匹配,隧道就停止建立.
第三个消息由发起者发出,但是在发出这个消息之前,有个过程必须先完成,就是Diffie-Hellman算法过程.
该过程的目的是什么呢？刚刚第一二条消息中所协商的算法它们必须需要一个KEY,这个KEY在二个对等体上必须一样,但同时这个KEY不能在链路中传递,因为传递KEY是一个不安全的手段.所以,该过程的目的是分别在二个对等间独立地生成一个DH公共值(该DH公共值不是我们上面所说的KEY),该公共值有什么用呢？因为二个对等体上都生成该DH公共值后,它们会在接下来的第三第四消息中传送给对方,打个比方,就是A收到了B的DH公共值Xb,B收到了A的DH公共值Xa.当A,B都收到了对方的该公共值后,问题就好解决了.因为有一个公式在数学中被论证成立,借助该公式,就可以在二个对等上生成一个只有他们二个对等体知道的相同的KEY,该公式为
发起者密秘=(Xb)amod p=(Xa)bmod p=响应者密秘
Xb为对等体B的DH公共值,Xa为对等体A的DH公共值
a为只有对等体A知道的秘密. b为只有对等体B知道的秘密.
注意,这里发起者秘密和响应者密秘相等,但这个秘密不是最终算法中使用的KEY,但对等体可通过该秘密材料来生成另外三个密钥,分别是:
SKEYID_d--此密钥被用于计算后续IPsec密钥资源.
SKEYID_a--此密钥被用于提供后续IKE消息的数据完整性以及认证.
SKEYID_e--此密钥被用于对后续IKE消息进行加密.
所以由发起者发起的第三条消息主要是向对等体发送自己的DH公共值和一个临时值.
临时值被用作生成上述3个SKEYID的材料.
第四条消息由响应者向发起者发送,主要是向发送者发送自己的DH公共值和临时值.
由于第一二条消息协商算法,第三四条消息生成KEY,所以在后续的第五六条消息就能被加密传送.
第五条消息由发起者向响应者发送,主要是为了验证对端就是自己想要与之通信的对端.这可以通过预共享,数字签名,加密临时值来实现.
第六条消息由响应者向发起者发送,主要目的和第五条一样.
在这六条消息过后,也就是验证一旦通过,就进入了第二阶段:快速模式,快速模式使用二条消息来实现.
快速模式
发起者会在第一条消息中发送IPsec SA的转换集属性,如:封装--ESP,完整性检验--SHA-HMAC,DH组--2,模式--隧道
响应者向发起者发送第二条消息,同意第一条消息中的属性,同时也能起到确认收到对端消息的作用.
这一步一旦完成,隧道就建立起来了,用户的数据就能被放入隧道中传送.
实例研究
这是IPsec VPN中最基本最常用的类型.这种类型的VPN属于LAN-to-LAN.这里使用的认证方法是预共享密钥.以后的实例研究有更安全的认证方法的例子.
在实例中我们将给出发起者路由器和响应者路由器的配置,同时也给出了DEBUG输出以及相关的SHOU命令输出,以便我们共同研究.
例1 作为IPsec协商的发起者的路由器配置
hostname Initiator
The ISAKMP policy defines the attributes which will be negotiated with peers for the IKE SA.
crypto isakmp policy 1
The encryption method defined below is used for encrypting the IKE negotiation packets using SKEYID_e
encr 3des
The hash algorithm defined below is used to generate the hashes which are used for IKE authetnication purposes.
hash sha
The line below defines the authentication method as pre-shared key authentication
authentication pre-share
The line below defines the pre-shared key for the peer at the IP address
172.16.172.20. Please note that the initiator will search through its config for this key using the source IP address of the IKE negotiation packets it is receiving.
crypto isakmp key jw4ep9846804ijl address 172.16.172.20
The following line defines the transform set for use with IPsec. This transform set !specifies the name of the transform set as 'myset'. The encapsulation method
defined !is ESP and the encryption algorithm to use is 3DES (triple DES). The last part of !this command specifies MD5 as the ESP integrity checking hash.
crypto ipsec transform-set myset esp-3des esp-md5-hmac
The following configuration is for the crypto map named 'vpn'. Crypto maps essentially bind the entire IPsec configuration together. Various elements of IPsec defined in various places in the configuration are tied together using the crypto map. 10 is the instance number for the map here. Instance numbers are used to specify the order in which multiple crypto maps are parsed in a config. The key word 'ipsec-isakmp' is used to specify that this particular crypto map is to be used for IPsec rather than CET.
crypto map vpn 10 ipsec-isakmp
The command line below defines the IP address of the IPsec peer.
set peer 172.16.172.20
The line below defines the transform set to use for this crypto map.
set transform-set myset
The line below specifies the access list which will be define traffic which will either trigger IKE negotiation or be used to verify that the proxy Ids being offered during an IKE negotiation are valid.
match address 101
interface Ethernet0/0
ip address <?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" />10.1.1.1 255.255.255.0
interface Ethernet1/0
ip address 172.16.172.10 255.255.255.0
The line below is used as a toggle switch to turn on IPsec functionality as defined by the crypto map vpn.
crypto map vpn
The access list define below is used to specify interesting traffic for IPsec.
access-list 101 permit ip 10.1.1.0 0.0.0.255 10.1.2.0 0.0.0.255
例2 作为IPsec协商的响应者的路由器配置
hostname Responder
crypto isakmp policy 1
encr 3des
hash sha
authentication pre-share
crypto isakmp key jw4ep9846804ijl address 172.16.172.10
crypto ipsec transform-set myset esp-3des esp-md5-hmac
crypto map vpn 10 ipsec-isakmp
set peer 172.16.172.10
set transform-set myset
match address 101
interface Ethernet0/0
ip address 10.1.2.1 255.255.255.0
interface Ethernet1/0
ip address 172.16.172.20 255.255.255.0
crypto map vpn
access-list 101 permit ip 10.1.2.0 0.0.0.255 10.1.1.0 0.0.0.255
对debug的解释紧接着该解释对应的实际debug
例3 作为IPsec协商的发起者的路由器debug
Cryptographic Subsystem:
Crypto ISAKMP debugging is on
Crypto Engine debugging is on
Crypto IPSEC debugging is on
A#ping
Protocol [ip]:
Target IP address: 10.1.2.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 10.1.1.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.2.1, timeout is 2 seconds:
The ping source and destination addresses matched the match address access list for the crypto map VPN. 'local' is the local tunnel endpoint, and 'remote' is the remote crypto endpoint as configured in the map. src proxy is the src interesting traffic as defined by the match address access list. dst proxy is the destination interesting traffic as defined by the match address access list.
(key eng. msg.) OUTBOUND local= 172.16.172.10, remote= 172.16.172.20,
local_proxy= 10.1.1.0/255.255.255.0/0/0 (type=4),
remote_proxy= 10.1.2.0/255.255.255.0/0/0 (type=4),
The protocol and the transforms are specified by the crypto map that has been hit, as are the lifetimes
protocol= ESP, transform= esp-3des esp-md5-hmac ,
lifedur= 3600s and 4608000kb,
spi= 0x8EAB0B22(2393574178), conn_id= 0, keysize= 0, flags= 0x400C
Begins main mode exchange. The first two packets negotiate phase I SA parameters.
00:04:10: ISAKMP: received ke message (1/1)
00:04:10: ISAKMP: local port 500, remote port 500
00:04:10: ISAKMP (0:1): Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM
MM stands for main mode, and QM stands for quick mode. The IKE debugs show which stage of IKE the negotiation is in, such as MM1. As you saw in the discussion of IKE, main mode is divided into six portions or messages, and quick mode into three.
Old State = IKE_READY New State = IKE_I_MM1
00:04:10: ISAKMP (0:1): beginning Main Mode exchange
00:04:10: ISAKMP (0:1): sending packet to 172.16.172.20 (I) MM_NO_STATE
00:04:10: ISAKMP (0:1): received packet from 172.16.172.20 (I) MM_NO_STATE
00:04:10: ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
Old State = IKE_I_MM1 New State = IKE_I_MM2
00:04:10: ISAKMP (0:1): processing SA payload. message ID = 0
The preshared key is searched for and found based on the source IP address of IKE negotiation packets.
00:04:10: ISAKMP (0:1): found peer pre-shared key matching 172.16.172.20
00:04:10: ISAKMP (0:1): Checking ISAKMP transform 1 against priority 1 policy
These are the parameters offered by the other side. Policy 1 is the policy set up on this router.
00:04:10: ISAKMP: encryption 3DES-CBC
00:04:10: ISAKMP: hash SHA
00:04:10: ISAKMP: default group 1
00:04:10: ISAKMP: auth pre-share
00:04:10: ISAKMP: life type in seconds
00:04:10: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80
The policy 1 on this router and the attributes offered by the other side matched.
00:04:10: ISAKMP (0:1): atts are acceptable. Next payload is 0
00:04:10: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
Old State = IKE_I_MM2 New State = IKE_I_MM2
The third and fourth packets complete Diffie-Hellman exchange.
00:04:10: ISAKMP (0:1): sending packet to 172.16.172.20 (I) MM_SA_SETUP
00:04:10: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
Old State = IKE_I_MM2 New State = IKE_I_MM3
00:04:10: ISAKMP (0:1): received packet from 172.16.172.20 (I) MM_SA_SETUP
00:04:10: ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
Old State = IKE_I_MM3 New State = IKE I_MM4
00:04:10: ISAKMP (0:1): processing KE payload. message ID = 0
00:04:10: ISAKMP (0:1): processing NONCE payload. message ID = 0
00:04:10: ISAKMP (0:1): found peer pre-shared key matching 172.16.172.20
00:04:10: ISAKMP (0:1): SKEYID state generated
00:04:10: ISAKMP (0:1): processing vendor id payload
Note below that some vendor ID payloads are being exchanged. These are necessary to gauge the peer's ability to do the things described in the vendor payload. For example, below, VID payloads for Unity Protocol Support (a new protocol introduced by Cisco for its newer version of VPN clients) and dead peer discovery are received.
00:04:10: ISAKMP (0:1): vendor ID is Unity
00:04:10: ISAKMP (0:1): processing vendor id payload
00:04:10: ISAKMP (0:1): vendor ID is DPD
00:04:10: ISAKMP (0:1): processing vendor id payload
00:04:10: ISAKMP (0:1): speaking to another IOS box!
00:04:10: ISAKMP (0:1): processing vendor id payload
00:04:10: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
Old State = IKE_I_MM4 New State = IKE_I_MM4
The fifth and sixth packets complete IKE authentication. Phase I SA is established.
00:04:10: ISAKMP (0:1): SA is doing pre-shared key authentication using id type ID_IPV4_ADDR
00:04:10: ISAKMP (1): ID payload
next-payload : 8
type : 1
protocol : 17
port : 500
length : 8
00:04:10: ISAKMP (1): Total payload length: 12
00:04:10: ISAKMP (0:1): sending packet to 172.16.172.20 (I) MM_KEY_EXCH
00:04:10: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
Old State = IKE_I_MM4 New State = IKE_I_MM5
00:04:10: ISAKMP (0:1): received packet from 172.16.172.20 (I) MM_KEY_EXCH
00:04:10: ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
Old State = IKE_I_MM5 New State = IKE_I_MM6
00:04:10: ISAKMP (0:1): processing ID payload. message ID = 0
00:04:10: ISAKMP (0:1): processing HASH payload. message ID = 0
00:04:10: ISAKMP (0:1): SA has been authenticated with 172.16.172.20
00:04:10: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
Old State = IKE_I_MM6 New State = IKE_I_MM6
00:04:10: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
Old State = IKE_I_MM6 New State = IKE_P1_COMPLETE
Begin quick mode exchange. IPsec SA will be negotiated in quick mode.
00:04:10: ISAKMP (0:1): beginning Quick Mode exchange, M-ID of 965273472
00:04:10: ISAKMP (0:1): sending packet to 172.16.172.20 (I) QM_IDLE
00:04:10: ISAKMP (0:1): Node 965273472, Input = IKE_MESG_INTERNAL, IKE_INIT_QM
Old State = IKE_QM_READY New State = IKE_QM_I_QM1
00:04:10: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
00:04:10: ISAKMP (0:1): received packet from 172.16.172.20 (I) QM_IDLE
The IPsec SA proposal offered by the far end is checked against the local crypto map configuration
00:04:10: ISAKMP (0:1): processing HASH payload. message ID = 965273472
00:04:10: ISAKMP (0:1): processing SA payload. message ID = 965273472
00:04:10: ISAKMP (0:1): Checking IPsec proposal 1
00:04:10: ISAKMP: transform 1, ESP_3DES
00:04:10: ISAKMP: attributes in transform:
00:04:10: ISAKMP: encaps is 1
00:04:10: ISAKMP: SA life type in seconds
00:04:10: ISAKMP: SA life duration (basic) of 3600
00:04:10: ISAKMP: SA life type in kilobytes
00:04:10: ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0
00:04:10: ISAKMP: authenticator is HMAC-MD5
The proposal 1 and transform 1 offered by the other end are found to be
acceptable.
00:04:10: ISAKMP (0:1): atts are acceptable.
00:04:10: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= 172.16.172.10, remote= 172.16.172.20,
local_proxy= 10.1.1.0/255.255.255.0/0/0 (type=4),
remote_proxy= 10.1.2.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-3des esp-md5-hmac ,
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4
00:04:10: ISAKMP (0:1): processing NONCE payload. message ID = 96527347
00:04:10: ISAKMP (0:1): processing ID payload. message ID = 965273472
00:04:10: ISAKMP (0:1): processing ID payload. message ID = 965273472
Two IPsec SAs have been negotiated--an incoming SA with the SPI generated by the
local machine, and an outbound SA with the SPIs proposed by the remote end.
00:04:10: ISAKMP (0:1): Creating IPsec SAs
00:04:10: inbound SA from 172.16.172.20 to 172.16.172.10
(proxy 10.1.2.0 to 10.1.1.0)
00:04:10: has spi 0x8EAB0B22 and conn_id 2029 and flags 4
00:04:10: lifetime of 3600 seconds
00:04:10: lifetime of 4608000 kilobytes
00:04:10: outbound SA from 172.16.172.10 to 172.16.172.20
(proxy 10.1.1.0 to 10.1.2.0 )
00:04:10: has spi -343614331 and conn_id 2030 and flags C
00:04:10: lifetime of 3600 seconds
00:04:10: lifetime of 4608000 kilobytes
The IPsec SA info negotiated by IKE is populated into the router's SADB.
00:04:10: IPSEC(key_engine): got a queue event...
00:04:10: IPSEC(initialize_sas): ,
(key eng. msg.) INBOUND local= 172.16.172.10, remote= 172.16.172.20,
local_proxy= 10.1.1.0/255.255.255.0/0/0 (type=4),
remote_proxy= 10.1.2.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-3des esp-md5-hmac ,
lifedur= 3600s and 4608000kb,
spi= 0x8EAB0B22(2393574178), conn_id= 2029, keysize= 0, flags= 0x4
00:04:10: IPSEC(initialize_sas): ,
(key eng. msg.) OUTBOUND local= 172.16.172.10, remote= 172.16.172.20,
local_proxy= 10.1.1.0/255.255.255.0/0/0 (type=4),
remote_proxy= 10.1.2.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-3des esp-md5-hmac ,
lifedur= 3600s and 4608000kb,
spi= 0xEB84DC85(3951352965), conn_id= 2030, keysize= 0, flags= 0xC
IPsec SA created in SADB, sent out last packet with commit bit set. IPsec tunnel
established.
00:04:10: IPSEC(create_sa): sa created,
(sa) sa_dest= 172.16.172.10, sa_prot= 50,
sa_spi= 0x8EAB0B22(2393574178),
sa_trans= esp-3des esp-md5-hmac , sa_conn_id= 2029
00:04:10: IPSEC(create_sa): sa created,
(sa) sa_dest= 172.16.172.20, sa_prot= 50,
sa_spi= 0xEB84DC85(3951352965),
sa_trans= esp-3des esp-md5-hmac , sa_conn_id= 2030
00:04:10: ISAKMP (0:1): sending packet to 172.16.172.20 (I) QM_IDLE
00:04:10: ISAKMP (0:1): deleting node 965273472 error FALSE reason ""
00:04:10: ISAKMP (0:1): Node 965273472, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH
Old State = IKE_QM_I_QM1 New State = IKE_QM_PHASE2_COMPLETE
例4 作为IPsec协商的发起者的路由器show命令输出
The command below shows the state of the crypto ISAKMP SA. It is shown here in QM IDLE, meaning that quick mode has completed successfully.
Initiator#show crypto isakmp sa
dst src state conn-id slot
172.16.172.20 172.16.172.10 QM_IDLE 1 0
The command below gives details on both the incoming and outgoing IPsec SAs. It gives information on the attributes negotiated during the exchange as well as statistics for how many packets have been exchanged via each of these SAs.
Initiator#show crypto ipsec sa
interface: Ethernet1/0
Crypto map tag: vpn, local addr. 172.16.172.10
local ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.1.2.0/255.255.255.0/0/0)
current_peer: 172.16.172.20
PERMIT, flags={origin_is_acl,}
#pkts encaps: 4, #pkts encrypt: 4, #pkts digest 4
#pkts decaps: 4, #pkts decrypt: 4, #pkts verify 4
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
#send errors 6, #recv errors 0
local crypto endpt.: 172.16.172.10, remote crypto endpt.: 172.16.172.20
path mtu 1500, media mtu 1500
current outbound spi: EB84DC85
inbound esp sas:
spi: 0x8EAB0B22(2393574178)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 2029, flow_id: 1, crypto map: vpn
sa timing: remaining key lifetime (k/sec): (4607998/3347)
IV size: 8 bytes
replay detection support: Y
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xEB84DC85(3951352965)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 2030, flow_id: 2, crypto map: vpn
sa timing: remaining key lifetime (k/sec): (4607999/3347)
IV size: 8 bytes
replay detection support: Y
outbound ah sas:
outbound pcp sas:
The command below basically prints the configuration of the crypto map on the router
Initiator#show crypto map
Crypto Map "vpn" 10 ipsec-isakmp
Peer = 172.16.172.20
Extended IP access list 101
access-list 101 permit ip 10.1.1.0 0.0.0.255 10.1.2.0 0.0.0.255
Current peer: 172.16.172.20
Security association lifetime: 4608000 kilobytes/3600 seconds
PFS (Y/N): N
Transform sets={ myset, }
Interfaces using crypto map vpn:
Ethernet1/0
例5 作为IPsec协商的响应者的路由器debug
Responder#show debug
Cryptographic Subsystem:
Crypto ISAKMP debugging is on
Crypto Engine debugging is on
Crypto IPSEC debugging is on
1w1d: ISAKMP (0:0): received packet from 172.16.172.10 (N) NEW SA
1w1d: ISAKMP: local port 500, remote port 500
1w1d: ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
Old State = IKE_READY New State = IKE_R_MM1
1w1d: ISAKMP (0:1): processing SA payload. message ID = 0
1w1d: ISAKMP (0:1): found peer pre-shared key matching 172.16.172.10
1w1d: ISAKMP (0:1): Checking ISAKMP transform 1 against priority 1 policy
1w1d: ISAKMP: encryption 3DES-CBC
1w1d: ISAKMP: hash SHA
1w1d: ISAKMP: default group 1
1w1d: ISAKMP: auth pre-share
1w1d: ISAKMP: life type in seconds
1w1d: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80
1w1d: ISAKMP (0:1): atts are acceptable. Next payload is 0
1w1d: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
Old State = IKE_R_MM1 New State = IKE_R_MM1
1w1d: ISAKMP (0:1): sending packet to 172.16.172.10 (R) MM_SA_SETUP
1w1d: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
Old State = IKE_R_MM1 New State = IKE_R_MM2
1w1d: ISAKMP (0:1): received packet from 172.16.172.10 (R) MM_SA_SETUP
1w1d: ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
Old State = IKE_R_MM2 New State = IKE_R_MM3
1w1d: ISAKMP (0:1): processing KE payload. message ID = 0
1w1d: ISAKMP (0:1): processing NONCE payload. message ID = 0
1w1d: ISAKMP (0:1): found peer pre-shared key matching 172.16.172.10
1w1d: ISAKMP (0:1): SKEYID state generated
1w1d: ISAKMP (0:1): processing vendor id payload
1w1d: ISAKMP (0:1): vendor ID is Unity
1w1d: ISAKMP (0:1): processing vendor id payload
1w1d: ISAKMP (0:1): vendor ID is DPD
1w1d: ISAKMP (0:1): processing vendor id payload
1w1d: ISAKMP (0:1): speaking to another IOS box!
1w1d: ISAKMP (0:1): processing vendor id payload
1w1d: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
Old State = IKE_R_MM3 New State = IKE_R_MM3
1w1d: ISAKMP (0:1): sending packet to 172.16.172.10 (R) MM_KEY_EXCH
1w1d: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
Old State = IKE_R_MM3 New State = IKE_R_MM4
1w1d: ISAKMP (0:1): received packet from 172.16.172.10 (R) MM_KEY_EXCH
1w1d: ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
Old State = IKE_R_MM4 New State = IKE_R_MM5
1w1d: ISAKMP (0:1): processing ID payload. message ID = 0
1w1d: ISAKMP (0:1): processing HASH payload. message ID = 0
1w1d: ISAKMP (0:1): SA has been authenticated with 172.16.172.10
1w1d: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
Old State = IKE_R_MM5 New State = IKE_R_MM5
1w1d: ISAKMP (0:1): SA is doing pre-shared key authentication using id type ID_IPV4_ADDR
1w1d: ISAKMP (1): ID payload
next-payload : 8
type : 1
protocol : 17
port : 500
length : 8
1w1d: ISAKMP (1): Total payload length: 12
1w1d: ISAKMP (0:1): sending packet to 172.16.172.10 (R) QM_IDLE
1w1d: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
Old State = IKE_R_MM5 New State = IKE_P1_COMPLETE
1w1d: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
1w1d: ISAKMP (0:1): received packet from 172.16.172.10 (R) QM_IDLE
1w1d: ISAKMP (0:1): processing HASH payload. message ID = 965273472
1w1d: ISAKMP (0:1): processing SA payload. message ID = 965273472
1w1d: ISAKMP (0:1): Checking IPsec proposal 1
1w1d: ISAKMP: transform 1, ESP_3DES
1w1d: ISAKMP: attributes in transform:
1w1d: ISAKMP: encaps is 1
1w1d: ISAKMP: SA life type in seconds
1w1d: ISAKMP: SA life duration (basic) of 3600
1w1d: ISAKMP: SA life type in kilobytes
1w1d: ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0
1w1d: ISAKMP: authenticator is HMAC-MD5
1w1d: ISAKMP (0:1): atts are acceptable.
1w1d: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= 172.16.172.20, remote= 172.16.172.10,
local_proxy= 10.1.2.0/255.255.255.0/0/0 (type=4),
remote_proxy= 10.1.1.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-3des esp-md5-hmac ,
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4
1w1d: ISAKMP (0:1): processing NONCE payload. message ID = 965273472
1w1d: ISAKMP (0:1): processing ID payload. message ID = 965273472
1w1d: ISAKMP (0:1): processing ID payload. message ID = 965273472
1w1d: ISAKMP (0:1): asking for 1 spis from ipsec
1w1d: ISAKMP (0:1): Node 965273472, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH
Old State = IKE_QM_READY New State = IKE_QM_SPI_STARVE