Windows IKEv2 müştərisi qoşulur və RADIUS sorğusu hesab adının olmalı olduğu yerdə bir ünvanla gəlir. Hələ heç nə uğursuz olmayıb və çaşdırıcı hissə də budur: şlüz müştərinin IKE qatında təqdim etdiyi kimliyi bildirir. Backend-inizin istədiyi istifadəçi adı hələ baş verməmiş ayrı bir EAP mübadiləsindən gələ bilər. Hesabı dəyişməzdən əvvəl bunu kimin soruşacağını müəyyənləşdirin.

Bir bağlantıda iki kimlik səyahət edir

Bir bağlantıda iki ad görünə bilər. IKE kimliyi tunel qurulması zamanı həmsöhbəti müəyyən edir və eap-radius plagini əvvəlcə onu RADIUS User-Name sahəsinə kopyalayır. EAP kimliyi istifadəçi autentifikasiyası üçün istifadə olunan fərqli bir dəyərdir və heç kim istəməzsə, heç vaxt göndərilməyə bilər.

Buna görə RADIUS jurnalı hesab mövcud və parol düzgün olduğu halda bir ünvan göstərə bilər. Backend-dən səhv qat haqqında soruşulur. RADIUS atributu yalnız seçilmiş ad üçün daşıyıcıdır.

Şlüzdən EAP kimliyini tələb etməsini xahiş edin

Dəstəklənən variantlardan biri şlüzün autentifikasiyanı RADIUS-a təhvil verməzdən əvvəl EAP kimliyini tələb etməsidir. Bağlantının uzaqdan autentifikasiya bölməsində metodu eap-radius olaraq təyin edin və EAP kimliyini açıq şəkildə tələb edin. Aşağıdakı fraqment öz faylında deyil, mövcud bağlantı blokunun içindədir. Sintaksisi başqa yerləşdirmədən kopyalamazdan əvvəl bağlantını və konfiqurasiya backend-ini təsdiqləyin.

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

Bu qurulduqda backend IKE ünvanı yerinə müştərinin EAP mübadiləsində təqdim etdiyi kimliyi alır. Bağlantıda başqa heç nə dəyişmir.

Və ya EAP mübadiləsini RADIUS başlatsın

Digər variant ilk addımı RADIUS tərəfinə qoyur. Plugin ilkin kimlik cavabını gözləmək əvəzinə EAP-Start siqnalı göndərə bilər və bu, serverə mübadiləni idarə etməyə imkan verir. Bu, plugin səviyyəsində konfiqurasiyadır, ona görə plugini istifadə edən hər bağlantıya təsir edir.

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

Hər ikisini aktivləşdirib ümid etmək əvəzinə RADIUS operatoru ilə bir variant seçin. Onlar fərqli iş axınlarını təsvir edir və başlamağı gözləyən server söhbəti başladan şlüzü mütləq idarə etməyəcək. Plugin sənədləri hər addımın hansı kimliyi daşıdığı daxil olmaqla, hər ikisini təsvir edir.

Bir cəhdi hər iki jurnalda izləyin

Tək bir cəhdi hər iki jurnal üzrə əlaqələndirin. IKE kimliyinə, sonra EAP-Identity mübadiləsinin baş verib-vermədiyinə, sonra autentifikasiya addımının hansı adı aldığına baxın. EAP mübadiləsindən əvvəl ünvanı rədd edən backend nəzərdə tutduğunuz kimlik heç görünməmişdən prosesi dayandıra bilər.

journalctl -u strongswan -f

Kimlik sisteminin gözlədiyi dəqiq istifadəçi adı formatını, domen prefiksi daxil olmaqla saxlayın. Heç vaxt ünvan formalı dəyərdən hesab uydurmayın və heç vaxt siyasət qaydasını ödəmək üçün autentifikasiyanı söndürməyin. EAP kimliyi bəyan edilmiş addır və metod hələ də onu sübut etməlidir. Yaranan adı test qeydinə yazın ki, növbəti cəhd məlum vəziyyətdən başlasın.

Düzəldilmiş axın düzgün hesaba çatıb yenə də rədd edilirsə, növbəti sübut kimlik deyil, EAP metodu və backend siyasətidir. Parol sıfırlamasını təkrarlamaq daha əvvəlki protokol qatında seçilmiş dəyəri düzəldə bilməz.

Əlaqəli məqalələr