+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Редкие несоответствия ключей SA между strongSwan и RouterOS

Редкие несоответствия ключей SA между strongSwan и RouterOS, RouterOS

dorian

Guest

21.08.2018 15:33:00

Привет! Мы настроили site-to-site VPN, соединяющий наш главный офис (running strongSwan 5.5.1 на Debian Stretch) с филиалом (используется RB2011iL с RouterOS 6.40.8). Это туннель IKEv2 с PSK и стандартным временем жизни ключа — 1 час. В целом всё работает отлично, но иногда (примерно раз в неделю) при обновлении ключа что-то идёт не так: после рекея две стороны уже не совпадают по тому, какие ключи использовать.

После такого рекея SAs на стороне strongSwan выглядят так:
src <STRONGSWAN_IP> dst <MIKROTIK_IP>
proto esp spi 0x09890c39 reqid 2 mode tunnel
replay-window 0 flag af-unspec
auth-trunc hmac(sha256) 0x511...fc4da 128
enc cbc(aes) 0x74a1...9c8c
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000

src <MIKROTIK_IP> dst <STRONGSWAN_IP>
proto esp spi 0xcff9f231 reqid 2 mode tunnel
replay-window 32 flag af-unspec
auth-trunc hmac(sha256) 0x162e...3c5f9 128
enc cbc(aes) 0x06ef...2a5
anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000

В то время как на стороне MikroTik используются следующие SAs:
1 E spi=0x9890C39 src-address=<STRONGSWAN_IP> dst-address=<MIKROTIK_IP> state=mature
auth-algorithm=sha256 enc-algorithm=aes-cbc enc-key-size=128
auth-key="3d5138d833aa55ceaee9801707c48a4dfb80e29fdc899cba6e39b188a03bc83b"
enc-key="c30de4b999ba413af5da8d2d8e024001" add-lifetime=48m2s/1h3s replay=128

2 E spi=0xCFF9F231 src-address=<MIKROTIK_IP> dst-address=<STRONGSWAN_IP> state=mature
auth-algorithm=sha256 enc-algorithm=aes-cbc enc-key-size=128
auth-key="e9d1eefcb8250c7b5795c381e7c9eb7b44e67064fb1a90334335d372f5efadb3"
enc-key="a856120a0824bb2fc60aa565482d303e" addtime=aug/21/2018 10:18:10 expires-in=51m18s
add-lifetime=48m2s/1h3s current-bytes=35703 current-packets=144 replay=128

Из этого вывода видно, что обе стороны используют разные ключи аутентификации и шифрования для одного и того же SPI. В результате любые ESP-пакеты данного соединения просто сбрасываются с обеих сторон. Перезапуск соединения сразу всё исправляет до следующего раза, когда после рекея возникает рассинхронизация ключей.

