Cnfan.net中国网络
IT网络技术专家
网络安全
 最新专题: VPN技术专题   Symantec专题   专题 | 分类 | 投稿 | 搜索
 网络安全首页 | 安全公告 | 病毒木马 | 安全知识 | 安全技术 | VPN技术

全系列VPN技术集锦第二卷(Site-to-Site IPsec VPN)

简介:1 ESP和AH IPsec流量可以使用二种协议封装,AH和ESP.比较AH和ESP的不同之处: AH功能为: 为二个系统这间传输的IP包进行数据认证和完整性保障.它用于检查从路由器A到路由器B的传输过程中消息有没有被更改.另外, ...

关键字: cisco vpn VPN 站点到站点

1 ESP和AH

IPsec流量可以使用二种协议封装,AH和ESP.比较AH和ESP的不同之处:

AH功能为:

为二个系统这间传输的IP包进行数据认证和完整性保障.它用于检查从路由器A到路由器B的传输过程中消息有没有被更改.另外,它还负责验证数据的来源是路由器A或还是路由器B.AH并不提供数据包的私密性(加密)功能.它执行以下任务.

确保数据的完整性

提供数据源认证

使用密钥散列机制

不提供数据的私密性

提供防重放攻击

 

ESP功能为:

可以用于提供私密性和认证的安全协议.ESP通过IP包层的加密提供数据的私密性.IP包加密隐藏了数据净载、数据源和目的地.ESP对内部IP包和ESP头标进行认证.它执行以下任务:

数据私密性

数据完整性

数据源的认证

防重放保护

 

AH工作过程:

AH功能适用于整个数据报,但在传输过程中发生过变化的易变性IP头标除外,如TTL字段.

(1) IP头标和数据净载使用了散列算法.

(2 )散列用于建立一个AH头标,并将其插入原始数据包

(3) 新的数据据包被发送到IPsec的对等路由器

(4) 对等到路由器对IP头标和数据净载使用了加密算法

(5) 对等路由器从AH头标中取出传送的散列

(6) 对等路由器将二个散列进行比较.

 

ESP工作过程:

在二个安全网关之间,由于整个的原始IP数据报文都被加密,原始的净载受到了很好的保护.ESP头标和结尾被加入加密的净载.通过ESP认证功能,加密的IP数据报文、ESP头标或结尾被加入散列计算的流程.最后,在经过验证的净载之前将加上一个新的IP头标.新的IP地址可以被用于INTERNET路由.

 

2 操作模式

ESP和AH可以通过二种不同的方法或模式应用于IP包:

传输模式

隧道模式

 

传输模式可以保护数据包的净载和更高层的协议,但原始的IP地址仍然是暴露的.原始的IP地址可以通过因特网选择数据包的路由.

 

隧道模式可以加密整个IP数据包,然后,在加密的数据包之前加入一个新的IP头标.用新的外部IP地址通过因特网将数据包路由到远端的安全网关.隧道模式为整个IP数据包提供安全保护.

 

3 扩展认证(x-auth)

扩展认证允许IPsec客户端的使用者,而不是IPsec客户端软件,被IPsec网关认证.这使被称作通配符的预共享密钥可用于认证所有的使用同一预共享密钥并连接到IPsec网关的IPsec客户端.这种方式带来的不安全性依靠多阶段的认证——展扩认证而得到克服.扩展认证是基于每一用户的,一般靠IPsec网关与TACACS+或ADIUS服务器合作完成.

 

扩展认证也被称作X-AUTH,在IKE阶段1完成后开始,在快速模式开始前结束.所以,这就是为什么说它是在IKE的阶段1.5发生的.

 

在IKE阶段1结束后,由配置X-AUTH的网关给客户端发送一个属性负载给客户端,要求用户输入用户名和密码.网关得到这些数据后提交给验证服务器(如TACACS+)进行验证,验证成功就进行快速模式,不成功则终止隧道建立过程.

 

