antiCisco blogs


блоги по технологиям и оборудованию cisco от инструкторов

Опубликовано 8 Июнь , 2012

Прим.: ахтунг, много букавок!

В прошлой статье мы с Вами уяснили как устанавливается защищенный IPsec туннель между двумя маршрутизаторами. Но теория это конечно хорошо, сейчас мне бы с Вами хотелось рассмотреть практическую часть: настройка LAN-to-LAN с помощью crypto-map.

И так, перво-наперво необходимо определить политики первой фазы: для ее защиты используем шифрование AES 192 бита, проверка целостности проходит по ф-ии SHA второй версии с выходным хэшем 384 бита, аутентификация между пирами — по локальному ключу, время жизни сессии — сутки, номер группы ДХ — 15.

crypto isakmp policy 10
encr aes 192
hash sha384
authentication pre-share
group 15

Прим.: в версиях 12.4 ф-ия sha version 2 недоступна, равно как и «большие» группы ДХ

Далее задаем секретный ключ для аутентификации пиров друг с другом

crypto isakmp key CISCO address 10.250.250.3

Следующим шагом создаем настройки для второй фазы IPsec: шифрование 3des, проверка целостности по SHA-384

crypto ipsec transform-set SET_3DES-SHA384 esp-3des esp-sha384-hmac

После этого необходимо описать «интересный трафик» — т.е. тот, который необходимо шифровать.

ip access-list extended ACL_L2L
permit ip 172.16.1.0 0.0.0.255 172.16.3.0 0.0.0.255

И поскольку сначала в IOS производится NAT, а только потом IPsec — выводим трафик между двумя сетями их под трансляций

ip access-list extended ACL_NAT
5 deny ip 172.16.1.0 0.0.0.255 172.16.3.0 0.0.0.255

Создаем крипто-карту, в которой описываем созданные параметры

crypto map CRMAP_L2L 10 ipsec-isakmp
set peer 10.250.250.3
set transform-set SET_3DES-SHA384
match address ACL_L2L

Как Вы могли заметить, то IPsec-туннель мы пытаемся построить между Loopback-интерфейсами. Но! Трафик то идет с интерфейсом Serial 1/0, и ip source адреса у пакетов будут соответствующие. Что же делать? Одним из вариантов решения такого казуса является финт ушами:

route-map MAP_L2L-LOOP permit 10
match ip address ACL_L2L
set interface Loopback0
ip local policy route-map MAP_L2L-LOOP
!
interface Loopback0
crypto map CRMAP_L2L

Т.е. весь трафик, который мы хотим зашифровать между офисами заворачиваем на Loopback 0 и на этот интерфейс вешаем crypto-map. На сим и успокоимся 🙂

Прим.: вторым вариантом решения проблемы является команда crypto map CRMAP_L2L local-address Loopback 0. В этом случае, crypto-map вешается на физический интерфейс, но ip source для всех пакетов будет изменен. В целом, такой вариант более предпочтителен, чем заворачивание трафика на Loopback, поскольку все пакеты, которые идут на логический интерфейс обрабатываются по process switching

Теперь запускаем пинг между локальными сетями, которые находятся за маршрутизаторами:

R3#ping 172.16.1.1 so Loopback 10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
Packet sent with a source address of 172.16.3.3
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 144/161/192 ms

Как вы видите — связь между офисами есть, профит! 🙂 Но! Как можно заметить, первый пакет (а иногда и больше) теряется. Почему? — причиной этого является тот факт, что IPsec туннель строится на сразу после конфигурации, а только по-требованию, т.е. когда есть интересный трафик. Соответственно, если первоначально туннеля нет и тут вдруг появляется трафик для шифрования, то маршрутизаторам между собой первоначально надо обо всем договориться (что и как шифровать) — а на это требуется время, вот пакет и теряется. Давайте посмотрим, что же происходит в этот самый момент времени: (запускаем debug crypto isakmp)

R3#ping 172.16.1.1 so Loopback 10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
Packet sent with a source address of 172.16.3.3

 

С самого начала маршрутизатор пытается найти уже существующее Security Association (SA). Поскольку она не может быть сейчас найдена, маршрутизатор начинает инициацию ISAKMP-сессии.

 