Логи рекея на стороне strongSwan не вызывают у меня особого подозрения:
2018-08-21T10:18:09.616057+02:00 09[IKE] <conn_name|1> queueing CHILD_REKEY task
2018-08-21T10:18:09.616674+02:00 09[IKE] <conn_name|1> activating new tasks
2018-08-21T10:18:09.617223+02:00 09[IKE] <conn_name|1> activating CHILD_REKEY task
2018-08-21T10:18:09.617782+02:00 09[IKE] <conn_name|1> establishing CHILD_SA conn_name{2}
2018-08-21T10:18:09.618394+02:00 09[CFG] <conn_name|1> proposing traffic selectors for us:
2018-08-21T10:18:09.618955+02:00 09[CFG] <conn_name|1> 10.11.0.0/16
2018-08-21T10:18:09.619505+02:00 09[CFG] <conn_name|1> 10.10.0.0/16
2018-08-21T10:18:09.620064+02:00 09[CFG] <conn_name|1> proposing traffic selectors for other:
2018-08-21T10:18:09.620697+02:00 09[CFG] <conn_name|1> 10.50.0.0/16
2018-08-21T10:18:09.621381+02:00 09[CFG] <conn_name|1> configured proposals: ESP:AES_CBC_128/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ
2018-08-21T10:18:09.636466+02:00 09[ENC] <conn_name|1> generating CREATE_CHILD_SA request 30 [ N(REKEY_SA) SA No KE TSi TSr ]
2018-08-21T10:18:09.637105+02:00 09[NET] <conn_name|1> sending packet: from <STRONGSWAN_IP>[4500] to <MIKROTIK_IP>[4500] (496 bytes)
2018-08-21T10:18:10.571371+02:00 12[NET] <conn_name|1> received packet: from <MIKROTIK_IP>[4500] to <STRONGSWAN_IP>[4500] (480 bytes)
2018-08-21T10:18:10.572847+02:00 12[ENC] <conn_name|1> parsed CREATE_CHILD_SA response 30 [ No KE TSi TSr SA ]
2018-08-21T10:18:10.590638+02:00 12[CFG] <conn_name|1> selecting proposal:
2018-08-21T10:18:10.591675+02:00 12[CFG] <conn_name|1> proposal matches
2018-08-21T10:18:10.592406+02:00 12[CFG] <conn_name|1> received proposals: ESP:AES_CBC_128/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ
2018-08-21T10:18:10.593170+02:00 12[CFG] <conn_name|1> configured proposals: ESP:AES_CBC_128/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ
2018-08-21T10:18:10.593884+02:00 12[CFG] <conn_name|1> selected proposal: ESP:AES_CBC_128/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ
2018-08-21T10:18:10.594612+02:00 12[CFG] <conn_name|1> selecting traffic selectors for us:
2018-08-21T10:18:10.595126+02:00 12[CFG] <conn_name|1> config: 10.11.0.0/16, received: 10.10.0.0/16 => no match
2018-08-21T10:18:10.595605+02:00 12[CFG] <conn_name|1> config: 10.10.0.0/16, received: 10.10.0.0/16 => match: 10.10.0.0/16
2018-08-21T10:18:10.596273+02:00 12[CFG] <conn_name|1> selecting traffic selectors for other:
2018-08-21T10:18:10.596780+02:00 12[CFG] <conn_name|1> config: 10.50.0.0/16, received: 10.50.0.0/16 => match: 10.50.0.0/16
2018-08-21T10:18:10.597258+02:00 12[CHD] <conn_name|1> using AES_CBC for encryption
2018-08-21T10:18:10.597731+02:00 12[CHD] <conn_name|1> using HMAC_SHA2_256_128 for integrity
2018-08-21T10:18:10.598220+02:00 12[CHD] <conn_name|1> adding inbound ESP SA
2018-08-21T10:18:10.598695+02:00 12[CHD] <conn_name|1> SPI 0xcff9f231, src <MIKROTIK_IP> dst <STRONGSWAN_IP>
2018-08-21T10:18:10.599168+02:00 12[CHD] <conn_name|1> adding outbound ESP SA
2018-08-21T10:18:10.599642+02:00 12[CHD] <conn_name|1> SPI 0x09890c39, src <STRONGSWAN_IP> dst <MIKROTIK_IP>
2018-08-21T10:18:10.600129+02:00 12[IKE] <conn_name|1> CHILD_SA conn_name{26} established with SPIs cff9f231_i 09890c39_o and TS 10.10.0.0/16 === 10.50.0.0/16
2018-08-21T10:18:10.600670+02:00 12[IKE] <conn_name|1> reinitiating already active tasks
2018-08-21T10:18:10.601294+02:00 12[IKE] <conn_name|1> CHILD_REKEY task
2018-08-21T10:18:10.601800+02:00 12[IKE] <conn_name|1> closing CHILD_SA conn_name{21} with SPIs cca08482_i (29988 bytes) 0f456b61_o (47112 bytes) and TS 10.10.0.0/16 === 10.50.0.0/16
2018-08-21T10:18:10.602274+02:00 12[IKE] <conn_name|1> sending DELETE for ESP CHILD_SA with SPI cca08482
2018-08-21T10:18:10.602744+02:00 12[ENC] <conn_name|1> generating INFORMATIONAL request 31 [ D ]
2018-08-21T10:18:10.603211+02:00 12[NET] <conn_name|1> sending packet: from <STRONGSWAN_IP>[4500] to <MIKROTIK_IP>[4500] (80 bytes)
2018-08-21T10:18:10.605572+02:00 08[NET] <conn_name|1> received packet: from <MIKROTIK_IP>[4500] to <STRONGSWAN_IP>[4500] (96 bytes)
2018-08-21T10:18:10.606048+02:00 08[ENC] <conn_name|1> parsed INFORMATIONAL response 31 [ ]
2018-08-21T10:18:10.606520+02:00 08[IKE] <conn_name|1> CHILD_SA closed
2018-08-21T10:18:10.607076+02:00 08[IKE] <conn_name|1> activating new tasks
2018-08-21T10:18:10.607624+02:00 08[IKE] <conn_name|1> ничего инициировать не нужно

