Клиент Windows IKEv2 подключается, и запрос RADIUS приходит с адресом там, где должно быть имя учётной записи. Пока ничего не сломалось, и именно это сбивает с толку: шлюз сообщает идентификатор, который клиент представил на уровне IKE. Имя пользователя, которое нужно вашему бэкенду, может приходить из отдельного обмена EAP, ещё не состоявшегося. Решите, кто его запрашивает, прежде чем менять учётную запись.

Два идентификатора путешествуют в одном соединении

В одном соединении могут появиться два имени. Идентификатор IKE определяет партнёра при настройке туннеля, и плагин eap-radius изначально копирует его в RADIUS User-Name. Идентификатор EAP — другое значение, используемое для аутентификации пользователя, и он может никогда не отправляться, если никто его не запросит.

Поэтому журнал RADIUS может показывать адрес, хотя учётная запись существует и пароль верен. У бэкенда спрашивают о неверном уровне. Атрибут RADIUS — лишь транспорт для выбранного имени.

Попросите шлюз запросить идентификатор EAP

Одна поддерживаемая конфигурация заставляет шлюз запрашивать идентификатор EAP до передачи аутентификации в RADIUS. В разделе удалённой аутентификации соединения задайте метод eap-radius и явно запросите идентификатор EAP. Фрагмент ниже относится внутрь существующего блока соединения, а не в отдельный файл. Подтвердите соединение и бэкенд конфигурации, прежде чем копировать синтаксис из другого развёртывания.

remote {
    auth = eap-radius
    eap_id = %any
}

С этим бэкенд получает идентификатор, который клиент предоставляет в обмене EAP, вместо адреса IKE. Больше в соединении ничего не меняется.

Или позвольте RADIUS начать обмен EAP

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

charon {
    plugins {
        eap-radius {
            eap_start = yes
        }
    }
}

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

Проследите одну попытку в обоих журналах

Сопоставьте одну попытку в обоих журналах. Смотрите на идентификатор IKE, затем на то, происходит ли обмен EAP-Identity, затем на то, какое имя получает шаг аутентификации. Бэкенд, отклоняющий адрес до обмена EAP, может остановить процесс раньше, чем предполагаемый идентификатор вообще будет замечен.

journalctl -u strongswan -f

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

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

Похожие статьи