iOS IKEv2 и strongSwan: согласование не выбрано — как исправить список

iPhone поднимает туннель, шлюз не отвечает ничем, а телефон показывает общую ошибку. Журнал strongSwan конкретнее: no proposal chosen. Это сообщение означает, что два списка допустимых наборов шифров ни разу не пересеклись, поэтому обмен завершился ещё до начала аутентификации. Это задача сопоставления, и решение — сделать списки пересекающимися.

Где шлюз объявляет свою политику

strongSwan записывает политику в конфигурацию, и восклицательный знак в конце определяет, как эту политику читать. С ним список исчерпывающий: принимаются только эти записи и ничего больше. Без него та же строка — порядок предпочтений, и демон может выбрать не то, что вы задумали. Спросите, какая форма развёрнута, прежде чем что-то переводить, потому что обе ведут себя по-разному с одним и тем же клиентом. Запишите точную строку вместе со знаком и проверяйте по ней.

Клиент с более широким списком всё равно может подключиться к закреплённому шлюзу, если хотя бы одна комбинация есть с обеих сторон. Чего произойти не может — согласования вне закреплённого набора.

Поэтому профиль, скопированный из другого VPN-приложения, может работать там, где ваш нет: то приложение отправляло другой список.

Имена должны совпадать, а не улучшаться

Два перевода путают тех, кто переносит значения из strongSwan в iOS. Алгоритм целостности, записанный как SHA1 в предложении IKE, идёт в усечённой форме, которую iOS называет .SHA96. Группа Диффи — Хеллмана, записанная как modp1024, — это группа 2, которую iOS называет .group2. Замена на SHA-256 или группу 14 не даст согласования со шлюзом, который принимает только старую пару. Клиент должен описать тот же алгоритм, а не более сильный.

Задайте эти значения явно в NEVPNProtocolIKEv2. Значения по умолчанию могут быть шире или уже заменяемого профиля, и разница проявляется только тогда, когда рукопожатие не удаётся.

Дочернее предложение падает позже и тише

Настройте и дочернюю ассоциацию безопасности, а не только IKE. Когда совпадают только параметры IKE, туннель аутентифицируется и затем не передаёт трафик, а это гораздо более тихий сбой, чем отказ. Задайте шифрование, целостность, группу и время жизни дочерней в одном проходе. Держите время жизни клиента на уровне шлюза или ниже, потому что настойчивость с более длинным даёт то же сообщение no proposal chosen по другой причине. Несовпадение там выглядит точно так же, как несовпадение IKE в журнале.

Проверьте, аутентифицируется ли профиль сертификатами или общим секретом, пока вы в конфигурации. Отказ предложения и отказ аутентификации появляются в разных строках, и исправление не той стоит дня. Тестируйте новым подключением после каждого изменения, по одной переменной за раз, потому что кэшированное состояние скрывает, какой параметр сдвинулся.

Оставляйте старый набор только пока он нужен

Закрепление SHA-1 с группой 1024 бита — это мост, а не цель. Оба устарели, и новые клиенты могут вовсе их отвергнуть, а значит, профиль откажет на следующем устройстве без каких-либо изменений с вашей стороны. Считайте закрепление временным и запишите это в протоколе.

Если strongSwan ваш, добавьте современное предложение и позвольте обеим сторонам согласовываться вверх, пока старая запись остаётся для старых устройств. Прочитайте вывод состояния демона, чтобы увидеть, какой набор действительно использовало каждое подключение. Затем уберите закрепление на стороне клиента, когда современная пара подтверждена. Поднятый туннель — недостаточное доказательство, потому что он может подняться на наборе, который вы пытались вывести из эксплуатации. Документация strongSwan по IKEv2 описывает синтаксис предложений и маркер strict.