科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网›网络频道 ›全系列VPN技术集锦第一卷第2章(Site-to-Site IPsec VPN)

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

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

IPsec VPN原理描述 1 IPsec VPN的分类 可以从多个角度给IPsec VPN分类,不过,看一下IPsec VPN试图解决的VPN二个主要设计问题是很有意义的. --为把二个专用的网络组合成一个虚拟网络的无缝连接. --将虚 ...

作者：论坛整理 来源：zdnet网络安全 2008年1月19日

关键字： 安全防护 防火墙 VPN

  • 评论
  • 分享微博
  • 分享邮件

实例研究

 

使用预共享密钥作为认证机制的路由器到路由器的IPsec

 

这是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

Initiator#show 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.

00:04:10: IPSEC(sa_request):

 

  (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
    • 评论
    • 分享微博
    • 分享邮件
    VIP专区
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息，那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章

    业界热点:

    北京第二十六维信息技术有限公司（至顶网）版权所有. 京ICP备15039648号-7 京ICP证161336号 京公网安备 11010802021500号