Ваш SA IKEv2 поднят, но дочернего SA нет: прочитайте обмен

IKE говорит, что туннель поднят, дочерний SA отсутствует, и оба утверждения могут быть верны одновременно. Установленное отношение управления не является ассоциацией данных, и у двух объектов разные времена жизни, согласования и режимы отказа. Сообщить о первом как о связности — это путь, которым заявка в итоге утверждает, что туннель поднят, хотя ничего не работает. Читайте список ассоциаций, а не сводную метку соединения, потому что этот список — единственное место, где виден отсутствующий объект. Далее идёт порядок, в котором список обретает смысл.

Две ассоциации, две задачи

SA IKE несёт канал управления: идентичности, ключи и предложения для самого обмена управлением. Дочерний SA несёт защиту ESP со своими алгоритмами и своими селекторами трафика. Аутентификация и создание дочернего SA обычно идут вместе, потому что первый дочерний SA согласуется внутри IKE_AUTH, и именно эта связка удивляет людей разделением.

Это объясняет и две формы отказа, с которыми вы столкнётесь. Дочерний SA, отклонённый во время начального обмена, обычно тянет за собой и SA IKE, так что установленного канала управления вы вообще не видите. Одинокий SA IKE чаще означает, что первый дочерний SA удался, а более поздняя попытка создать дочерний SA не удалась, например при обновлении ключей. Временные метки разделяют эти случаи быстрее любого просмотра конфигурации.

Какой уровень отказал

Когда дочерний SA отклоняется, уведомление называет уровень. Отказ предложения означает, что стороны не смогли договориться об алгоритмах, часто потому что одна требует другой группы совершенной прямой секретности или шифра, который другая не примет. Отказ селектора означает, что набор трафика был отклонён сразу, и это аргумент охвата, а не криптографический.

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

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

Затем спросите о пути данных

Как только дочерний SA существует, на следующий вопрос отвечают счётчики. ip -s xfrm state сообщает число пакетов и байтов по каждой ассоциации, и дочерний SA, который ничего не несёт, пока вы создаёте трафик, указывает на сопоставление или маршрутизацию, а не на отсутствующую ассоциацию. swanctl --list-sas печатает селекторы дочернего SA рядом с этими счётчиками, и именно это подтверждает, что пакет находится внутри принятого набора.

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

Сопоставьте два конца

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

Исправьте согласование дочернего SA, затем повторите проверку с трафиком внутри нужного селектора. Это единственная проверка, доказывающая, что отсутствующий объект теперь присутствует, потому что список ассоциаций, обновлённый в покое, может выглядеть одинаково до исправления и после.