Очередные грабли с IPSec (StrongSWAN + Juniper + IKEv2)

Во время строительства очередного IPSec-а опять традиционно походил по граблям. Потерял кучу времени и замудохал саппорт одного хостинг-провайдера. А на самом деле оказались очередные приколы мультивендорной несовместимости.

Короткое лирическое отступление. Прежде чем поднимется собственно IPSec-тоннель (ну или транспорт), стороны должны обменяться друг с другом сеансовыми ключами по протоколу IKE. У него на данный момент есть две ревизии: v1 и v2. Перед генерацией сеансовых ключей должна произойти взаимная аутентификация сторон друг перед другом каким-то из способов. При этом имеет значение, кто из них начинает церемонию, а кто подхватывает. В зависимости от этого та или иная сторона будет называеться Initiator или Responder.

Если обе стороны обладают "честным" ("прямым", "белым") IP-адресом, то любая из них может оказаться как Initiator-ом, так и Responder-ом. Как говорится, кто первым халат одел, тот и доктор initiator.

Далее проводим серию экспериментов, когда у нас с одной стороны StrongSWAN, с другой Juniper SRX. Всякий раз меняем версию IKE, способ аутентификации, роли (initiator-responder). И смотрим что получается или не получается. Результаты занесем в табличку.

Первые три строчки не особо интересны. В гомогенном (слово-то какое, тьфу) варианте всегда всё будет нормально работать. Ну в смысле "такой же с таким же". Дальше видим, что в случае аутентификации по сертификатам тоже все норм (RSA или ECDSA). А вот в комбинации "PSK + IKEv2" ждунипер нормально заводит соединение со StrongSWAN, но не наоборот. При этом если откатить всё на IKEv1, то опять всё работает.

Со стороны выглядит это так, что Juniper дает StrongSWAN-у отлуп с мотивацией "Invalid syntax". Везде в мануалах сказано, что это означает неправильный PSK (Pre-shared Key). Но при этом в другую-то сторону всё работает отлично, то есть на самом-то деле он правильный.

Единственное что я смог выяснить пока курил дампы IKE-обмена, это что при аутентификации в сообщении "Identification - Initiator" Juniper шлет StrongSWAN-у более жирный Payload, нежели при обратном процессе. В моих экспериментах разница составляла 213 байт супротив 138. Видимо, Juniper ожидает там получить что-то эх-такое, чего charon ему почему-то прислать не хочет. Но, увы, моей квалификации уже недостаточно для того чтобы разобраться, очередной ли это баг Juniper-а, или же косяк в StrongSWAN.

Как-то так. Шел 21-й век, а запилить нормальную совместимость по IKEv2 так и не шмагли...

UPDATE. Пока больше похоже на косяк StrongSWAN-а. Потому что если портировать тот же конфиг на "старый" stroke-синтаксис, оно таки заводится. А в "новом" VICI-синтаксисе — нет. Есть, конечно, ненулевая вероятность, что я неправильно конфиги портировал. Но очень загадочно всё это...

UPDATE2. Вообще дичь эталонная. Если стартовать только прицельно ike-соединение вот так:

то хрен вамъ.

Если же стартовать сразу его "ребёнка" вот так:

То всё зашибись.

Попробую запостить баг в StrongSWAN, может чего умного подскажут...

UPDATE3. Похоже, что я вляпался в childless IKE_SA. И в отсутствие их поддержки у Juniper-ов...