CISCO IPsec часть 3

CISCO IPsec часть 3 — в третьей части рассматриваем создание туннеля на IKEv2, какие тут преимущества и зачем это надо.

Разговор как всегда только про Site2Site, Remote Access со всеми его особенностями не интересует меня в принципе.


Обмен сообщениями IKEv1 vs IKEv2

Изложил как понял сам, если в чём-то ошибся, поправки приветствуются.

В IKEv1 соединение устанавливается в две фазы. Первая фаза согласуется в Main mode (6 сообщений) или Aggressive Mode (3 сообщения). Вторая фаза Quick Mode (3 сообщения). Итого либо 9, либо 6 сообщений.

Затем IKEv1 был доработан до версии 2, начальные сведения содержатся в RFC4306 2005 год. И как принято, после этого стандарт неоднократно правили. Последний RFC7296 аж за 2014 год.

Что же здесь такого напридумывали? Поменяли всю терминологию (и правильно сделали, надеюсь будет понятно почему), теперь у нас не Phases, а Exchanges. Exchange подразумевает пару запрос/ответ (request/response pair).

  • Phase1 стала IKE_SA_INIT exchange и эквивалентна первым 4 сообщениям из Phase1 IKEv1, но всё это упаковано в одну пару запрос/ответ. Уже круто;
  • Phase2 стала IKE_AUTH exchange и эквивалентна оставшимся 2 сообщениям Phase1 IKEv1 плюс 2 сообщения Phase2. Опять это сгруппировано в одну пару запрос/ответ. В ходе IKE_AUTH устанавливается IKE SA.

Что в результате этих 2 exchanges? Поднят один двунаправленный туннель IKE SA, подобный туннелю первой фазы для IKEv1.

Затем поверх готового туннеля IKE SA, устанавливается Child SA для каждого роутера. Это и есть IPsec SA. Child SAs поднимаются с помощью двух CREATE_CHILD_SA exchanges, по 1 на роутер.

The CREATE_CHILD_SA exchange is used to create new Child SAs and to rekey both IKE SAs and Child SAs.
This exchange consists of a single request/response pair, and some of its function was referred to as 
a Phase 2 exchange in IKEv1.

Что в результате следующих 2 exchanges? Поднято два однонаправленных туннеля Child SAs. Итого: двунаправленный IKE SA плюс 2 однонаправленных Child SAs. В этой части всё осталось на своих местах.

Таким образом, всего нужно 4 пары запрос/ответ: IKE_SA_INIT, IKE_AUTH, CREATE_CHILD_SA в одну сторону, CREATE_CHILD_SA в другую сторону. Прогресс? Да, прогресс.


Сравнение характеристик IKEv1 vs IKEv2

Поскольку сообщения IKEv1 сильно отличаются от сообщений IKEv2, то IKEv1 и IKEv2 между собой несовместимы. Все улучшения IKEv2 в таблице:

Features IKEv1IKEv2
Exchange ModesMain mode,
Aggressive mode,
Quick mode
SA_INIT,
IKE_Auth,
CREATE_CHILD_SA
Number of MessagesNine with main mode,
Six with aggressive mode
Four
Supported Authentication MethodsPre-Shared Key (PSK),
Digital RSA Certificate (RSA-SIG),
Public key
Pre-Shared Key,
Digital RSA Certificate (RSA-SIG),
Elliptic Curve Digital Signature Certificate
(ECDSA-SIG),
Extensible Authentication Protocol (EAP)
Next Generation Encryption (NGE)Not supportedSupported
Attack ProtectionMitM protection,
Eavesdropping protection
MitM protection,
Eavesdropping protection,
Anti-DoS protection

Из вкусных плюшек IKEv2 — NGE (по ссылке есть табличка, какие алгоритмы являются Avoid, Legacy, Acceptable, NGE), защита от DoS, Authentication Methods могут быть различными с двух сторон. Итого: скорость установки соединения, усиленная защита.


CISCO IKEv2

Конечно же циска не осталась в стороне и разработала кучу всего на IKEv2:

FeaturesIPsec VPNDMVPNGET VPNFLEX VPNRemote Access VPN
VendorMultiCISCOCISCOCISCOCISCO
IKEv1, v2 v1, v2 v1, v2 v2v2
ScaleLowТысячиТысячиТысячиТысячи
IKEv2 is not supported on Integrated Service Routers (ISR) G1.

