Mikrotik.moscow [тема: IKEv2 между MikroTik, переключение сторон, инициатор <> ответчик]

IKEv2 между MikroTik, переключение сторон, инициатор <> ответчик

Tue, 18 Aug 2020 17:44:00 -0400

IKEv2 между MikroTik, переключение сторон, инициатор <> ответчик RouterOS в форуме RouterOS.
На часах теперь снова инициатор (1 день). Таким образом, у него есть шанс переключаться каждые 24 часа, что соответствует установленному времени жизни в профиле ipsec, фаза 1? Я настроил скрипт для проверки переключений сторон, и если произойдет какое-либо переключение, он уведомит меня через Telegram. Вот так я это и закрыл. (Этот скрипт Telegram будет полезен и в будущем, для других целей, рад, что настроил его, и тот, что следит за изменениями значений ^^). Теперь обе стороны имеют время жизни фазы 1, установленное на 24 часа, и судя по логам, какая бы сторона первой ни инициировала повторный ключ, становится инициатором. Поправь меня, если я не прав. Лог для переключения обратно на инициатора, также захваченный с клиента: 20:21:44 ipsec IKE SA время жизни истекло, повторный ключ 20:21:44 ipsec добавление полезной нагрузки: SA 20:21:44 ipsec,debug => (размер 0x38) [...] 20:21:44 ipsec добавление полезной нагрузки: KE 20:21:44 ipsec,debug => (первый 0x100 из 0x108) [...] 20:21:44 ipsec добавление полезной нагрузки: NONCE 20:21:44 ipsec,debug => (размер 0x1c) 20:21:44 ipsec,debug 0000001c 9b5df9e7 04f0b6a4 c5f7d44d 5d21fc5c b4de8314 ff3e563e 20:21:44 ipsec <- ike2 запрос, обмен: CREATE_CHILD_SA:604 SERVER.IP[4500] 14701140c6f2c116:606ed9b3fc7a9c76 20:21:44 ipsec,debug ===== отправка 556 байт от CLIENT.IP[4500] к SERVER.IP[4500] 20:21:44 ipsec,debug 1 раз будет отправлено сообщение размером 560 байт к SERVER.IP[4500] 20:21:44 ipsec,debug ===== получено 540 байт от SERVER.IP[4500] к CLIENT.IP[4500] 20:21:44 ipsec -> ike2 ответ, обмен: CREATE_CHILD_SA:604 SERVER.IP[4500] 14701140c6f2c116:606ed9b3fc7a9c76 20:21:44 ipsec полезная нагрузка: ENC (512 байт) 20:21:44 ipsec обработка полезной нагрузки: ENC 20:21:44 ipsec,debug => iv (размер 0x10) 20:21:44 ipsec,debug 41096c51 414381d8 fc2cbfb2 7d1185fb 20:21:44 ipsec,debug => обычная полезная нагрузка (усеченная) (первый 0x100 из 0x15c) [...] 20:21:44 ipsec,debug расшифровано 20:21:44 ipsec полезная нагрузка: SA (56 байт) 20:21:44 ipsec полезная нагрузка: KE (264 байта) 20:21:44 ipsec полезная нагрузка: NONCE (28 байт) 20:21:44 ipsec повторный ключ: завершено 20:21:44 ipsec обработка полезных нагрузок: NOTIFY (не найдено) 20:21:44 ipsec обработка полезной нагрузки: NONCE 20:21:44 ipsec обработка полезной нагрузки: SA 20:21:44 ipsec IKE Протокол: IKE 20:21:44 ipsec предложение #1 20:21:44 ipsec шифрование: aes256-cbc 20:21:44 ipsec prf: hmac-sha1 20:21:44 ipsec аутентификация: sha1 20:21:44 ipsec dh: modp2048 20:21:44 ipsec совпавшее предложение: 20:21:44 ipsec предложение #1 20:21:44 ipsec шифрование: aes256-cbc 20:21:44 ipsec prf: hmac-sha1 20:21:44 ipsec аутентификация: sha1 20:21:44 ipsec dh: modp2048 20:21:44 ipsec обработка полезной нагрузки: KE 20:21:45 ipsec,debug => общий секрет (размер 0x100) [...] 20:21:45 ipsec добавление полезной нагрузки: DELETE 20:21:45 ipsec,debug => (размер 0x8) 20:21:45 ipsec,debug 00000008 01000000 20:21:45 ipsec <- ike2 запрос, обмен: INFORMATIONAL:605 SERVER.IP[4500] 14701140c6f2c116:606ed9b3fc7a9c76 20:21:45 ipsec,debug ===== отправка 236 байт от CLIENT.IP[4500] к SERVER.IP[4500] 20:21:45 ipsec,debug 1 раз будет отправлено сообщение размером 240 байт к SERVER.IP[4500] 20:21:45 ipsec,debug => skeyseed (размер 0x14) 20:21:45 ipsec,debug 001d6686 3f0cbf85 9f63d9e6 ebf1af80 cda557c4 20:21:45 ipsec,debug => keymat (размер 0x14) 20:21:45 ipsec,debug 95989951 4758a7ba e3b8fe59 1f914d65 24c127f2 20:21:45 ipsec,debug => SK_ai (размер 0x14) 20:21:45 ipsec,debug 261422d2 9f8ec4a2 00abe6bd db0444c5 4a4b2379 20:21:45 ipsec,debug => SK_ar (размер 0x14) 20:21:45 ipsec,debug 2e30e9fb e232e416 0706e58b 0bddde5a 42485794 20:21:45 ipsec,debug => SK_ei (размер 0x20) 20:21:45 ipsec,debug f1cc2394 a3761bcf b3238d53 aa5b6fd8 8f2f3c81 0a467038 3bd12356 6564cb0d 20:21:45 ipsec,debug => SK_er (размер 0x20) 20:21:45 ipsec,debug ff019301 739cd5bb 655de74e b70ad81b f86bab60 7b047600 6d2d79a9 09b0ae93 20:21:45 ipsec,debug => SK_pi (размер 0x14) 20:21:45 ipsec,debug 8b177554 7fccdbc3 7b5978e3 605f17ae f2c6342e 20:21:45 ipsec,debug => SK_pr (размер 0x14) 20:21:45 ipsec,debug 76144050 4a4180de 3ff275d4 2691af62 9029689e 20:21:45 ipsec,debug ===== получено 156 байт от SERVER.IP[4500] к CLIENT.IP[4500] 20:21:45 ipsec -> ike2 ответ, обмен: INFORMATIONAL:605 SERVER.IP[4500] 14701140c6f2c116:606ed9b3fc7a9c76 20:21:45 ipsec полезная нагрузка: ENC (128 байт) 20:21:45 ipsec обработка полезной нагрузки: ENC 20:21:45 ipsec,debug => iv (размер 0x10) 20:21:45 ipsec,debug 957bcbf1 bb57d0d5 c3426ab7 0151d314 20:21:45 ipsec,debug => обычная полезная нагрузка (усеченная) (размер 0x0) 20:21:45 ipsec,debug расшифровано 20:21:45 ipsec ответ: информация 20:21:45 ipsec получил ответ 20:21:45 ipsec повторный ключ завершен 20:21:50 script,info ike2peer: MONITORED.PEER.NAME переключилась на сторону: инициатор
18.08.2020 17:44:00, Znevna.

