Две личности в одном входе IKEv2: сначала машина, затем пользователь

Сертификат клиента проверяется, первый обмен завершается, и затем соединение останавливается с ошибкой о дополнительном раунде аутентификации. В цепочке сертификатов нет ничего неверного, и в сети ничего не изменилось. Шлюз настроен требовать второе доказательство от подключающейся стороны, а клиент никогда его не отправляет. Решить, кто что доказывает и в каком порядке, — это вся задача, и она начинается с чтения политики с той конечной точки, на которой вы стоите. Два доказательства разного рода в фиксированном порядке — это проектное решение, а не флажок.

Симптом: сбой после успешного первого доказательства

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

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

Что добавляет расширение и что нет

IKEv2 несёт расширение для проведения более одного обмена аутентификации в рамках одной сессии. RFC 4739 описывает, среди прочих последовательностей, клиента, который доказывает личность по сертификату, а затем аутентифицирует человека через EAP. Документ имеет статус Experimental, то есть ни одна реализация вам эту функцию не обязана. Не предполагайте ничего о поддержке, пока партнёр не договорится о ней.

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

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

EAP-TLS — третья форма, и это тоже не она. Там сертификат клиента предъявляется внутри метода EAP, поэтому клиент всё равно завершает одну аутентификацию IKE. Учётные данные могут выглядеть так же, как в случае нескольких раундов, тогда как протокол несёт один раунд вместо двух. Поэтому проект, скопированный из развёртывания EAP-TLS, терпит неудачу именно там, где ожидается второе доказательство.

Тот же файл на шлюзе читается иначе

Тот же файл swanctl читается иначе в зависимости от того, где он выполняется, и именно на этом люди спотыкаются. На ноутбуке шлюз является партнёром, а на шлюзе партнёром является ноутбук, поэтому пишите сторону local как кто я, а сторону remote как кого я приму. Блок local описывает, как эта конечная точка аутентифицирует себя, а блок remote указывает, что он требует от другого конца. Копирование блока между двумя файлами переворачивает его смысл, не меняя ни одного символа. Сравнение двух файлов почти ничего не даёт, потому что одни и те же слова в каждом из них означают противоположное.

Положение раздела задаёт его порядок, если номер раунда не перекрывает его. Поэтому дополнительные разделы local или remote описывают дополнительные раунды, а не альтернативы, и явный номер раунда в справочнике swanctl.conf существует именно для того, чтобы этот порядок был намеренным. Без него перемещение блока меняет поведение. Поэтому и две конфигурации, которые на бумаге выглядят равнозначными, могут вести себя в обратном порядке.

Это правило порядка порождает режим отказа, который стоит запомнить. Второй блок remote — не ещё один допустимый вариант; это второе требование, поэтому политика, читаемая как «или/или», ведёт себя как «и-затем». Политика шлюза может принять сертификат зарегистрированной машины, а затем потребовать обмен EAP этого пользователя, именно в этом порядке.

Различайте раунды и независимые факторы

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

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

Запишите, что каждый раунд действительно доказывает, прежде чем добавлять его. Когда два раунда доказывают одно и то же дважды, второй добавляет задержку и обращения в поддержку вместо уверенности. Эта заметка также останавливает спор о том, оправдывает ли дополнительный раунд свою стоимость.

Напишите правило сопоставления и проверьте отказы

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

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

swanctl --list-conns
swanctl --list-sas

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