Защо RADIUS вижда IP адрес вместо потребителското име на VPN

strongSwan може да постави идентичността на IKE в RADIUS User-Name преди какъвто и да е обмен на EAP. Решете кой иска идентичността на акаунта, след което свържете един опит.

Клиент на 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 и политиката на бекенда, а не идентичността. Повтарянето на нулиране на парола не може да поправи стойност, избрана на по-ранен протоколен слой.

Подобни статии