IKEv2 между MikroTik, переключение сторон, инициатор <> ответчик

Mon, 17 Aug 2020 21:19:00 -0400

IKEv2 между MikroTik, переключение сторон, инициатор <> ответчик RouterOS в форуме RouterOS.
Наверное, я тоже стал жертвой этого… Спасибо за подсказку и объяснение, Синди!
17.08.2020 21:19:00, eworm.

IKEv2 между MikroTik, переключение сторон, инициатор <> ответчик

Sun, 22 May 2022 18:35:00 -0400

IKEv2 между MikroTik, переключение сторон, инициатор <> ответчик RouterOS в форуме RouterOS.
Я перестал разбираться с этим, не помню, была ли у тех пиров установлена mode-config или нет, но я уверен, что была. Однако туннель не падает во время переключения на другую сторону, так что он не создается заново (не цитируйте меня на этом, просто предположение), и на mode-conf это не влияет, я все равно не заметил никаких проблем. Проверю в ближайшие дни.
22.05.2022 18:35:00, Znevna.

IKEv2 между MikroTik, переключение сторон, инициатор <> ответчик

Sun, 22 May 2022 16:47:00 -0400

IKEv2 между MikroTik, переключение сторон, инициатор <> ответчик RouterOS в форуме RouterOS.
Я недавно это обнаружил, когда искал, как заменить IKE на IKE2, и думал, что делаю что-то неправильно. Это не влияет на текущее использование, но что будет, если вы используете mode-config? И, похоже, есть еще одна ошибка в документации - для peer exchange-mode сказано: “Параметры, которые игнорируются IKEv2: proposal-check, compatibility-options, lifebytes, dpd-maximum-failures, nat-traversal.” При этом соединение можно успешно установить с профилем, у которого nat-traversal=нет, с клиента за NAT, но последующая повторная настройка phase2 ломается.
22.05.2022 16:47:00, tdw.

