RADIUS Access-Challenge cavabından sonra VPN girişi donur

Parolunuz düzgündür, VPN girişi yenə də alınmır və RADIUS serveri ola bilsin ki, ona deyiləni tam yerinə yetirib. Şlüz çox güman ki, Access-Challenge alıb, faydalı heç nə göstərməyib, sonra vaxt aşımına uğrayıb və ya bu cavabı rədd kimi qəbul edib. Müştəri tərəfindən bu, səhv etimad məlumatı və ya pozulmuş tunel kimi görünür. Səbəb adətən heç kimin tutmadığı söhbətin ortasında olur.

Bir giriş, iki RADIUS mübadiləsi

Arxa sistem ikinci faktor istəyəndə ilk sorğuya qəbul və ya rədd ilə cavab vermir. 11 kodu ilə cavab verir və istifadəçinin növbəti cavabını gözləyir; şlüz həmin cavabı təqib sorğusunda geri göndərməlidir. Bu təqib eyni autentifikasiya söhbətinə aiddir, yeni giriş cəhdinə deyil.

İşlək qurmada istifadəçi ikinci sorğu görür: əvvəl parol, sonra birdəfəlik kod, ya da operator sənədləşdiribsə, tək birləşdirilmiş sorğu. Pozaq qurmada ikinci sorğu heç vaxt görünmür və giriş sadəcə alınmır.

İzlənməli simptom budur və yalnız müştəri tərəfindən təsdiqləmək asandır: VPN müştərisi tam bir sirr soruşub sonra düzgün bildiyiniz parolu rədd edirsə, mübadilə çox güman ki, challenge mərhələsində bitib.

Challenge əslində nə daşıyır

RADIUS spesifikasiyası 4.4 bölməsində 11 kodunu təsvir edir və burada əhəmiyyətli iki atribut icazə verir. Reply-Message istifadəçi üçün nəzərdə tutulmuş mətni saxlayır, State isə serverin geri qaytarılmasını istədiyi qeyri-şəffaf dəyəri saxlayır. NAS State-i şərh etməməli, yalnız dəyişməz qaytarmalıdır.

Təqib sorğusu yeni Identifier və yeni Request Authenticator istifadə edir və eyni State dəyərini üstəgəl istifadəçinin cavabını daşımalıdır. Server onu həmin State vasitəsilə gözləyən challenge ilə uyğunlaşdırır; buna görə atributu yenidən yaradan və ya atan şlüz mərasimi tamamlaya bilmir. Hər cavabdakı response authenticator da doğrulanmalıdır, əks halda NAS paketi atmalıdır.

4.4 bölməsi səssiz uğursuzluqların çoxunu izah edən detalı əlavə edir: challenge-ları dəstəkləyə bilməyən NAS Access-Challenge-ı rədd kimi qəbul edir. Şlüzünüzün VPN xidməti bu dəstəyi əhatə etmirsə, arxa sistemin ikinci faktor sorğusu heç bir sorğu olmadan dərhal «autentifikasiya alınmadı» olur.

Zəncirlənmiş sorğu harada itir

İlk şübhəli etimad məlumatı deyil, sorğu yoludur. Veb girişləri üçün OTP sahəsi göstərən portal bunu avtomatik VPN xidməti üçün etmir və bəzi şlüzlər challenge-ı yalnız bu qabiliyyəti elan edən müştərilərə ötürür. Eyni hesabı hər iki giriş nöqtəsində yoxlayın; portal işləyib VPN işləmirsə, baxdığınız şey ötürmədir, token deyil.

İkinci şübhəli giriş formatıdır. Parolu və kodu satıcının sənədləşdirdiyi ayırıcı olmadan birləşdirmək və ya saxlanmış etimad məlumatının köhnə kodu təkrarlamasına imkan vermək, səhv parolla eyni görünən uğursuzluq yaradır. Operatorun sənədləşdirdiyi ayrı sorğudan və ya birləşdirilmiş formatdan istifadə edin və ayırıcı uydurmayın.

Buraxılışa xas qüsurlar mövcuddur, lakin illər əvvələ aid düzəldilmiş versiyalar siyahısı bugünkü qurulum üçün diaqnoz deyil. Həqiqətən işlətdiyiniz proqramın buraxılış qeydlərini oxuyun və müşahidə etdiyiniz mübadilə mərhələsini sübut kimi saxlayın.

Tək cəhdi başdan sona izləyin

Server tərəfində sazlama açıq halda bir dəfə təkrar yaradın və hər digər sessiyanı tutma pəncərəsindən kənarda saxlayın:

$ sudo radsniff -i eth0 -x -f 'udp port 1812'
$ sudo freeradius -X
$ radtest alice 'password' 127.0.0.1 0 testing123

Çıxışda tək sətir deyil, söhbətin formasını axtarın. Identifier 3 olan ilk Access-Request, State daşıyan bir Access-Challenge, sonra həmin State-i təkrarlayan və istifadəçinin cavabını ehtiva edən Identifier 4 olan ikinci Access-Request. İkinci sorğu yoxdursa, şlüz heç vaxt təqib etməyib. State olmadan gəlirsə, server onu gözləyən challenge ilə uyğunlaşdıra bilməz və adətən rədd edər.

İzi paylaşarkən etimad məlumatlarını, tokenləri və lazımsız şəxsiyyət məlumatlarını silin və bir neçə brauzer nişanındakı təkrarları qarışdırmaq əvəzinə hadisələri tək cəhddən əlaqələndirin. Vaxt damğaları burada dostunuzdur; müştəri əl çəkdikdən sonra gələn challenge istifadəçiyə rədd, jurnalda isə gec cavab kimi görünür.

İstədiyiniz yekun vəziyyət tamamlanmış, icazə verilmiş söhbət və ardınca nəzərdə tutulan xidmət girişidir. RADIUS serverindən gələn cavab bundan qat-qat azını sübut edir.