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 մեթոդն ու բեքենդի քաղաքականությունն են, ոչ թե նույնականությունը։ Գաղտնաբառի վերականգնման կրկնումը չի կարող ուղղել ավելի վաղ արձանագրային շերտում ընտրված արժեքը։

Առնչվող հոդվածներ