4 模式配置

模式配置产生的背景是什么呢?

原因1,因为IPsec客户端被作为它们连接专用网络的一部分对待,它们必须以已知的IP地址进入专用网络而不是ISP给它们指定的IP地址

原因2,IPsec客户端必须使用DNS服务器,DHCP服务器和其它一些在专用网络上作为信息主要来源的服务器而不是使用ISP服务器,它提供的信息不被认做内部资源.

 

针对这样的二个问题,允许将指定的IP地址,DNS,其它服务器推送给客户端.

 

推送到客户端的IP地址被称为内部IP地址.当不使用这项特性时,在ESP负载中加密并封装的分组IP头同外部的IP头包含同样的IP地址:由ISP分配给客户端地址.不过,当使用这项特性后,所有使用ESP发送的封装的分组的源地址就被改为该客户端的内部IP地址.采用这种方法,当网关对ESP分组解除封装并解密后,分配给该对等体的内部IP地址就显露出来了.除了内部IP地址,模式配置还向客户推送了其它参数,如DNS服务器IP地址,DHCP服务器IP地址等.

 

模式配置使用同X-AUTH一样的负载工作.它在X-AUTH后发生,同样在阶段1.5.网关向客户端推送它认为可以推送的那些属性到客户端.

5 NAT透明

NAT透明是一种为解决ESP中加密TCP/UDP端口时防止PAT发生问题而引入IPsec的机制.这个问题的解决是靠将ESP分组封装在UDP头中并附带必需的端口信息以使PAT能正确工作.一接收到这个分组,网关就剥去UDP头并正常处理分组的其余部分.IKE协商不存该问题,因为协商发生在使用UDP端口500时,只有ESP存在这个问题.

基于这种技术思想,即在UDP或TCP中封装IPsec数据包.主要使用到了三种技术手段,分别是:

(1) IPsec over UDP,这是CISCO专有的技术,这种技术就是直接把ESP封装进UDP中,利用UDP来实现地址转换.

(2) NAT-T 基于标准的IPsec over UDP

NAT-T是IETF提出的基于标准的IPsec over UDP方案.NAT-T用来执行二种任务:检查是否二端都支持NAT-T,并检查传输路径中的中间NAT设备.第一项任务地完成是依赖于他们会交换一个供应商身份的数据包来确实是否都能支持NAT-T.第二项任务地完成是依赖于他们各自向对方发送二个NAT-D载荷数据包,每个NAT-D载荷数据包都是原始IP地址和端口号的散列.它们相互收到对方的数据包后执行散列算法,最终比较散列值是否匹配来决定中间路径是否有NAT设备.

(3) IPsec over TCP:CISCO专有

IPsec over TCP,这是CISCO专有的技术,这种技术是把ESP封装进TCP中,利用TCP来实现地址转换.

6 IPsec失效等体发现机制

IPsec提供了一种当对等体发现其一个IPsec断开连接时,通过IKE发送一个删除通知负载到该对等体的机制.不过,在通常情况下,这种通知负载并不能被发送,这可能是由于该对等体连接断开得非常突然(系统崩溃),也可能是网络原因(有人将膝上型电脑的以太网线拔掉了).在这种情况下,有一个对等体崩溃的发现机制非常重要,它可以避免由于向不再活跃的对等体发送分组而导致数据损失(这是很有效的,IPsec对等体可以在时间的扩展期内持续向崩溃对等体发送流).这种机制靠一种称为失效对等体发现(Dead Peer Discovery,DPD)的技术实现.

DPD通过使用通知负载工作,该负载在对等体的非活跃时间超过所配置的“担扰的度量”之后以及新数据将要发送之前发送给对等体.IPsec流量数据被认为是对等体处于生存期的标志.如果对等体处于活跃状态,对等体就在接收到通知负载后返回一个它自己的通知负载作为应答.