К сожалению, логов с RouterOS у меня сейчас нет. У кого-нибудь уже была похожая ситуация? Как я сказал, эту проблему сложно отследить, поскольку она появляется редко, и я не смог найти способ её воспроизвести. Любые советы будут очень полезны.

sindy

Guest

11.09.2018 20:14:00

Из темы бета-версии 6.44: Что нового в 6.44beta6 (2018-Сен-11 08:52): … *) ike2 — исправлены редкие ошибки несоответствия ключей аутентификации и шифрования после обновления ключа с включённым PFS; Если у вас есть возможность выделить устройство для тестирования 6.44beta6 с strongswan, было бы супер. Я планирую сделать это на паре Mikrotik через несколько дней — сейчас они заняты тестированием другого. Чем раньше исправление докажет свою стабильность, тем скорее его можно будет внедрить в 6.43.x.

sergeyk

Guest

28.11.2018 11:30:00

Похоже, эта проблема так и не исправлена. Я протестировал 6.43.4 и 6.44beta28 с IKEv2 в режиме транспортных предложений: add auth-algorithms=sha256 enc-algorithms=aes-256-cbc lifetime=1h pfs-group=modp4096 профиль: dh-group=modp4096 dpd-interval=10s dpd-maximum-failures=3 enc-algorithm=aes-256 hash-algorithm=sha256 lifetime=2h, подключён к strongswan 5.7.1 на centos7. Всё работает нормально какое-то время, ключи обновляются каждый час, но спустя 2-3 дня ситуация повторяется, как в первом посте: у обеих сторон правильные номера SPI, но ключи аутентификации и шифрования полностью разные, из-за чего весь зашифрованный трафик сбрасывается обеими пирами. В этот момент обе стороны посылают друг другу DPD, так как не видят активности по этой ссылке, но DPD не использует ESP и эти ключи, поэтому для обеих сторон канал выглядит живым и не пересоздаётся аутентификация. Через час при следующем обновлении ключи снова синхронизируются, и трафик течёт. Сегодня поставил 6.44beta39, буду смотреть, как пойдёт, но в списке изменений ничего про обновление ключей не вижу, скорее всего будет точно так же, и это очень раздражает. И, конечно, всё начинает работать, если принудительно вызвать повторную аутентификацию. Есть идеи, в чём может быть причина? Или лучше заявить об этой ошибке в другой трекер?

sindy

Guest

28.11.2018 19:00:00

Пожалуйста, отправьте это как баг-репорт на support@mikrotik.com, этот форум — не подходящее место. Лично я с таким багом не сталкивался начиная с версии 6.43.2, но все мои IKEv2-сессии идут либо между двумя Mikrotik’ами, либо между Mikrotik и Windows-машиной, где PFS не поддерживается со стороны Windows. Так что теоретически возможно, что с strongswan это ведёт себя иначе.

sergeyk Guest	#5 0 08.04.2020 08:49:00 Прошло полтора года, а проблема всё ещё не решена)

sindy

Guest

08.04.2020 09:15:00

Ты уже открывал заявку в службу поддержки support@mikrotik.com, как я советовал полтора года назад? В твоей конфигурации проблема возникает между двумя Mikrotik или между Mikrotik с одной стороны и каким-то другим IKEv2-решением с другой? За всё это время я не встречал ни одного случая такой проблемы на примерно 20 IKEv2-связях (хотя это не значит, что их нет, но при сбое на 30 минут на большинстве связей сразу бы сработал сигнал тревоги), многие из них с несколькими параллельными SA. Так что, возможно, это связано с твоей аппаратной платформой или с взаимодействием с другим IKEv2-решением… Разработчикам Mikrotik нужны все эти детали, чтобы они могли воспроизвести проблему в лаборатории и исправить её.

sergeyk Guest	#7 0 08.04.2020 09:36:00 Конечно, я открыл тикет полтора года назад) Это проблема взаимодействия между mikrotik и strongswan при использовании PFS. Отключение PFS — плохое решение. Если правильно помню, когда я разбирался с этой проблемой, я также пробовал другую реализацию.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры