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 | IKEv1 | IKEv2 |
|---|---|---|
| Exchange Modes | Main mode, Aggressive mode, Quick mode | SA_INIT, IKE_Auth, CREATE_CHILD_SA |
| Number of Messages | Nine with main mode, Six with aggressive mode | Four |
| Supported Authentication Methods | Pre-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 supported | Supported |
| Attack Protection | MitM protection, Eavesdropping protection | MitM protection, Eavesdropping protection, Anti-DoS protection |
Из вкусных плюшек IKEv2 — NGE (по ссылке есть табличка, какие алгоритмы являются Avoid, Legacy, Acceptable, NGE), защита от DoS, Authentication Methods могут быть различными с двух сторон. Итого: скорость установки соединения, усиленная защита.
CISCO IKEv2
Конечно же циска не осталась в стороне и разработала кучу всего на IKEv2:
| Features | IPsec VPN | DMVPN | GET VPN | FLEX VPN | Remote Access VPN |
|---|---|---|---|---|---|
| Vendor | Multi | CISCO | CISCO | CISCO | CISCO |
| IKE | v1, v2 | v1, v2 | v1, v2 | v2 | v2 |
| Scale | Low | Тысячи | Тысячи | Тысячи | Тысячи |
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.
Поэтому если мы не создадим 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 нет:
Посмотрим сессию 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.