为这种机工作,供应商ID负载必须在IKE主模式交换中交换,这意味着二个主机都要支持该机制.“担扰的度量”都是在本地定义的.这种仅基于需求的机制大大减少了对等体的负担,因为这不会使用可能南非要也可能不需要的周期性keeplive.同样,DPD机制也允许在网关过一段时间后想要整理其资源并查看一些空闲客户端是否仍然活跃的进修发送R-U-THERE消息.

 

7 NAT同IPsec相互作用

因为隧道模式下的IPsec隐藏了私有IP地址,为进入IPsec隧道的流量做网络地址转换(NAT)没有必要了.实际上,通常都不需要为进入隧道的流量做NAT.这在通过VPN网络连接的二个网路的管理员想要允许二个网络的用户可以使用同一IP就可以访问这二个网络的所有资源的环境下是正确的.这意味着网络A上的用户可以访问网络A上使用IP地址10.1.1.1的服务器,通过VPN连接到网络A的网络B上的用户就能连接到这个IP地址为10.1.1.1的服务器,而不用管在网络A前面的IPsec路由器是否有一个该服务器的适适静态的NAT转换以允许从INTERNET上来的连接.

下面的配置中给出了忽略NAT进入IPsec隧道的一种方法.忽略IPsec是为了使用特定策略路由技巧.现在,感兴趣流量从INSIDE端口进来从OUTSIDE端口出去,有什么方法可以绕过NAT呢?可以使用策略路由,把从INSIDE端口进来的流量策略到一个环回接口,而环回接口没有配置IP NAT INSIDE命令,现在,路由器以为流量是从环回接口来去往隧道另一端,所以,将不执行NAT,直接送入隧道.

 

这种思想是一种经典!

 

例子:

本实例研究中路由器NATRTR的配置

Router#write terminal

hostname NATRTR

crypto map test 10 IPsec-isakmp

 set peer 1.1.1.1

 set transform-set transform

 match address 100

This is the loopback the traffic will be routed to in order to change the order of events on the router

interface Loopback1

ip address 10.2.2.2 255.255.255.252

interface Ethernet0/0

 ip address 1.1.1.2 255.255.255.0

 ip nat outside

 crypto map test

interface Ethernet0/1

 ip address 10.1.1.1 255.255.255.0

 ip nat inside

 ip route-cache policy

The policy route map below is used to force the IPsec interesting traffic to the loopback interface.

 ip policy route-map nonat

This is the dynamic NAT configuration we are trying to bypass.

ip nat inside source access-list 1 interface Ethernet0/0 overload

access-list 1 permit 10.0.0.0 0.255.255.255

The access list below defines IPsec interesting traffic.

access-list 100 permit ip 10.1.1.0 0.0.0.255 10.1.2.0 0.0.0.255

The access list below defines the traffic that is to be used by the route map nonat to route to the loopback interface.

access-list 120 permit ip 10.1.1.0 0.0.0.255 10.1.2.0 0.0.0.255

Below is the route map used to route the traffic matching access list 120 to the loopback interface.

route-map nonat permit 10

 match ip address 120

 set ip next-hop 10.2.2.1

8 IPsec隧道终点发现(TED)

本实例研究包括了CISCO路由器实现中提供的特殊属性.TED允许路由器动态配置其IPsec对等体地址而不用在路由调协中手动配置.这种可扩展特性很有用,它使创建数目众多的对等体仅需定义一个它们感兴趣的流量访问列表并允许TED找出这些对等体窨是哪能些即可.重要的是,如果VPN创建在INTERNET上,那么感兴趣的流量必须使用全局可路由地址定义.这是必须的,因为TED使用一般路由以计算出IPsec对等体的位置.

TED靠发送一个分组,该探测分组的目的地址为定义感兴趣流量的访问控制列表中的目的地址.这个探测分组终止于目的IP地址前的IPsec路由器.该路由器收集关于代理ID的必须信息,并返回一个探测应答,应答中包含相同代理和自己的IP地址.发起者收到该响应消息后就开始IKE的协商.