Не всё оборудование поддерживает IKEv2, тогда классика IKEv1 в помощь. Наоборот лимиты на IKEv2 для современного оборудования более чем, так например для ASR 1000 это 4000 сессий FlexVPN и более. Хотелось бы конечно узнать, сколько туннелей S2S может реально тащить роутер в продакшене без ущерба для производительности. К сожалению, такой инфы у меня нет.


Настройка

Теперь когда разобрались с терминологией, попробуем настроить IKEv2. В конфе будут следующие секции:

  • Proposal;
  • Policy;
  • Keyring;
  • IKEv2 Profile
Proposal

При настройке секции Proposal нам в явном виде говорят что нужно указать encryption, inetgrity и DH group.

R1(config)# crypto ikev2 proposal IKEv2PROPOSAL
IKEv2 proposal MUST have atleast an encryption algorithm, an integrity algorithm and a dh group configured

R1(config-ikev2-proposal)# encryption aes-cbc-128
R1(config-ikev2-proposal)# integrity sha1
R1(config-ikev2-proposal)# group 5

Тут нужно учесть, что:

Although the crypto ikev2 proposal command is similar to the crypto isakmp policy priority command, the IKEv2 proposal differs as follows: 
- An IKEv2 proposal allows configuration of one or more transforms for each transform type.
- An IKEv2 proposal does not have any associated priority.

Хотя похоже на IKEv1, логика здесь другая. И мы можем задавать сразу ряд параметров, а не один:

  • Encryption;
R1(config)# crypto ikev2 proposal IKEv2PROPOSAL
R1(config-ikev2-proposal)# encryption ?
  3des         3DES
  aes-cbc-128  AES-CBC-128
  aes-cbc-192  AES-CBC-192
  aes-cbc-256  AES-CBC-256
  des          DES
R1(config-ikev2-proposal)# encryption AES-CBC-128 AES-CBC-192 AES-CBC-256

AES-CBC — Advanced Encryption Standard-Cipher Block Chaining, CBC (шифр блок цепочки) один из режимов шифрования AES
  • Integrity;
R1(config-ikev2-proposal)# integrity 
  md5     Message Digest 5
  sha1    Secure Hash Standard
  sha256  Secure Hash Standard 2 (256 bit)
  sha384  Secure Hash Standard 2 (384 bit)
  sha512  Secure Hash Standard 2 (512 bit)
R1(config-ikev2-proposal)# integrity sha256 sha384 sha512    
  • DH Group;
R1(config-ikev2-proposal)# group ?
  1   DH 768 MODP
  14  DH 2048 MODP
  15  DH 3072 MODP
  16  DH 4096 MODP
  19  DH 256 ECP
  2   DH 1024 MODP
  20  DH 384 ECP
  21  DH 521 ECP
  24  DH 2048 (256 subgroup) MODP
  5   DH 1536 MODP
R1(config-ikev2-proposal)# group 14 20 24

Введённые ранее значения будут перезаписаны. В порядке ввода параметров (выделено жирным шрифтом) была специально допущена ошибка, подробнее далее.

Каких-то супер алгоритмов для IKEv2 для образа IOL не увидел, всё очень похоже на ISAKMP. Возможно на каком-то другом оборудовании.

Policy

Для Policy нам требуется секция Proposal, мы должны её предварительно создать, что и сделали. В Policy мы определяем дополнительные параметры если нужно и привязываем Proposal.

R1(config)# crypto ikev2 policy IKEv2POLICY
IKEv2 policy MUST have atleast one complete proposal attached 

R1(config-ikev2-policy)# match ? - дополнительные параметры
  address  Specify the address to match
  fvrf     Specify fvrf

R1(config-ikev2-policy)# match fvrf any - никакие дополнительные параметры не задаются
R1(config-ikev2-policy)# proposal IKEv2PROPOSAL
Smart Defaults

Для быстрого создания туннеля в конфигурации уже есть дефолтные преднастройки Smart Defaults.

CISCO IPsec часть 3

Поэтому если мы не создадим Policy и не привяжем Proposal, то ничего страшного, будет использоваться дефолтный Proposal и дефолтная Policy:

