Из спортивного интереса состыковал по IPSec Juniper SRX и OpenWRT (StrongSWAN) с использованием X509-сертификатов для взаимной аутентификации.
Конфиг ждунипера выглядит примерно следующим образом.
Конфиг StrongSWAN выглядит примерно следующим образом.
Некоторые мысли, которые я решил для себя отметить, чтобы потом не забыть.
... У StrongSWAN есть два варианта написания конфигов: "старый", он же "stroke-based", и "новый", он же "vici-based". По-хорошему бы, конечно, надо уже перейти на "новый" синтаксис. Но мне традиционно лень.
... Изначально я хотел взять криптоалгоритмы повеселее: AES-256-GCM. А также использовать GRE over IPSec. Но потом обнаружил, что при пересборке прошивки для OpenWRT я не добавил в ядро ни то, ни другое. Тихо поматерившись, пришлось откатиться на более старые алогоритмы. Обидно, досадно, ну ладно.
... Начиная с версий 5.8.0 для StrongSWAN, 4.19 для ядра и 5.1.0 для iproute2, вся эта связка начинает уметь в виртуальные XFRM-интерфейсы. Всё ручки чешутся попробовать, но всё никак не дойдут. Может тогда и не придется со стороны Linux-коробки городить все эти dummy-интерфейсы и GRE. Иначе маршрутизацию-фильтрацию дюже неудобно прикручивать.
... Вот странная какая штука. Я сделал на ждунипере два почти одинаковых IPSec-тоннеля: оба на IKEv2. Только один на сертификатах, второй на PreShared Key. Первый заработал без вопросов, а во втором он мне почему-то не дал использовать Traffic Selector-ы с мотивацией "address configuration under gateway with IKEv2 with traffic-selector is not suppported". Я, конечно, понимаю, что у меня там прошивка зело тухлая (12.3), но почему тогда первый-то заработал?!? Вроде как вот тут проясняют этот момент, но логичность поведения железки находится традиционно на грани ненаучной фантастики.
... Прежде чем заливать в ждунипер CA-сертификаты, нужно сперва закоммитить в конфиг "security pki ca-profile". Иначе не даст импортировать сертификат. Пресловутый "ca-profile" — это всего лишь отсылка на то, каким CA проверять тот или иной вражеский сертификат. Пафосность названий директив в конфиге over 9000. "Мы не отдел, мы департамент!"
... Сертификаты и ключи импортируются командой типа "request security pki local-certificate load filename /var/tmp/cert.crt key /var/tmp/priv.key certificate-id test". Но сперва их нужно, разумеется, скопировать на железку каким-нибудь scp (например). Сертификаты, сгенерированные при помощи EasyRSA, вполне себе нормально хаваюцца. Эллиптические ключи — тоже. Проверить валидность сертификата можно командой "request security pki local-certificate verify certificate-id test". CA-сертификат импортируется отдельной командой "request security pki ca-certificate load filename /var/tmp/ca.crt ca-profile test".
... Соответственно, в конфиге указывается не имя сертификата, а его алиас, заданный при импорте. Аналогично, для CA указывается "профиль". Вообще, конечно, последовательность действий немного ракообразная: создать профиль в конфиге, импортировать CA, импортировать сертификат, прописать его в конфиге. Минимизировать количество телодвижений не удастся.
... При использовании GCM-алгоритмов, на вражеской стороне нужно явно указывать "prfsha384", иначе не взлетит. Вот что ещё странно. Juniper требует, чтобы и в первой, и во второй фазе использовался бы один и тот же тип симметричных алгоритмов. То есть, либо и там и там CBC, либо и там и там GCM. Почему-то нельзя для первой фазы взять GCM, а для второй CBC. Казалось бы, при чём здесь Лужков?
... Для расчета MTU очень удобно пользоваться Cisco-вским калькулятором. Но он почему-то не для всех, а только для тех, у кого есть подписЬка. Странно, зачем они его анально огородили... жалко что ли для всех открыть?
... Нужно обязательно ждуниперу сказать "local-identity distinguished-name", иначе он будет слать врагу свой внешний IP-адрес в качестве identity, чего тот, скорее всего, не оценит и не поймёт. Вот StrongSWAN как-то сразу шлёт что нужно. А этому можжевельнику всё расжёвывать приходится.
... Не спрашивайте почему директива сверки вражеского сертификата называется "container". Сам не знаю при чём тут "контейнер". Просто строка в Subject, на совпадение с которой нужно проверить.
... Если со стороны StrongSWAN хочется отключить CRL (ну да, мы ведь еще собственный PKI поднимать, небось, собрались), то у charon-а в "/etc/strongswan.d/charon/revocation.con
... У StrongSWAN-а есть давняя багофича (ещё с 2010-го года тянется). Он не жрёт закрытые EC-ключи в PEM-формате. Только в DER. Соответственно, если мы их генерировали не его собственными утилитами, то придется конвертировать: "openssl ec -in khimky.staser.ru.key -outform DER -out khimky.der.key".
... Просто положить закрытый ключ в папочку "/etc/ipsec.d/private" для StrongSWAN недостаточно. Нужно его ещё прописать в "ipsec.secrets" примерно так. Пробел между двоеточием и словом "ECDSA" обяазателен.
: ECDSA khimky.der.key
... При испытаниях скорости мой древненький Juniper SRX-100 H2 смог пропустить через шифрованный канал чуть меньше 60 МБит/с. Не бог весть что. Но хоть что-то. Для OpenWRT+WireGuard предел был в районе 40 МБит/с. В следующей серии журнала "Мурзилка" попробую задействовать аппаратное криптоускорение AES на Xiaomi Mi 3G и погонять с ним в режиме GCM. Если, конечно, когда-нибудь дойдут до этого лапки. Самому интересно что получится.