IKEv2 между MikroTik, переключение сторон, инициатор <> ответчик

Wed, 19 Aug 2020 21:14:00 -0400

IKEv2 между MikroTik, переключение сторон, инициатор <> ответчик RouterOS в форуме RouterOS.
Я отключил DPD на стороне клиента (использую провайдера VPN), и это сработало, сторона теперь остается инициатором. Я заметил обновление соединения, и столбец состояния в активных пирах показал что-то вроде: сообщение 1 обновлено, и это продолжалось примерно 15 секунд, после чего статус стал "установлено". Обновление: Не так уж и хорошо! Все выглядело прекрасно, я даже мог опубликовать это сообщение, однако трафик по IKEv2 туннелям не проходил, так что я снова включу DPD.
19.08.2020 21:14:00, msatter.

IKEv2 между MikroTik, переключение сторон, инициатор <> ответчик

Wed, 19 Aug 2020 20:02:00 -0400

IKEv2 между MikroTik, переключение сторон, инициатор <> ответчик RouterOS в форуме RouterOS.
Хм, пропустил это, но учитывая, что это представлено как предупреждение, я скорее предполагаю, что когда DPD отключен, фаза 1 не восстанавливается автоматически после истечения своего времени, и вам нужно будет запускать её вручную.
19.08.2020 20:02:00, sindy.

IKEv2 между MikroTik, переключение сторон, инициатор <> ответчик

Wed, 19 Aug 2020 19:53:00 -0400

IKEv2 между MikroTik, переключение сторон, инициатор <> ответчик RouterOS в форуме RouterOS.
В инструкции есть предупреждение: «Предупреждение: Фаза 1 не будет перерегистрирована, если DPD отключен при истечении срока жизни, только фаза 2 будет перерегистрирована. Чтобы принудительно перерегистрировать фазу 1, включите DPD». Этот переключатель происходит только когда обе стороны — Tiks. Или, по крайней мере, я пока что это заметил. Поэтому я думал, что установка DPD в положение «отключено» на сервере/ответчике предотвратит запрос перерегистрации и, тем самым, инициирование. Это не настоящая проблема... пока. Как я сказал в первом сообщении.
19.08.2020 19:53:00, Znevna.

IKEv2 между MikroTik, переключение сторон, инициатор <> ответчик

Wed, 19 Aug 2020 19:39:00 -0400