ISAKMP:(0): SA request profile is (NULL)
ISAKMP: Created a peer struct for 10.250.250.1, peer port 500
ISAKMP: New peer created peer = 0x6A7DC96C peer_handle = 0x80000008
ISAKMP: Locking peer struct 0x6A7DC96C, refcount 1 for isakmp_initiator
ISAKMP: local port 500, remote port 500
ISAKMP: set new node 0 to QM_IDLE
ISAKMP: Find a dup sa in the avl tree during calling isadb_insert sa = 6A3C9130

 

По умолчанию для согласования выбирается агрессивный режим IKE, но поскольку мы отключили его, стартует обычный режим (Main mode). Основываясь на ISAKMP-политике, начинается просмотр локально сконфигурированных ключей для удаленного пира. Первый пакет IKE не будет отослан до тех пор, пока такой ключ не найден. Пакет инициализации сессии содержит в себе список локальных ISAKMP-политик

 

ISAKMP:(0):Can not start Aggressive mode, trying Main mode.
ISAKMP:(0):found peer pre-shared key matching 10.250.250.1
ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID
ISAKMP:(0): constructed NAT-T vendor-07 ID
ISAKMP:(0): constructed NAT-T vendor-03 ID
ISAKMP:(0): constructed NAT-T vendor-02 ID
ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM
ISAKMP:(0):Old State = IKE_READY  New State = IKE_I_MM1
ISAKMP:(0): beginning Main Mode exchange
ISAKMP:(0): sending packet to 10.250.250.1 my_port 500 peer_port 500 (I) MM_NO_STATE
ISAKMP:(0):Sending an IKE IPv4 Packet.
ISAKMP (0): received packet from 10.250.250.1 dport 500 sport 500 Global (I) MM_NO_STATE

 

Только что локальный маршрутизатор получил ответ на сообщение инициализации сессии. В этом сообщении содержится ISAKMP-политика, выбранная удаленной стороной. Помимо этого, содержится дополнительная информация – Vendor ID.

 

ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
ISAKMP:(0):Old State = IKE_I_MM1  New State = IKE_I_MM2
ISAKMP:(0): processing SA payload. message ID = 0
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismatch
ISAKMP (0): vendor ID is NAT-T RFC 3947
ISAKMP:(0):found peer pre-shared key matching 10.250.250.1
ISAKMP:(0): local preshared key found
ISAKMP : Scanning profiles for xauth …

 

Маршрутизатор пытается проматчить политику, которая была выбрана удаленной стороной по списку локально настроенных политик первой фазы. Если совпадение найдено, система переходит к шагу обмена ключами (Key Exchange).

 

ISAKMP:(0):Checking ISAKMP transform 1 against priority 10 policy
ISAKMP:      encryption AES-CBC
ISAKMP:      keylength of 192
ISAKMP:      hash SHA384
ISAKMP:      default group 15
ISAKMP:      auth pre-share
ISAKMP:      life type in seconds
ISAKMP:      life duration (VPI) of  0x0 0x1 0x51 0x80
ISAKMP:(0):atts are acceptable. Next payload is 0
ISAKMP:(0):Acceptable atts:actual life: 0
ISAKMP:(0):Acceptable atts:life: 0
ISAKMP:(0):Fill atts in sa vpi_length:4
ISAKMP:(0):Fill atts in sa life_in_seconds:86400
ISAKMP:(0):Returning Actual lifetime: 86400
ISAKMP:(0)::Started lifetime timer: 86400.

 

ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismatch
ISAKMP (0): vendor ID is NAT-T RFC 3947
ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
ISAKMP:(0):Old State = IKE_I_MM2  New State = IKE_I_MM2

 

Далее высылается третье сообщение, которое содержит в себе KE в качестве полезной нагрузки.

 

ISAKMP:(0): sending packet to 10.250.250.1 my_port 500 peer_port 500 (I) MM_SA_SETUP
ISAKMP:(0):Sending an IKE IPv4 Packet.
ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
ISAKMP:(0):Old State = IKE_I_MM2  New State = IKE_I_MM3

 

Получен IKE-ответ от удаленного соседа. В данный момент, маршрутизаторы могут сгенерировать сессионный ключ базируясь на ДХ алгоритме и pre-shared ключе.

 