例子:

配置TED-Initiator路由器:

TED-Initiator#show running-config

Building configuration...

Current configuration:

version 12.0

service timestamps debug uptime

service timestamps log uptime

hostname TED-Initiator

enable secret 5 <removed>

enable password <removed>

ip subnet-zero

crypto isakmp policy 10

 authentication pre-share

One of the issues with using a preshared key with TED is the need to use a wildcard preshared key because the peer's address is not known beforehand. A resolution to this is to use digital certificate-based digital signatures as the authentication method.

crypto isakmp key abc123 address 0.0.0.0

crypto ipsec transform-set ted-transforms esp-des esp-md5-hmac

Note that no peer address has been configured in the crypto map below.

crypto dynamic-map ted-map 10

 set transform-set ted-transforms

 match address 101

The keyword discover in the crypto map below triggers the use of TED

crypto map tedtag 10 ipsec-isakmp dynamic ted-map discover

interface Ethernet0/0

 ip address 13.13.13.13 255.255.255.0

 no ip directed-broadcast

 no mop enabled

interface Ethernet0/1

 ip address 11.11.11.1 255.255.255.0

 crypto map tedtag

ip classless

ip route 0.0.0.0 0.0.0.0 11.11.11.2

no ip http server

access-list 101 permit ip 13.13.13.0 0.0.0.255 12.12.12.0 0.0.0.255

access-list 101 permit icmp 13.13.13.0 0.0.0.255 12.12.12.0 0.0.0.255

line con 0

 transport input none

line aux 0

line vty 0 4

 password ww

 login

end

配置TED-Responder路由器:

TED-Responder#show running-config

Building configuration...

Current configuration:

version 12.0

service timestamps debug uptime

service timestamps log uptime

hostname TED-Responder

enable secret 5 <removed>

enable password <removed>

crypto isakmp policy 10

 authentication pre-share

crypto isakmp key abc123 address 0.0.0.0

crypto ipsec transform-set ted-transforms esp-des esp-md5-hmac

crypto dynamic-map ted-map 10

 set transform-set ted-transforms

 match address 101

crypto map tedtag 10 ipsec-isakmp dynamic ted-map discover

interface Ethernet0/0

 ip address 12.12.12.12 255.255.255.0

 no ip directed-broadcast

 no mop enabled

interface Ethernet0/1

 ip address 11.11.11.2 255.255.255.0

 crypto map tedtag

ip classless

ip route 0.0.0.0 0.0.0.0 11.11.11.1

no ip http server

access-list 101 permit ip 12.12.12.0 0.0.0.255 13.13.13.0 0.0.0.255

access-list 101 permit icmp 12.12.12.0 0.0.0.255 13.13.13.0 0.0.0.255

line con 0

 transport input none

line aux 0

line vty 0 4

 password ww

 login

no scheduler allocate

end

在TED-Initiator路由器中的debug:

TED-Initiator#show debug

Cryptographic Subsystem:

  Crypto ISAKMP debugging is on

  Crypto Engine debugging is on

  Crypto IPSEC debugging is on

TED-Initiator#

The TED process has started. The proxy IDs are shown in the message below.

01:33:56: IPSEC(tunnel discover request): ,

  (key eng. msg.) src= 13.13.13.14, dest= 12.12.12.13,

    src_proxy= 13.13.13.0/255.255.255.0/0/0 (type=4),

    dest_proxy= 11.11.11.1/255.255.255.255/0/0 (type=1),

    protocol= ESP, transform= esp-des esp-md5-hmac ,

    lifedur= 3600s and 4608000kb,

    spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4044

01:33:56: GOT A PEER DISCOVERY MESSAGE FROM THE SA MANAGER!!!

01:33:56: src = 13.13.13.14 to 12.12.12.13, protocol 3, transform 2, hmac 1