IKEv2 между MikroTik, переключение сторон, инициатор <> ответчик RouterOS в форуме RouterOS.
Что ж... Я никогда не слышал, что DPD (Dead Peer Detection) отвечает за перегенерацию Phase 1 — он завершает текущую сессию Phase 1, если удаленный пир перестает отвечать, и начинает новую, если локальный пир имеет активированное инициаторное поведение. Но после истечения срока действия Phase 1 он восстанавливается даже если DPD говорит, что все в порядке, но я не думаю, что у вас есть возможность повлиять на то, какой пир начнет процесс, то есть если удаленное устройство, не являющееся Mikrotik, инициирует новую Phase 1, устройство Mikrotik будет действовать как ответчик. В это время UDP-отверстие в фаерволе (отслеживаемое соединение) активно, созданное и поддерживаемое предыдущей сессией, так что переговоры пройдут успешно даже если Mikrotik находится за NAT. Что такого плохого в том, что Tik работает в качестве ответчика?
19.08.2020 19:39:00, sindy.

IKEv2 между MikroTik, переключение сторон, инициатор <> ответчик

Wed, 19 Aug 2020 17:42:00 -0400

IKEv2 между MikroTik, переключение сторон, инициатор <> ответчик RouterOS в форуме RouterOS.
На часах снова время. Теперь, когда я установил, что переобновление ключей phase1 является виновником (я прав?), если я отключу DPD на стороне сервера (согласно документации, DPD и заставляет переобновлять phase 1), как это повлияет на других подключенных клиентов? Клиенты Windows обращают внимание на DPD, установленный на сервере? У меня мало знаний об этом. Здесь есть кто-то из MikroTik? Я бы подал отчет об ошибке, но не очень хочу переходить с версии 6.46 на 6.47 с учетом всех этих изменений, если это исправится в версии .47 или выше. Наверное, я переключусь на следующий долгосрочный релиз, если дойдет до 6.46.x, и останусь на нем долгое время. Спасибо. 20:22:12 ipsec,debug ===== получено 588 байт от SERVER.IP[4500] к CLIENT.IP[4500]
20:22:12 ipsec -> ike2 запрос, обмен: CREATE_CHILD_SA:647 SERVER.IP[4500] 0cb9f8b572ccd9d2:671d673072bb45dc
20:22:12 ipsec наблюдается полезная нагрузка: ENC (560 байт)
20:22:12 ipsec обработка полезной нагрузки: ENC
20:22:12 ipsec,debug => iv (размер 0x10)
20:22:12 ipsec,debug 8f200ffd 066a266d 2fde2b2e 65e8fe75
20:22:12 ipsec,debug => открытая полезная нагрузка (усеченная) (первый 0x100 из 0x15c)
[...]
20:22:12 ipsec,debug расшифровано
20:22:12 ipsec наблюдается полезная нагрузка: SA (56 байт)
20:22:12 ipsec наблюдается полезная нагрузка: KE (264 байт)
20:22:12 ipsec наблюдается полезная нагрузка: NONCE (28 байт)
20:22:12 ipsec создайте дочерний: ответить
20:22:12 ipsec обработка полезных нагрузок: NOTIFY (не найдено)
20:22:12 ipsec IKE SA переобновление
20:22:12 ipsec обработка полезной нагрузки: SA
20:22:12 ipsec IKE Протокол: IKE
20:22:12 ipsec предложение #1
20:22:12 ipsec шифрование: aes256-cbc
20:22:12 ipsec prf: hmac-sha1
20:22:12 ipsec аутентификация: sha1
20:22:12 ipsec dh: modp2048
20:22:12 ipsec сопоставлено предложение:
20:22:12 ipsec предложение #1
20:22:12 ipsec шифрование: aes256-cbc
20:22:12 ipsec prf: hmac-sha1
20:22:12 ipsec аутентификация: sha1
20:22:12 ipsec dh: modp2048
20:22:12 ipsec обработка полезной нагрузки: KE
20:22:12 ipsec обработка полезной нагрузки: NONCE
20:22:12 ipsec,debug => общего секрета (размер 0x100)
[...]
20:22:12 ipsec добавление полезной нагрузки: SA
20:22:12 ipsec,debug => (размер 0x38)
20:22:12 ipsec,debug 00000038 00000034 01010804 2221e39a 3505ead6 0300000c 0100000c 800e0100
20:22:12 ipsec,debug 03000008 02000002 03000008 03000002 00000008 0400000e
20:22:12 ipsec добавление полезной нагрузки: KE
20:22:12 ipsec,debug => (первый 0x100 из 0x108)
[...]
20:22:12 ipsec добавление полезной нагрузки: NONCE
20:22:12 ipsec,debug => (размер 0x1c)
20:22:12 ipsec,debug 0000001c 203e646b 82b4313d 8245e5dd 127c06b8 5616ffd4 2809567b
20:22:12 ipsec <- ike2 ответ, обмен: CREATE_CHILD_SA:647 SERVER.IP[4500] 0cb9f8b572ccd9d2:671d673072bb45dc
20:22:12 ipsec,debug ===== отправка 588 байт от CLIENT.IP[4500] к SERVER.IP[4500]
20:22:12 ipsec,debug 1 раз сообщение объемом 592 байта будет отправлено на SERVER.IP[4500]
20:22:12 ipsec,debug => skeyseed (размер 0x14)
20:22:12 ipsec,debug e4e91dda d9655739 3da8eef1 58801b9e 34eb426a
20:22:12 ipsec,debug => keymat (размер 0x14)
20:22:12 ipsec,debug fee01920 53827f84 88158f25 84f3d0e9 707e5359
20:22:12 ipsec,debug => SK_ai (размер 0x14)
20:22:12 ipsec,debug 937273ae b00fb076 8f236545 62187208 af1b8e53
20:22:12 ipsec,debug => SK_ar (размер 0x14)
20:22:12 ipsec,debug 1b00b816 e35b7ecc 34db5064 cfe02c11 164d8412
20:22:12 ipsec,debug => SK_ei (размер 0x20)
20:22:12 ipsec,debug 34b5b506 029ec827 6bdfd883 b4f30bdc 8e742509 b9cf7d4f 4bd8f83d 1cf73936
20:22:12 ipsec,debug => SK_er (размер 0x20)
20:22:12 ipsec,debug 693beda2 7a2499e3 2bfd4a8c cdcf554b 3267e481 e7fab2b5 8e29a07f 7402bd29
20:22:12 ipsec,debug => SK_pi (размер 0x14)
20:22:12 ipsec,debug b1e71807 36c423a7 0ea99c40 b3fa92a8 b251e0f8
20:22:12 ipsec,debug => SK_pr (размер 0x14)
20:22:12 ipsec,debug 768a9e69 c7a55820 c31c1637 a82bf988 9af98cfb
20:22:12 ipsec,debug ===== получено 220 байт от SERVER.IP[4500] к CLIENT.IP[4500]
20:22:12 ipsec -> ike2 запрос, обмен: INFORMATIONAL:648 SERVER.IP[4500] 0cb9f8b572ccd9d2:671d673072bb45dc
20:22:12 ipsec полезная нагрузка: ENC (192 байта)
20:22:12 ipsec обработка полезной нагрузки: ENC
20:22:12 ipsec,debug => iv (размер 0x10)
20:22:12 ipsec,debug febd58d4 ff331e3f 59e75b7f f8d84588
20:22:12 ipsec,debug => открытая полезная нагрузка (усеченная) (размер 0x8)
20:22:12 ipsec,debug 00000008 01000000
20:22:12 ipsec,debug расшифровано
20:22:12 ipsec наблюдается полезная нагрузка: DELETE (8 байт)
20:22:12 ipsec ответить: информация
20:22:12 ipsec обработка полезных нагрузок: NOTIFY (не найдено)
20:22:12 ipsec обработка полезных нагрузок: DELETE
20:22:12 ipsec удаление IKE SA
20:22:12 ipsec <- ike2 ответ, обмен: INFORMATIONAL:648 SERVER.IP[4500] 0cb9f8b572ccd9d2:671d673072bb45dc
20:22:12 ipsec,debug ===== отправка 92 байта от CLIENT.IP[4500] к SERVER.IP[4500]
20:22:12 ipsec,debug 1 раз сообщение объемом 96 байт будет отправлено на SERVER.IP[4500]
20:22:12 ipsec переобновление завершено
20:22:20 script,info ike2peer: MONITORED.PEER переключился на сторону: ответчик
19.08.2020 17:42:00, Znevna.