ISAKMP (0): received packet from 10.250.250.1 dport 500 sport 500 Global (I) MM_SA_SETUP
ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
ISAKMP:(0):Old State = IKE_I_MM3  New State = IKE_I_MM4

 

ISAKMP:(0): processing KE payload. message ID = 0
ISAKMP:(0): processing NONCE payload. message ID = 0
ISAKMP:(0):found peer pre-shared key matching 10.250.250.1
ISAKMP:(1005): processing vendor id payload
ISAKMP:(1005): vendor ID is Unity
ISAKMP:(1005): processing vendor id payload
ISAKMP:(1005): vendor ID is DPD
ISAKMP:(1005): processing vendor id payload
ISAKMP:(1005): speaking to another IOS box!
ISAKMP:received payload type 20
ISAKMP (1005): His hash no match — this node outside NAT
ISAKMP:received payload type 20
ISAKMP (1005): No NAT Found for self or peer
ISAKMP:(1005):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
ISAKMP:(1005):Old State = IKE_I_MM4  New State = IKE_I_MM4

 

Пятое и шестое сообщения вместе составляю IKE ID обмен и аутентификацию пиров Однако, как мной было замечено раньше, эти самые ID не используются для аутентификации в Main, так как сгенерированный сессионный ключ подразумевает под собой двустороннюю аутентификацию. Сообщение ниже содержит в себе локальный ID маршрутизатора.

 

ISAKMP:(1005):Send initial contact
ISAKMP:(1005):SA is doing pre-shared key authentication using id type ID_IPV4_ADDR
ISAKMP (1005): ID payload
        next-payload : 8
        type         : 1
        address      : 10.250.250.3
        protocol     : 17
        port         : 500
        length       : 12
ISAKMP:(1005):Total payload length: 12
ISAKMP:(1005): sending packet to 10.250.250.1 my_port 500 peer_port 500 (I) MM_KEY_EXCH
ISAKMP:(1005):Sending an IKE IPv4 Packet.
ISAKMP:(1005):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
ISAKMP:(1005):Old State = IKE_I_MM4  New State = IKE_I_MM5

 

Ответ на последнее сообщение содержит в себе ответный IKE ID. В данном случае от IP-адрес Loopback 0 маршрутизатора R1.

 

ISAKMP (1005): received packet from 10.250.250.1 dport 500 sport 500 Global (I) MM_KEY_EXCH
ISAKMP: (1005): processing ID payload. Message ID = 0
ISAKMP: (1005): ID payload
        next-payload : 8
        type         : 1
        address      : 10.250.250.1
        protocol     : 17
        port         : 500
        length       : 12
ISAKMPL0):: peer matches *none* of the profiles
ISAKMP: (1005): processing HASH payload. Message ID = 0
ISAKMP:(1005):SA authentication status:
        authenticated
ISAKMP:(1005):SA has been authenticated with 10.250.250.1
ISAKMP: Trying to insert a peer 10.250.250.3/10.250.250.1/500/,  and inserted successfully 6A7DC96C.
ISAKMP:(1005):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
ISAKMP:(1005):Old State = IKE_I_MM5  New State = IKE_I_MM6

 

ISAKMP (1005): received packet from 10.250.250.1 dport 500 sport 500 Global (I) MM_KEY_EXCH
ISAKMP: set new node 31880102 to QM_IDLE
ISAKMP:(1005): processing HASH payload. Message ID = 31880102
ISAKMP:(1005): processing DELETE payload. Message ID = 31880102
ISAKMP:(1005):peer does not do paranoid keepalives.

 

ISAKMP:(1005):deleting node 31880102 error FALSE reason “Informational (in) state 1”
ISAKMP:(1005):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
ISAKMP:(1005):Old State = IKE_I_MM6  New State = IKE_I_MM6

 

ISAKMP:(1005):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
ISAKMP:(1005):Old State = IKE_I_MM6  New State = IKE_P1_COMPLETE

 

После завершения первой фазы сразу стартует вторая фаза IPsec в быстром режиме (Quick Mode). Сообщение инициации содержит в себе локальное Proxy ID и политики безопасности локального маршрутизатора (алгоритм шифрования, хэш ф-ия и пр.)

 