To use IKEv2 proposals in negotiation, they must 
be attached to IKEv2 policies. If a proposal is 
not configured, then the default IKEv2 proposal 
is used with the default IKEv2 policy.

Для начала поглядим какие вообще есть опции:

R1# show crypto ikev2 ?  
  authorization      Author policy
  certificate-cache  Show certificates in ikev2 certificate-cache
  client             Show Client Status
  cluster            Show Cluster load
  diagnose           Shows ikev2 diagnostic
  policy             Show policies
  profile            Shows ikev2 profiles
  proposal           Show proposals
  sa                 Shows ikev2 SAs
  session            Shows ikev2 active session
  stats              Shows ikev2 sa stats

Теперь смотрим Proposal:

R1# show crypto ikev2 proposal 
 IKEv2 proposal: default 
     Encryption : AES-CBC-256 AES-CBC-192 AES-CBC-128
     Integrity  : SHA512 SHA384 SHA256 SHA96 MD596
     PRF        : SHA512 SHA384 SHA256 SHA1 MD5
     DH Group   : DH_GROUP_1536_MODP/Group 5 DH_GROUP_1024_MODP/Group 2
 IKEv2 proposal: IKEv2PROPOSAL
     Encryption : AES-CBC-128 AES-CBC-192 AES-CBC-256
     Integrity  : SHA256 SHA384 SHA512
     PRF        : SHA256 SHA384 SHA512
     DH Group   : DH_GROUP_2048_MODP/Group 14 DH_GROUP_384_ECP/Group 20 DH_GROUP_2048_256_MODP/Group 24

Смотрим Policy:

R1# show crypto ikev2 policy 
 IKEv2 policy : default
      Match fvrf : any
      Match address local : any 
      Proposal    : default 
 IKEv2 policy : IKEv2POLICY
      Match fvrf : any
      Match address local : any 
      Proposal    : IKEv2PROPOSAL

И что мы тут видим?

  • Важен порядок ввода параметров. В настроенном Proposal порядок задом наперёд по отношению к дефолтному. Ошибка, про которую говорил: сначала были введены менее криптостойкие параметры, затем более. А нужно наоборот;
  • Созданные нами Proposal и Policy мало отличаются от дефолтных. Политика по сути не отличается ничем.
Keyring

Следующее Keyring, тут мы задаём параметры пира и ключи. Аналогично соотвествующей строчке в IKEv1, только тут не строчка, а вот такой иерахический наборчик:

R1(config)# crypto ikev2 keyring ?
  WORD  Name of IKEv2 Keyring

R1(config)# crypto ikev2 keyring KR
R1(config-ikev2-keyring)# peer R2
R1(config-ikev2-keyring-peer)# address 10.10.10.2
R1(config-ikev2-keyring-peer)# pre-shared-key local cisco123
R1(config-ikev2-keyring-peer)# pre-shared-key remote cisco123
IKEv2 Profile

Наконец IKEv2 Profile (не путать с профилем IPsec), здесь методы аутентификации (локальной и удалённой, так как они могут быть разными), match identity (у нас это айпишник).

R1(config)# crypto ikev2 profile IKEv2PROFILE
IKEv2 profile MUST have:
   1. A local and a remote authentication method.
   2. A match identity or a match certificate or match any statement.

R1(config-ikev2-profile)# match identity remote address 10.10.10.2 255.255.255.255    
R1(config-ikev2-profile)# authentication remote pre-share
R1(config-ikev2-profile)# authentication local pre-share
R1(config-ikev2-profile)# keyring local KR
Туннельный интерфейс

Доступна настройка с Crypto Map (без туннельного интерфейса), такую настройку можно посмотреть тут. Настраиваем Crypto Profile (с туннельным интерфейсом).

R1(config)# crypto ipsec transform-set TS esp-aes 256 esp-sha384-hmac

R1(config)# crypto ipsec profile IPSEC
R1(ipsec-profile)# set ikev2-profile IKEv2PROFILE
R1(ipsec-profile)# set transform-set TS