IKEv2 между MikroTik, переключение сторон, инициатор <> ответчик

Tue, 18 Aug 2020 19:07:00 -0400

IKEv2 между MikroTik, переключение сторон, инициатор <> ответчик RouterOS в форуме RouterOS.
Как я уже писал ранее, у меня такое же поведение, но появляется оно между 15 и 35 минутами. Как и ты, я вел журнал, но там ничего необычного не было. Это происходит только с одним провайдером VPN. У меня это наблюдается на 4011 и hEX-S, так что платформа здесь ни при чем.
18.08.2020 19:07:00, msatter.

IKEv2 между MikroTik, переключение сторон, инициатор <> ответчик

Mon, 17 Aug 2020 17:45:00 -0400

IKEv2 между MikroTik, переключение сторон, инициатор <> ответчик RouterOS в форуме RouterOS.
Ок, я почти уверен, что во время этого (захвачено от клиента/инициатора) стороны сменились (инициатор → ответчик). Я также попытаюсь зафиксировать возврат к инициатору. Не знаю, полезно ли это. 20:20:54 ipsec,debug ===== получено 572 байта от SERVER.IP[4500] к CLIENT.IP[4500] 20:20:54 ipsec -> ike2 запрос, обмен: CREATE_CHILD_SA:652 SERVER.IP[4500] cd6c9547697d300f:62848846dee423c0 20:20:54 ipsec увиден полезный нагрузка: ENC (544 байта) 20:20:54 ipsec обрабатывается полезный нагрузка: ENC 20:20:54 ipsec,debug => iv (размер 0x10) 20:20:54 ipsec,debug c0fa451f 73228ef1 f14c675e fb472b10 20:20:54 ipsec,debug => обычная полезная нагрузка (обрезанная) (первый 0x100 из 0x15c) [...] 20:20:54 ipsec,debug расшифровано 20:20:54 ipsec увидена полезная нагрузка: SA (56 байт) 20:20:54 ipsec увидена полезная нагрузка: KE (264 байта) 20:20:54 ipsec увидена полезная нагрузка: NONCE (28 байт) 20:20:54 ipsec создание ребенка: ответ 20:20:54 ipsec обрабатываются полезные нагрузки: NOTIFY (не найдено) 20:20:54 ipsec IKE SA повторная ключировка 20:20:54 ipsec обрабатывается полезная нагрузка: SA 20:20:54 ipsec Протокол IKE: IKE 20:20:54 ipsec предложение #1 20:20:54 ipsec шифрование: aes256-cbc 20:20:54 ipsec prf: hmac-sha1 20:20:54 ipsec аутентификация: sha1 20:20:54 ipsec dh: modp2048 20:20:54 ipsec согласованное предложение: 20:20:54 ipsec предложение #1 20:20:54 ipsec шифрование: aes256-cbc 20:20:54 ipsec prf: hmac-sha1 20:20:54 ipsec аутентификация: sha1 20:20:54 ipsec dh: modp2048 20:20:54 ipsec обрабатывается полезная нагрузка: KE 20:20:54 ipsec обрабатывается полезная нагрузка: NONCE 20:20:55 ipsec,debug => общий секрет (размер 0x100) [...] 20:20:55 ipsec добавление полезной нагрузки: SA 20:20:55 ipsec,debug => (размер 0x38) [...] 20:20:55 ipsec добавление полезной нагрузки: KE 20:20:55 ipsec,debug => (первый 0x100 из 0x108) [...] 20:20:55 ipsec добавление полезной нагрузки: NONCE 20:20:55 ipsec,debug => (размер 0x1c) 20:20:55 ipsec,debug 0000001c 429690c6 8fac4d1b 62886a6c 550bbbfb 975d3caa a04d081d 20:20:55 ipsec <- ike2 ответ, обмен: CREATE_CHILD_SA:652 SERVER.IP[4500] cd6c9547697d300f:62848846dee423c0 20:20:55 ipsec,debug ===== отправка 604 байта от CLIENT.IP[4500] к SERVER.IP[4500] 20:20:55 ipsec,debug 1 раз сообщение на 608 байт будет отправлено на SERVER.IP[4500] 20:20:55 ipsec,debug => skeyseed (размер 0x14) 20:20:55 ipsec,debug 44c97490 7ade50cd 39b2eb9c c3e0ef70 352dc6a8 20:20:55 ipsec,debug => keymat (размер 0x14) 20:20:55 ipsec,debug e5521a7a b9e60133 47ea344e eb23a4a0 7898098b 20:20:55 ipsec,debug => SK_ai (размер 0x14) 20:20:55 ipsec,debug 4b25f7a9 7bf251ee 51550e5b 4754feee 883e1314 20:20:55 ipsec,debug => SK_ar (размер 0x14) 20:20:55 ipsec,debug 9cf2258b cbea40bd 69e3d15b e8aace02 89aac332 20:20:55 ipsec,debug => SK_ei (размер 0x20) 20:20:55 ipsec,debug 241a97d0 0b5715f3 879f50da 215c542d 22b7b919 ea759854 98cc7d90 1dfb9cbb 20:20:55 ipsec,debug => SK_er (размер 0x20) 20:20:55 ipsec,debug 1fbe224e 37be1c95 86d867d4 311ee753 3c04f145 bd8132f1 52177478 5a5cb2c7 20:20:55 ipsec,debug => SK_pi (размер 0x14) 20:20:55 ipsec,debug 17b360f0 4f448904 6b62ccb5 7691d409 1d1cea65 20:20:55 ipsec,debug => SK_pr (размер 0x14) 20:20:55 ipsec,debug cd9f7d3c 972a6cb5 e86d56eb cbcd38ab 0ae210e9 20:20:55 ipsec,debug ===== получено 236 байт от SERVER.IP[4500] к CLIENT.IP[4500] 20:20:55 ipsec -> ike2 запрос, обмен: INFORMATIONAL:653 SERVER.IP[4500] cd6c9547697d300f:62848846dee423c0 20:20:55 ipsec увидена полезная нагрузка: ENC (208 байт) 20:20:55 ipsec обрабатывается полезная нагрузка: ENC 20:20:55 ipsec,debug => iv (размер 0x10) 20:20:55 ipsec,debug e3ecfcda eccb7ebc 937b1493 7775fea4 20:20:55 ipsec,debug => обычная полезная нагрузка (обрезанная) (размер 0x8) 20:20:55 ipsec,debug 00000008 01000000 20:20:55 ipsec,debug расшифровано 20:20:55 ipsec увидена полезная нагрузка: DELETE (8 байт) 20:20:55 ipsec ответ: информация 20:20:55 ipsec обрабатываются полезные нагрузки: NOTIFY (не найдено) 20:20:55 ipsec обрабатываются полезные нагрузки: DELETE 20:20:55 ipsec удаление IKE SA 20:20:55 ipsec <- ike2 ответ, обмен: INFORMATIONAL:653 SERVER.IP[4500] cd6c9547697d300f:62848846dee423c0 20:20:55 ipsec,debug ===== отправка 108 байт от CLIENT.IP[4500] к SERVER.IP[4500] 20:20:55 ipsec,debug 1 раз сообщение на 112 байт будет отправлено на SERVER.IP[4500] 20:20:55 ipsec повторная ключировка завершена
17.08.2020 17:45:00, Znevna.