ISAKMP:(1005):beginning Quick Mode exchange, M-ID of 421917716
ISAKMP:(1005):QM Initiator gets spi
ISAKMP:(1005): sending packet to 10.250.250.1 my_port 500 peer_port 500 (I) QM_IDLE
ISAKMP:(1005):Sending an IKE IPv4 Packet.
ISAKMP:(1005):Node 421917716, Input = IKE_MESG_INTERNAL, IKE_INIT_QM
ISAKMP:(1005):Old State = IKE_QM_READY  New State = IKE_QM_I_QM1
ISAKMP:(1005):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
ISAKMP:(1005):Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE

 

Следующее сообщение – ответ от соседа. Дебаг показывает  transform-set, который был выбран удаленной стороной и другие SA-параметры.

 

ISAKMP (1005): received packet from 10.250.250.1 dport 500 sport 500 Global (I) QM_IDLE
ISAKMP:(1005): processing HASH payload. message ID = 421917716
ISAKMP:(1005): processing SA payload. message ID = 421917716
ISAKMP:(1005):Checking IPSec proposal 1
ISAKMP: transform 1, ESP_3DES
ISAKMP:   attributes in transform:
ISAKMP:      encaps is 1 (Tunnel)
ISAKMP:      SA life type in seconds
ISAKMP:      SA life duration (basic) of 3600
ISAKMP:      SA life type in kilobytes
ISAKMP:      SA life duration (VPI) of  0x0 0x46 0x50 0x0
ISAKMP:      authenticator is HMAC-SHA384
ISAKMP:(1005):atts are acceptable.
ISAKMP:(1005): processing NONCE payload. message ID = 421917716
ISAKMP:(1005): processing ID payload. message ID = 421917716
ISAKMP:(1005): processing ID payload. message ID = 421917716
ISAKMP:(1005): Creating IPSec SAs
        inbound SA from 10.250.250.1 to 10.250.250.3 (f/i)  0/ 0
        (proxy 172.16.1.0 to 172.16.3.0)
        has spi 0xB137F9B8 and conn_id 0
        lifetime of 3600 seconds
        lifetime of 4608000 kilobytes
        outbound SA from 10.250.250.3 to 10.250.250.1 (f/i) 0/0
        (proxy 172.16.3.0 to 172.16.1.0)
        has spi  0x6E55B6EF and conn_id 0
        lifetime of 3600 seconds
        lifetime of 4608000 kilobytes

 

Последний пакет QM завершает согласование IPsec-канала. Сейчас обе стороны процесса могут обмениваться шифрованный трафиком.

 

ISAKMP:(1005): sending packet to 10.250.250.1 my_port 500 peer_port 500 (I) QM_IDLE
ISAKMP:(1005):Sending an IKE IPv4 Packet.
ISAKMP:(1005):deleting node 421917716 error FALSE reason «No Error»
ISAKMP:(1005):Node 421917716, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH
ISAKMP:(1005):Old State = IKE_QM_I_QM1  New State = IKE_QM_PHASE2_COMPLETE

Дебаг это дело хорошее, но есть еще и команды типа show 🙂

Посмотреть состояние ISAKMP:

R3#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
10.250.250.1    10.250.250.3    QM_IDLE           1001 ACTIVE
 

Если в графе «state» стоит QM_IDLE, а в «status» ACTIVE — то все хорошо — все политики согласованы и туннель скорее всего установлен.

Чтобы посмотреть информацию об IPsec-трафике (сколько зашифровано, сколько расшифровано, какие политики применяются):

R3#show crypto ipsec sa

 