The TED process below determines which address is the source address in the TED packet and which addresses are the proxy IDs.

01:33:56: proxy source is 13.13.13.0     /255.255.255.0   and my address (not used now) is 11.11.11.1

01:33:56: ISAKMP (1): ID payload

        next-payload : 5

        type         : 1

        protocol     : 17

        port         : 500

        length       : 8

01:33:56: ISAKMP (1): Total payload length: 12

The initiator determines below that the first ID payload will be its own IP address, 11.11.11.1, and the second payload contains its source IPsec proxy:13.13.13.0/24

01:33:56: 1st ID is 11.11.11.1

01:33:56: 2nd ID is 13.13.13.0     /255.255.255.0

01:33:56: ISAKMP (0:1): beginning peer discovery exchange

The TED probe is being sent to the destination IP address found in the original packet that was received on the initiator and that matched the IPsec interesting traffic access list.

01:33:56: ISAKMP (1): sending packet to 12.12.12.13 (I) PEER_DISCOVERY

The peer has been discovered to be 12.12.12.13, and it responds as shown below

01:33:56: ISAKMP (1): received packet from 12.12.12.13 (I) PEER_DISCOVERY

Upon processing the vendor ID payload, the initiator ascertains that the responder does indeed understand what was sent to it.

01:33:56: ISAKMP (0:1): processing vendor id payload

01:33:56: ISAKMP (0:1): speaking to another IOS box!

01:33:56: ISAKMP (0:1): processing ID payload. message ID = 0

The responder's IP address is encoded in the ID payload. It is equal to 11.11.11.2

01:33:56: ISAKMP (0:1): processing ID payload. message ID = 1168952014

Upon looking at the ID payload sent by the responder, the initiator finds that the responder's proxy ID indeed matches the proxy configured on itself.

01:33:56: ISAKMP (1): ID_IPV4_ADDR_SUBNET dst 12.12.12.0/255.255.255.0 prot 0 port 0

01:33:56: ISAKMP (1): received response to my peer discovery probe!

Normal IKE processing starts at this point to the IP address discovered through TED

01:33:56  ISAKMP: initiating IKE to 11.11.11.2 in response to probe.

01:33:56: ISAKMP (2): sending packet to 11.11.11.2 (I) MM_NO_STATE

01:33:56: ISAKMP (0:1): deleting SA

01:33:56: ISAKMP (2): received packet from 11.11.11.2 (I) MM_NO_STATE

01:33:56: ISAKMP (0:2): processing SA payload. message ID = 0

01:33:56: ISAKMP (0:2): Checking ISAKMP transform 1 against priority 10 policy

01:33:56: ISAKMP:      encryption DES-CBC

01:33:56: ISAKMP:      hash SHA

01:33:56: ISAKMP:      default group 1

01:33:56: ISAKMP:      auth pre-share

01:33:56: ISAKMP (0:2): atts are acceptable. Next payload is 0

01:33:56: CryptoEngine0: generate alg parameter

01:33:56: CRYPTO_ENGINE: Dh phase 1 status: 0

01:33:56: CRYPTO_ENGINE: Dh phase 1 status: 0

01:33:56: ISAKMP (0:2): SA is doing pre-shared key authentication

01:33:56: ISAKMP (2): SA is doing pre-shared key authentication using id type ID_IPV4_ADDR

01:33:56: ISAKMP (2): sending packet to 11.11.11.2 (I) MM_SA_SETUP

01:33:56: ISAKMP (2): received packet from 11.11.11.2 (I) MM_SA_SETUP

01:33:56: ISAKMP (0:2): processing KE payload. message ID = 0

01:33:56: CryptoEngine0: generate alg parameter

01:33:57: ISAKMP (0:2): processing NONCE payload. message ID = 0

01:33:57: CryptoEngine0: create ISAKMP SKEYID for conn id 2

01:33:57: ISAKMP (0:2): SKEYID state generated

01:33:57: ISAKMP (0:2): processing vendor id payload

01:33:57: ISAKMP (0:2): speaking to another IOS box!

01:33:57: ISAKMP (2): ID payload

        next-payload : 8

        type         : 1

        protocol     : 17

        port         : 500

        length       : 8

01:33:57: ISAKMP (2): Total payload length: 12

01:33:57: CryptoEngine0: generate hmac context for conn id 2

01:33:57: ISAKMP (2): sending packet to 11.11.11.2 (I) MM_KEY_EXCH

01:33:57: ISAKMP (2): received packet from 11.11.11.2 (I) MM_KEY_EXCH

01:33:57: ISAKMP (0:2): processing ID payload. message ID = 0

01:33:57: ISAKMP (0:2): processing HASH payload. message ID = 0

01:33:57: CryptoEngine0: generate hmac context for conn id 2

01:33:57: ISAKMP (0:2): SA has been authenticated with 11.11.11.2

01:33:57: ISAKMP (0:2): beginning Quick Mode exchange, M-ID of 474637101

01:33:57: CryptoEngine0: clear dh number for conn id 1

01:33:57: IPSEC(key_engine): got a queue event...

01:33:57: IPSEC(spi_response): getting spi 348588451 for SA from 11.11.11.2      to 11.11.11.1      for prot 3

01:33:57: CryptoEngine0: generate hmac context for conn id 2

01:33:57: ISAKMP (2): sending packet to 11.11.11.2 (I) QM_IDLE

01:33:57: ISAKMP (2): received packet from 11.11.11.2 (I) QM_IDLE

01:33:57: CryptoEngine0: generate hmac context for conn id 2

01:33:57: ISAKMP (0:2): processing SA payload. message ID = 474637101

01:33:57: ISAKMP (0:2): Checking IPsec proposal 1

01:33:57: ISAKMP: transform 1, ESP_DES

01:33:57: ISAKMP:   attributes in transform:

01:33:57: ISAKMP:      encaps is 1

01:33:57: ISAKMP:      SA life type in seconds

01:33:57: ISAKMP:      SA life duration (basic) of 3600

01:33:57: ISAKMP:      SA life type in kilobytes

01:33:57: ISAKMP:      SA life duration (VPI) of  0x0 0x46 0x50 0x0

01:33:57: ISAKMP:      authenticator is HMAC-MD5

01:33:57: validate proposal 0

01:33:57: ISAKMP (0:2): atts are acceptable.

01:33:57: IPSEC(validate_proposal_request): proposal part #1,

  (key eng. msg.) dest= 11.11.11.2, src= 11.11.11.1,

    dest_proxy= 12.12.12.0/255.255.255.0/0/0 (type=4),

    src_proxy= 13.13.13.0/255.255.255.0/0/0 (type=4),

    protocol= ESP, transform= esp-des esp-md5-hmac ,

    lifedur= 0s and 0kb,

    spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4

01:33:57: validate proposal request 0

01:33:57: ISAKMP (0:2): processing NONCE payload. message ID = 474637101

01:33:57: ISAKMP (0:2): processing ID payload. message ID = 474637101

01:33:57: ISAKMP (0:2): processing ID payload. message ID = 474637101

01:33:57: CryptoEngine0: generate hmac context for conn id 2

01:33:57: ipsec allocate flow 0

01:33:57: ipsec allocate flow 0

01:33:57: ISAKMP (0:2): Creating IPsec SAs

01:33:57:         inbound SA from 11.11.11.2 to 11.11.11.1      (proxy 12.12.12.0 to 13.13.13.0)

01:33:57:         has spi 348588451 and conn_id 2000 and flags 4

01:33:57:         lifetime of 3600 seconds

01:33:57:         lifetime of 4608000 kilobytes

01:33:57:         outbound SA from 11.11.11.1 to 11.11.11.2      (proxy 13.13.13.0 to 12.12.12.0)

