antiCisco blogs

Опубликовано Minorioo 15 Январь , 2014

Сначала рассмотрим настройку L2L IPsec-туннеля в случае, когда защищаемая сеть находится внутри VRF, а транспорт идет через global. В целом настройка тривиальная. Однако, хочу обратить внимание вот на что: в конфиге pre—shared—key указан не в режиме глобальной конфигурации, а внутри crypto keyring, который далее применяется к isakmp profile, а тот в свою очередь завязан на ipsec profile. Для чего такой геморрой, спросите вы? В данной ситуации это действительно излишне, но такой подход позволяет легко из данного конфига перейти к варианту IPsec-туннеля между различными VRF.

ip vrf VRF_INSIDE

 rd 10:1

crypto keyring KEYRING

 pre-shared-key address 136.1.23.3 key CISCO

crypto isakmp profile PROF_ISA

 keyring KEYRING

 match identity address 136.1.23.3

 local-address Loopback0

crypto ipsec profile PROF_IPSEC

 set transform-set 3DES-SHA

 set isakmp-profile PROF_ISA

interface Tunnel0

 ip vrf forwarding VRF_INSIDE

 ip address 192.168.13.1 255.255.255.0

 tunnel source 136.1.12.1

 tunnel destination 136.1.23.3

 tunnel mode ipsec ipv4

 tunnel protection ipsec profile PROF_IPSEC

interface Loopback0

 ip vrf forwarding VRF_INSIDE

 ip address 1.1.1.1 255.255.255.255

ip route vrf VRF_INSIDE 3.3.3.3 255.255.255.255 Tu0

Для проверки воспользуемся обыкновенным пингом между Loopback-интерфейсами двух маршрутизаторов и командами show.

R1#ping vrf VRF_INSIDE 3.3.3.3 so LO0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:

Packet sent with a source address of 1.1.1.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 220/249/276 ms

R1#show crypto isakmp sa

IPv4 Crypto ISAKMP SA

dst             src             state          conn-id status

136.1.23.3      136.1.12.1      QM_IDLE           1001 ACTIVE

136.1.12.1      136.1.23.3      QM_IDLE           1002 ACTIVE

R1#show crypto ipsec sa

interface: Tunnel0

    Crypto map tag: Tunnel0-head-0, local addr 136.1.12.1

   protected vrf: VRF_INSIDE

   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)

   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)

   current_peer 136.1.23.3 port 500

     PERMIT, flags={origin_is_acl,}

    #pkts encaps: 10, #pkts encrypt: 10, #pkts digest: 10

    #pkts decaps: 10, #pkts decrypt: 10, #pkts verify: 10

     local crypto endpt.: 136.1.12.1, remote crypto endpt.: 136.1.23.3

     current outbound spi: 0xE66AEBFD(3865766909)

     inbound esp sas:

      spi: 0xAC95DDE8(2895502824)

        transform: esp-3des esp-sha-hmac ,

        in use settings ={Tunnel, }

        Status: ACTIVE(ACTIVE)

А теперь отнесем внешний интерфейс маршрутизатора к другой vrf: VRF_OUTSIDE. В чем же тут сложность? А все дело вот в чем: представьте, что удаленная сторона пытается инициировать туннеля с вашим маршрутизатором, соответственно пакет прилетает на интерфейс внутри VRF_OUTSIDE. А сама защищаемая сеть находится за VRF_INSIDE, т.е. нужен ликинг между vrf-ми на data-plane. Осуществляется это с помощью crypto keyring!

Его настройка становится следующей:

R1(config)#crypto keyring KEYRING-OUTSIDE vrf VRF_OUTSIDE

Плюс ко всему необходимо внутри isakmp profile матчить identity пира внутри VRF_OUTSIDE.

Весь конфиг целиком:

ip vrf VRF_INSIDE

 rd 10:1

ip vrf VRF_OUTSIDE

 rd 20:1

crypto keyring KEY-OUTSIDE vrf VRF_OUTSIDE

  pre-shared-key address 136.1.23.3 key CISCO

crypto isakmp policy 10

 encr aes

 authentication pre-share

crypto isakmp profile PROF_ISA-OUTSIDE

 keyring KEY-OUTSIDE

 match identity address 136.1.23.3 255.255.255.255 VRF_OUTSIDE

crypto ipsec transform-set 3DES-SHA esp-3des esp-sha-hmac

 mode tunnel

crypto ipsec profile PROF_IPSEC-OUTSIDE

 set transform-set 3DES-SHA

 set isakmp-profile PROF_ISA-OUTSIDE

interface Tunnel0

 ip vrf forwarding VRF_INSIDE

 ip address 172.16.13.1 255.255.255.0

 tunnel source 136.1.12.1

 tunnel mode ipsec ipv4

 tunnel destination 136.1.23.3

 tunnel vrf VRF_OUTSIDE

 tunnel protection ipsec profile PROF_IPSEC-OUTSIDE

interface Lo0

 ip vrf forwarding VRF_INSIDE

 ip address 1.1.1.1 255.255.255.255

interface Fa0/0

 ip vrf forwarding VRF_OUTSIDE

 ip address 136.1.12.1 255.255.255.0

ip route vrf VRF_OUTSIDE 136.1.23.3 255.255.255.255 136.1.12.2

Остановиться отдельно хотелось бы на настройке interface Tunnel. Вы могли заметить команду tunnel vrf VRF_OUTSIDE. Для чего же она нужна? Дело в том, что по-умолчанию IOS пытается строить IPsec через global. Чтобы изменить это поведение (у нас IPsec терминируется внутри vrf) и необходима эта команда.

Проверка:

R1#ping vrf VRF_INSIDE 172.16.13.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.16.13.3, timeout is 2 seconds:

!!.!!

Success rate is 80 percent (4/5), round-trip min/avg/max = 180/241/292 ms

R1#show crypto isa sa detail

Codes: C - IKE configuration mode, D - Dead Peer Detection

       K - Keepalives, N - NAT-traversal

       T - cTCP encapsulation, X - IKE Extended Authentication

       psk - Preshared key, rsig - RSA signature

       renc - RSA encryption

IPv4 Crypto ISAKMP SA

C-id  Local           Remote          I-VRF  Status Encr Hash   Auth DH Lifetime Cap.

1001  136.1.12.1      136.1.23.3      VRF_IN ACTIVE aes  sha    psk  1  23:48:12

       Engine-id:Conn-id =  SW:1

IPv6 Crypto ISAKMP SA

R1#show crypto ipsec sa

interface: Tunnel0

    Crypto map tag: Tunnel0-head-0, local addr 136.1.12.1

   protected vrf: VRF_INSIDE

   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)

   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)

   current_peer 136.1.23.3 port 500

     PERMIT, flags={origin_is_acl,}

    #pkts encaps: 15, #pkts encrypt: 15, #pkts digest: 15

    #pkts decaps: 13, #pkts decrypt: 13, #pkts verify: 13

     local crypto endpt.: 136.1.12.1, remote crypto endpt.: 136.1.23.3

Метки: IPSec, vrf
Опубликовано: Безопасность cisco , Маршрутизаторы и коммутаторы