interface: Loopback0
    Crypto map tag: CRMAP_L2L, local addr 10.250.250.3

 

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (172.16.3.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (172.16.1.0/255.255.255.0/0/0)
   current_peer 10.250.250.1 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 8, #pkts encrypt: 8, #pkts digest: 8
    #pkts decaps: 8, #pkts decrypt: 8, #pkts verify: 8
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 2, #recv errors 0

 

     local crypto endpt.: 10.250.250.3, remote crypto endpt.: 10.250.250.1
     path mtu 1514, ip mtu 1514, ip mtu idb Loopback0
     current outbound spi: 0x4B4B88F6(1263241462)
     PFS (Y/N): N, DH group: none

 

     inbound esp sas:
      spi: 0x282FD762(674223970)
        transform: esp-3des esp-sha384-hmac ,
        in use settings ={Tunnel, }
        conn id: 1, flow_id: SW:1, sibling_flags 80000046, crypto map: CRMAP_L2L
        sa timing: remaining key lifetime (k/sec): (4491492/3494)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

 

     inbound ah sas:

 

     inbound pcp sas:

 

     outbound esp sas:
      spi: 0x4B4B88F6(1263241462)
        transform: esp-3des esp-sha384-hmac ,
        in use settings ={Tunnel, }
        conn id: 2, flow_id: SW:2, sibling_flags 80000046, crypto map: CRMAP_L2L
        sa timing: remaining key lifetime (k/sec): (4491492/3494)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

 

     outbound ah sas:

 

     outbound pcp sas:

Посмотреть состояние сессии:

R3#show crypto session
Crypto session current status

 

Interface: Loopback0
Session status: UP-ACTIVE
Peer: 10.250.250.1 port 500
  IKEv1 SA: local 10.250.250.3/500 remote 10.250.250.1/500 Active
  IPSEC FLOW: permit ip 172.16.3.0/255.255.255.0 172.16.1.0/255.255.255.0
        Active SAs: 2, origin: crypto map
 

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

 

6 комментариев “IOS LAN-TO-LAN IPsec, от теории к практике”

comment rss - Trackback

  1. P@ve1:

    Хорошая статью. Очень подробно описанный процесс установления соединений с выкладками дебага и разъяснениями — это оч полезно. Оч хоролший материал для понимания и подглядывания при траблшутинге.
    А вот заморочка с лупбэком — имхо лишнее: во первых новичков только столку собьет, во вторых, пакеты идущие через лупбек, на сколько я знаю — маршрутизируются не посредством CEF — разве можно это считать хорошей практикой?

  2. fantas1st0:

    В целом замечено верно, CEF не работает для логических интерфейсов.
    В статье есть примечание: что можно использовать crypto-map local address. Добавил, что второй вариант более предпочтителен.

  3. Да, новичка не просто собьет — убьет наповал 🙂

    Я бы в лабу добавил еще пару рутеров за криптующими, чтобы они выполняли роль хостов в ЛАН.

    Да, AES-192 настоятельно НЕ рекомендую — это насколько я знаю проприетарный цискин алгоритм (длина). Лучше тогда сразу 256, а то при настройке с другими вендорами можно удивиться 🙂

  4. fantas1st0:

    Серёж, насколько я знаю — AES 256 менее криптостоек, чем 128-ой 🙂

  5. djon:

    Я как раз тот самый новичек и меня действительно срубило наповал.
    Можно чуть-чуть поподробней в следующих местах:
    — «Как Вы могли заметить, то IPsec-туннель мы пытаемся построить между Loopback-интерфейсами» я не смог заметить где об этом говорится.
    — «По умолчанию для согласования выбирается агрессивный режим IKE, но поскольку мы отключили его» — а где мы его отключили?
    — Ну и поскольку я новичек, то про туннель, строящийся с помощью лупбек понимаю мало, можно ли поподробей про саму схему (что откуда и куда идет).
    — Если бы сделать комментарии к каждой команде из этого «финта ушами», то тоже был бы благодарен (куда рут-мапа применяется и что в ней последние две команды значат?):
    route-map MAP_L2L-LOOP permit 10
    match ip address ACL_L2L
    set interface Loopback0
    ip local policy route-map MAP_L2L-LOOP

    Ну и до кучи еще вопрос. Я заметил что на 1841 по show crypto isakmp sa не всегда показываются все установленные SA. Т.е. туннель есть, трафик по нему идет, по show crypto ipsec sa его увидеть можно как ACTIVE, а в crypto isakmp sa его не видно. Это баг или фича?

  6. djon:

    В качестве пруфлинка к этому утверждению :
    «насколько я знаю — AES 256 менее криптостоек, чем 128-ой»
    Вот что нашел, может кому полезно будет:
    http://habrahabr.ru/post/68328/

» Оставить комментарий

Вы должны войти чтобы прокомментировать.