01:33:57:         has spi 132187477 and conn_id 2001 and flags 4

01:33:57:         lifetime of 3600 seconds

01:33:57:         lifetime of 4608000 kilobytes

01:33:57: ISAKMP (2): sending packet to 11.11.11.2 (I) QM_IDLE

01:33:57: ISAKMP (0:2): deleting node 474637101

01:33:57: IPSEC(key_engine): got a queue event...

01:33:57: IPSEC(initialize_sas): ,

  (key eng. msg.) dest= 11.11.11.1, src= 11.11.11.2,

    dest_proxy= 13.13.13.0/255.255.255.0/0/0 (type=4),

    src_proxy= 12.12.12.0/255.255.255.0/0/0 (type=4),

    protocol= ESP, transform= esp-des esp-md5-hmac ,

    lifedur= 3600s and 4608000kb,

    spi= 0x14C709A3(348588451), conn_id= 2000, keysize= 0, flags= 0x4

01:33:57: IPSEC(initialize_sas): ,

  (key eng. msg.) src= 11.11.11.1, dest= 11.11.11.2,

    src_proxy= 13.13.13.0/255.255.255.0/0/0 (type=4),

dest_proxy= 12.12.12.0/255.255.255.0/0/0 (type=4),

    protocol= ESP, transform= esp-des esp-md5-hmac ,

    lifedur= 3600s and 4608000kb,

    spi= 0x7E10555(132187477), conn_id= 2001, keysize= 0, flags= 0x4

01:33:57: IPSEC(create_sa): sa created,

  (sa) sa_dest= 11.11.11.1, sa_prot= 50,

    sa_spi= 0x14C709A3(348588451),

    sa_trans= esp-des esp-md5-hmac , sa_conn_id= 2000

01:33:57: IPSEC(create_sa): sa created,

  (sa) sa_dest= 11.11.11.2, sa_prot= 50,

    sa_spi= 0x7E10555(132187477),

    sa_trans= esp-des esp-md5-hmac , sa_conn_id= 2001

TED-Initiator路由器show命令输出:

TED-Initiator#show crypto ipsec sa

interface: Ethernet0/1

    Crypto map tag: tedtag, local addr. 11.11.11.1

   local  ident (addr/mask/prot/port): (13.13.13.0/255.255.255.0/0/0)

   remote ident (addr/mask/prot/port): (12.12.12.0/255.255.255.0/0/0)

   current_peer: 11.11.11.2

     PERMIT, flags={}

    #pkts encaps: 9, #pkts encrypt: 9, #pkts digest 9

    #pkts decaps: 9, #pkts decrypt: 9, #pkts verify 9

    #pkts compressed: 0, #pkts decompressed: 0

    #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0

    #send errors 0, #recv errors 0

     local crypto endpt.: 11.11.11.1, remote crypto endpt.: 11.11.11.2

     path mtu 1500, media mtu 1500

     current outbound spi: 7E10555

     inbound esp sas:

      spi: 0x14C709A3(348588451)

        transform: esp-des esp-md5-hmac ,

        in use settings ={Tunnel, }

        slot: 0, conn id: 2000, flow_id: 1, crypto map: tedtag

        sa timing: remaining key lifetime (k/sec): (4607998/3557)

        IV size: 8 bytes

        replay detection support: Y

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:

      spi: 0x7E10555(132187477)

        transform: esp-des esp-md5-hmac ,

        in use settings ={Tunnel, }

        slot: 0, conn id: 2001, flow_id: 2, crypto map: tedtag

        sa timing: remaining key lifetime (k/sec): (4607998/3557)

        IV size: 8 bytes

        replay detection support: Y

     outbound ah sas:

     outbound pcp sas:


  <欢迎投稿>  <论坛讨论>
 »相关文章  »论坛新贴
精彩文章 活动资讯 今日头条