При моделировании сценариев администратору необходимо учитывать правила согласования набора параметров IKE в процессе установления соединений.

С-Терра VPN Клиент (как и аналогичные продукты ряда других производителей), будучи инициатором создания защищённого соединения, изначально высылает Шлюзу для согласования два набора предложений с параметрами, отличающихся между собой идентификаторами метода аутентификации. А именно, с использованием XAuth и без XAuth.

Если в конфигурации Шлюза более приоритетное правило допускает использование предложенного набора с XAuth, то при совпадениях параметров в менее приоритетных правилах всегда будет выбран тот же набор с XAuth.

Однако в Main mode ответчик в начале обмена 1-й фазы выбирает метод аутентификации, ограничивая тем самым список собственных подходящих IKERule, и только в конце 1-й фазы окончательно определяет по зашифрованному идентификатору партнёра правило создания соединения.

Таким образом, если на Шлюзе в LSP присутствуют IKERule и с XAuth (с AAA c указанным ClientDialogType), и без XAuth (соответственно, без AAA либо с AAA без ClientDialogType), то при совпадении по IKETransform для пришедшего Клиента всегда будет выбираться трансформ, попадающий под наиболее приоритетное локальное правило, независимо от использования в нём XAuth. И когда в конце 1-й фазы Шлюз получит ID Клиента, может выясниться, что для данного Клиента 1-я фаза проводилась не с тем методом аутентификации, и в построении соединения будет отказано.

Возможен ещё более запутанный вариант, когда ID Клиента подходит под несколько правил (например, в правиле аутентификации RemoteID отсутствует либо используется TEMPLATE), но проводится дополнительная аутентификация на RADIUS сервере. Если в неправильно выбранном IKERule AAA не только с ClientDialogType, но и c несоответствующим значением ForcedUser либо ForcedPasswordId, то RADIUS сервер, скорее всего, не даст разрешение на соединение с таким партнёром.

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

Если всё же требуется работать с разнородными партнёрами, то в качестве обходного решения для вышеописанных случаев можно рекомендовать корректно «развести» Клиентов по правильным IKERule в начале 1-й фазы, используя для них разные криптоалгоритмы в трансформах (например, когда это допустимо, для одного семейства Клиентов использовать VKO2_1B, а для другого VKO_1B).

 

Внимание!

Данное примечание актуально для многоэтапной аутентификации реализованной на С-Терра Клиент 4.3: например, с подтверждением входа по SMS, когда за одну сессию пользователю требуется последовательно вводить данные более чем в одном окне диалога.

Суммарное время, за которое пользователь должен успеть ввести данные во всех окнах во время многоэтапной аутентификации на С-Терра Клиент 4.3, не должно превышать значение заданное в LSP атрибуте SessionTimeMax структуры IKEParameters  на С-Терра Шлюз 4.3.

 

Рекомендации: При реализации многоэтапной аутентификации на С-Терра Клиент 4.3 администратору на С-Терра Шлюз 4.3 необходимо установить ограничение времени на сессию IKE, задаваемое в атрибуте SessionTimeMax структуры IKEParameters, указав достаточное время для заполнения пользователем всех необходимых полей всех запросов дополнительной аутентификации.

Например, если пользователю требуется до 60 секунд на заполнение поля в каждом из последовательных окон диалога двухэтапной аутентификации, то на С-Терра Шлюз 4.3 атрибуту SessionTimeMax необходимо присвоить значение 130:

IKEParameters(

   SessionTimeMax = 130

)

IKEParameters = время на заполнение поля в первом окне (60 сек.) + время на заполнение поля во втором окне (60 сек.) + 10 секунд на остальные неинтерактивные обмены.