IKEv2 между MikroTik, переключение сторон, инициатор <> ответчик

Mon, 03 Aug 2020 07:42:00 -0400

IKEv2 между MikroTik, переключение сторон, инициатор <> ответчик RouterOS в форуме RouterOS.
Привет! Согласно названию темы, я настраиваю несколько IKEv2 туннелей на RB4011. К ним подключается несколько клиентов Windows, три моих других MikroTik (hAP ac2) и, думаю, один маршрутизатор на базе FreeBSD (поддержка какого-то программного обеспечения использует его), который иногда накопляет количество PH2, но это пока не проблема. Все MikroTik работают на версии 6.46.6. Между MikroTik у меня просто политика между двумя IP-адресами, по которой я запускаю IPIP Tunnel. Теперь время от времени, когда я проверяю активные пиры, я вижу один, два или всех трех MikroTik с перевернутыми сторонами. (все клиенты как инициаторы). Проверил на hAP ac2, и они тоже говорят "responder". Тем не менее, все работает, IPIP туннели никогда не отключаются. Должен ли я переживать из-за этого? RB4011 имеет конфигурацию пира с passive=yes и send-initial-contact=no. hAP ac2 имеют конфигурацию пира с passive=no и send-initial-contact=yes.

/ip ipsec active-peers> print detail
Flags: R - responder, N - natt-peer
0 RN id="win-22" side=responder dynamic-address=172.28.248.22 uptime=2w4d1h5m28s last-seen=1m3s ph2-total=1
1 RN id="win-23" side=responder dynamic-address=172.28.248.23 uptime=2w3d1h7m35s last-seen=1m13s ph2-total=1
2 RN id="win-21" side=responder dynamic-address=172.28.248.21 uptime=1w3d10s last-seen=1m24s ph2-total=1
3 RN id="win-25" side=responder dynamic-address=172.28.248.25 uptime=1w2d23h1m6s last-seen=20s
4 id="ac2-69" side=initiator dynamic-address=172.28.252.69 uptime=6d17h18m25s last-seen=1m5s ph2-total=1
5 RN id="win-12" side=responder dynamic-address=172.28.248.12 uptime=5d16h21m30s last-seen=1m17s
6 RN id="win-11" side=responder dynamic-address=172.28.248.11 uptime=3d1h41m20s last-seen=1m13s ph2-total=1
7 id="ac2-134" side=initiator dynamic-address=172.28.252.134 uptime=3d10m22s last-seen=41s ph2-total=1
8 N id="ac2-135" side=initiator dynamic-address=172.28.252.135 uptime=2d23h52m30s last-seen=1m11s ph2-total=1
9 R id="bsd" side=responder uptime=11h42m24s last-seen=0s ph2-total=2
10 RN id="win-42" side=responder dynamic-address=172.28.248.42 uptime=2h18m38s last-seen=33s ph2-total=1
11 RN id="win-13" side=responder dynamic-address=172.28.248.13 uptime=2h13s last-seen=22s
12 RN id="win-14" side=responder dynamic-address=172.28.248.14 uptime=45m11s last-seen=1m9s ph2-total=1
13 RN id="win-47" side=responder dynamic-address=172.28.248.47 uptime=25m30s last-seen=1m29s ph2-total=1
14 RN id="win-44" side=responder dynamic-address=172.28.248.44 uptime=11m3s last-seen=1m3s ph2-total=1

И пока я это писал, пир 8 снова поменял сторону. 8 RN id="ac2-135" side=responder dynamic-address=172.28.252.135 uptime=3d4m20s last-seen=54s ph2-total=1 Спасибо.
03.08.2020 07:42:00, Znevna.