Я хочу настроить шлюз IKEv2 VPN для доступа нескольких удаленных пользователей к частной сети.
У меня есть тестовая установка, в которой респондент аутентифицируется с помощью самозаверяющего сертификата. Инициатор аутентифицируется с помощью имени пользователя и пароля.
Пара вопросов:
За исключением развертывания надлежащего PKI, я бы предпочел выполнить взаимный аутентификация хостов инициатора и ответчика через PSK. Этот ключ будет безопасно распространен среди всех пользователей. У сторонних злоумышленников не будет PSK, поэтому слабый или взломанный пароль недостаточен для доступа. Аутентификация по имени пользователя и паролю позволяет идентифицировать и авторизовать конкретного пользователя в существующей системе каталогов без необходимости создания и распределения уникальных ключей для каждого пользователя.
Возможно ли такое с IKEv2? Насколько я могу судить, это было возможно через Xauth в IKEv1. Но в отношении IKEv2 я не уверен: бегло прочитав RFC 5996, раздел 2.16, похоже, это может быть не так. Аутентификация имени пользователя и пароля будет происходить с помощью некоторого метода EAP и:
Инициатор указывает на желание использовать EAP, пропуская полезную нагрузку AUTH из первого сообщения в обмене IKE_AUTH. (Обратите внимание, что полезная нагрузка AUTH требуется для аутентификации, отличной от EAP, и поэтому не помечена как необязательная в остальной части этого документа.)
Это предполагает, что инициатор может использовать только один из EAP (имя пользователя и пароль) или PSK.
Хотя вопрос касается протокола IKEv2, я намерен реализовать ответную часть с помощью strongswan, поэтому любые дополнительные знания будут оценены.
Аутентификация клиента и сервера в IKEV2 не связана. Так что теоретически вы можете аутентифицировать сервер с помощью PSK, а клиента с помощью EAP. Однако RFC утверждает следующее относительно аутентификации EAP:
Помимо аутентификации с использованием подписей с открытым ключом и общих секретов, IKE поддерживает аутентификацию с использованием методов, определенных в RFC 3748 [EAP]. Как правило, эти методы асимметричны (предназначены для аутентификации пользователя на сервере), и они могут не быть взаимными. По этой причине эти протоколы обычно используются для аутентификации инициатора перед ответчиком. и ДОЛЖЕН использоваться вместе с аутентификацией на основе открытого ключа и подписи ответчика для инициатора..
Таким образом, объединение аутентификации сервера PSK с аутентификацией клиента EAP не соответствует RFC. Однако его можно настроить с помощью strongSwan. Но учтите, что большинство клиентов не допускают такую комбинацию.
Многие клиенты Roadwarrior на самом деле вообще не поддерживают аутентификацию PSK, поскольку в таких сценариях возникает потенциальная угроза безопасности, если один и тот же PSK используется с несколькими клиентами, потому что все клиенты, которые знают PSK, теоретически могут олицетворять сервер.
У меня есть тестовая установка, в которой респондент аутентифицируется с помощью самозаверяющего сертификата.
Почему бы не использовать Давайте зашифровать?
Инициатор аутентифицируется только по имени пользователя и паролю, поэтому внешний злоумышленник может легко попытаться угадать слабые или взломанные пароли.
Использование PSK для аутентификации сервера не изменит этого. Вам нужно будет добавить второй фактор к аутентификации клиента, чтобы что-то сделать с этим (т.е. сначала используйте сертификат или PSK, а затем выполните EAP). Однако для этого требуется поддержка RFC 4739, которого не хватает многим клиентам (хотя strongSwan его поддерживает).