R1(config)# interface Tunnel1
R1(config-if)# bandwidth 4000
R1(config-if)# ip address 172.16.1.2 255.255.255.252
R1(config-if)# ip mtu 1400
R1(config-if)# tunnel source 10.10.10.1
R1(config-if)# tunnel destination 10.10.10.2
R1(config-if)# tunnel protection ipsec profile IPSEC
*Aug 11 11:49:03.123: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON

Обращаю внимание на сообщение ISAKMP, оно не совсем верное, у нас же тут IKEv2. Проверим далее.

Маршрутизация

Настраиваем маршрутизацию в туннель и интерфейс Loopback 0, который будет эмулировать локальную подсеть.

R1(config)# interface lo0
*Aug 11 11:55:02.114: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to up
R1(config-if)# ip address 192.168.1.1 255.255.255.0

R1(config)# router ospf 1
R1(config-router)# network 192.168.1.0 0.0.0.255 area 0
R1(config-router)# network 172.16.2.1.0 0.0.0.3 area 0 
*Aug 11 12:24:47.856: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on Tunnel1 from LOADING to FULL, Loading Done

Поскольку OSPF установил отношения смежности, то сразу можно сделать вывод о заработавшем туннеле.

R2# show ip route ospf
...
      192.168.1.0/32 is subnetted, 1 subnets
O        192.168.1.1 [110/26] via 172.16.1.1, 00:17:24, Tunnel1

Проверка IKEv2

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

R2# show crypto ikev2 sa
 IPv4 Crypto IKEv2  SA 

Tunnel-id Local                 Remote                fvrf/ivrf            Status 
2         10.10.10.2/500        10.10.10.1/500        none/none            READY  
      Encr: AES-CBC, keysize: 128, Hash: SHA256, DH Grp:14, Auth sign: PSK, Auth verify: PSK
      Life/Active Time: 86400/199 sec

 IPv6 Crypto IKEv2  SA 

Из-за неправильного порядка параметров согласовались самые слабые алгоритмы. Удалим созданные нами Policy/Proposal и передёрнем интерфейс туннеля:

R1(config)# no crypto ikev2 policy IKEv2POLICY
R1(config)# no crypto ikev2 proposal IKEv2PROPOSAL

R2(config)# no crypto ikev2 policy IKEv2POLICY
R2(config)# no crypto ikev2 proposal IKEv2PROPOSAL

Смотрим сессию:

R2# show crypto ikev2 sa
 IPv4 Crypto IKEv2  SA 

Tunnel-id Local                 Remote                fvrf/ivrf            Status 
1         10.10.10.2/500        10.10.10.1/500        none/none            READY  
      Encr: AES-CBC, keysize: 256, Hash: SHA512, DH Grp:5, Auth sign: PSK, Auth verify: PSK
      Life/Active Time: 86400/22 sec

 IPv6 Crypto IKEv2  SA 

Согласовались самые стойкие алгоритмы из дефолтного Proposal. Дефолтного Keyring нет, понятно почему, дефолтного IKEv2 Profile тоже нету, дефолтный IPsec Profile ничего интересного. И дефолтный Transform Set проверим далее.

Wireshark

Теперь смотрим в Wireshark. Ожидаемо ничего нового, никаких данных именно о IKEv2 нет:

CISCO IPsec часть 3

Посмотрим сессию IKE:

R2# show crypto session 
...
Interface: Tunnel1
Profile: IKEv2PROFILE
Session status: UP-ACTIVE     
Peer: 10.10.10.1 port 500 
  Session ID: 4  
  IKEv2 SA: local 10.10.10.2/500 remote 10.10.10.1/500 Active 
  IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0 
        Active SAs: 2, origin: crypto map

А можно ещё вот так:

R2# show crypto ikev2 session 
IPsec SA

Наконец, посмотрим IPsec SA:

R1# show crypto ipsec sa
...
     plaintext mtu 1422, path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0
     current outbound spi: 0xBAC229E5(3133286885)
     PFS (Y/N): N, DH group: none

     inbound esp sas:
      spi: 0x1CF2A80F(485664783)
        transform: esp-256-aes esp-sha384-hmac ,
        in use settings ={Tunnel, }
...

Наш трансформ сет, всё верно. Теперь уберём трансформ сет из конфигурации:

R1(config)# crypto ipsec profile IPSEC
R1(ipsec-profile)# no set transform-set TS - отвязали трансформ сет от IKEv2 профиля
R1(ipsec-profile)# no crypto ipsec transform-set TS - пытаемся удалить

Transform-set TS is in use by the crypto-map(s) / ipsec-profile(s):  Tunnel1-head-0
First remove the transform-set from the above crypto map(s)/profile(s).

R1(ipsec-profile)# interface Tunnel1
R1(config-if)# no tunnel protection ipsec profile IPSEC
R1(config-if)# no crypto ipsec transform-set TS
R1(config)# interface Tunnel1
R1(config-if)# tunnel protection ipsec profile IPSEC
- на R2 аналогично

Снова смотрим IPsec SA:

R2# show crypto ipsec sa
...
     plaintext mtu 1438, path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0
     current outbound spi: 0xC52EDAD6(3308182230)
     PFS (Y/N): N, DH group: none

     inbound esp sas:
      spi: 0x54042619(1409558041)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
...

Смотрим дефолтный сет:

R1# show crypto ipsec transform-set 
Transform set default: { esp-aes esp-sha-hmac  } 
   will negotiate = { Transport,  }, 

Здесь непонятная ситуация. В конфе единственный дефолтный сет в режиме Transport, в таблице Smart Defaults дефолтный сет в режиме Tunnel. У нас используется естественно в режиме Tunnel. Очень похоже, как будто есть ещё дефолтный сет неуказанный в выводе. Если неправ, поправьте.

Значение plaintext MTU это размер пакета без накладных расходов IPsec. Кстати, если заглянуть в первую часть статьи, то там есть точно такой же кусок вывода "plaintext mtu 1438..". Вывод этот тоже для дефолтного сета.

Как видно, размер накладных расходов IPsec зависит от криптостойкости алгоритмов. Чем сильнее алгоритмы, тем меньше места для полезной нагрузки: 1422 против 1438. Проверим это далее.

Debug

Запустим дебаг ISAKMP (debug crypto isakmp), погасим и включим интерфейс туннеля. В дебаге пусто, всё верно, ISAKMP SA нету:

R1# show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status

IPv6 Crypto ISAKMP SA

Теперь дебаг IKEv2 (debug crypto ikev2) и ещё раз дёрнем туннель, посыпалось. Ищу знакомые буквы:

*Aug 11 13:17:02.501: IKEv2:Received Packet [From 10.10.10.1:500/To 10.10.10.2:500/VRF i0:f0] 
Initiator SPI : ACC6516BD324F827 - Responder SPI : 0000000000000000 Message id: 0
IKEv2 IKE_SA_INIT Exchange REQUEST 
...
*Aug 11 13:17:02.516: IKEv2:(SESSION ID = 7,SA ID = 2):Received Packet [From 10.10.10.1:500/To 10.10.10.2:500/VRF i0:f0] 
Initiator SPI : ACC6516BD324F827 - Responder SPI : 7470206135BE0757 Message id: 1
IKEv2 IKE_AUTH Exchange REQUEST 

Вывод как всегда огромен, привёл оттуда пару сообщений.

MTU

Проверим MTU через туннель. Убираю настройку ip mtu 1400 и запускаю пинг:

R1# ping 
Protocol [ip]: 
Target IP address: 172.16.1.2 - IP туннеля с другой стороны
Repeat count [5]: 
Datagram size [100]: 1438
Timeout in seconds [2]: 
Extended commands [n]: y
Source address or interface: Tunnel 1
Type of service [0]: 
Set DF bit in IP header? [no]: y
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, 1400-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds:
Packet sent with a source address of 172.16.1.1 
Packet sent with the DF bit set
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 6/7/8 ms

Действительно, максимальный размер датаграммы с битом DF когда пинг проходит равен 1438 байтам. А вот 1439 уже нет. Значение plaintext mtu не врёт.

Почему тогда 1400, если по факту пролазит и больше? Потому что 1400 универсальное значение для туннеля, гарантирующее отсутствие фрагментации.

Можно подкрутить его? Можно, но осторожно. Если пробовать крутить его в сторону увеличения, то неплохо было бы с помощью Iperf замерить как это будет влиять на скорость передачи пакетов через туннель. Подробнее про IKEv2.

Leave a Comment

Scroll to Top