Statik çağırış kodunun OpenVPN girişində yeri

Müştəri parol sahəsindən sonra ikinci qutu göstərir, siz aparat tokenindən kodu yazırsınız və giriş yenə də autentifikasiya xətası ilə alınmır. Bu qutu mövcuddur, deməli profil onu tələb edib. Serverin dəyəri başa düşdüyü formada alıb-almaması isə başqa sualdır və ilk cavablandırılmalı olan məhz budur.

Müştərinizin həqiqətən göstərdiyi sorğu mətnindən başlayın

Profil sorğu mətni və cavabın yazarkən göstərilib-göstərilməyəcəyini idarə edən bayraqla statik çağırış direktivini daşıya bilər. Sorğu mətni dialoqda gördüyünüz şeydir; bayraq həmin daxiletmə üçün ekran üstünlüyüdür. Heç biri serverə nəyisə necə yoxlamağı demir.

Həqiqətən verilən sahələri sayın. İstifadəçi adı üçün bir sahə və bir maskalanmış sahə heç bir çağırış olmadan adi parol girişidir. Paroldan sonra öz etiketi ilə görünən ikinci sahə isə müştərinin çağırış qarşılıqlı əlaqəsini həyata keçirməsidir.

İstifadə etdiyiniz müştəridə ikinci qutu heç görünmürsə, o müştəri qarşılıqlı əlaqəni həyata keçirmir, ya da onu yalnız idarəetmə interfeysi kimi fərqli bir ön paneldən həyata keçirir. Müştərini yoxlamaq profili yenidən yazmaqdan ucuzdur və uyğunsuzluq adətən məhz orada olur.

Serverin artıq dəstəkləməli olduğu şeylər

Profil müştərinin nə toplamalı olduğunu təsvir edir. O, serverdə yoxlamanı aktivləşdirmir və uyğun autentifikasiya inteqrasiyası olmayan server sadəcə tanımadığı bir parol alacaq. Buna görə bəzi quraşdırmalar sorğunu göstərir və hər kodu rədd edir, və buna görə yoxlamanı hansı mexanizmin etdiyi barədə operatorun cavabı vacib olan cavabdır.

Operatora yoxlamanı hansı mexanizmin etdiyini soruşun. Bu, PAM ilə danışan plagin, cavabı token xidmətinə qarşı yoxlayan skript qarmağı və ya yığılmış dəyəri özü təhlil edən idarəetmə əsaslı inteqrasiya ola bilər. Onların hər biri bir az fərqli daxiletmə gözləyir.

Gözləntilərin tənzimlənməsi də elə buradadır. İkinci sorğu daxiletmə mexanizmidir, ikinci amilin tətbiq olunduğunun sübutu deyil, çünki tətbiq server tərəfində baş verir və yalnız səhv kodu sınayanda görünür.

İdarəetmə interfeysinin göndərdiyi kodlaşdırılmış sahə

Ön panel bağlantını idarəetmə interfeysi vasitəsilə idarə etdikdə, parol və çağırış cavabı göndərilməzdən əvvəl tək bir dəyərdə yığılır. İdarəetmə interfeysi sənədi formatı belə təsvir edir: prefiks, sonra ayrı Base64 komponentləri kimi parol və cavab.

Base64 kodlaşdırmadır, qoruma deyil. O, sahəni oxuya bilən heç kimdən heç nə gizlətmir və birdəfəlik kodu təkrar istifadə oluna bilən bir şeyə çevirmir. Yığılmış dəyər parolla eyni rəftarı haqq edir: paylaşılan profillərdən, əmr sətirlərindən və diaqnostik jurnallardan kənarda.

Bu kodlaşdırma həm də ən çox yayılmış çaşqınlıq mənbəyidir, çünki indi oxşar görünən və bir-birini əvəz etməyən üç forma var. Adi etimadnamə faylı parol saxlayır. Parolun və kodun hərfi birləşməsi fərqli sətir saxlayır. İdarəetmə müştərisinin yığılmış cavabı üçüncünü saxlayır. Yalnız xəta yox olduğu üçün sahəni dəyişməzdən əvvəl yoxlama yolunuzun hansını gözlədiyini təsdiqləyin.

Statik və dinamik: fərqli vaxtlama

Statik çağırış ilk etimadnamə göndərilməzdən əvvəl məlumdur, ona görə müştəri onu əvvəlcədən soruşa bilər. Dinamik çağırış isə sonra gəlir, mübadilə artıq başladıqdan sonra autentifikasiya iş axını tərəfindən göndərilir və söhbətin ortasında gələn sorğu ilə bacaran müştəri tələb edir.

Birini dəstəkləmək digərini vermir. Statik sorğu quran profil direktivi serverin başlatdığı çağırışı həyata keçirmir və dinamik sorğularla işləyən ön panel yenə də statik olanı göstərməyə bilər. Sorğunun hansı tərəfin başlatdığını oxumaq onları ayırd etməyin ən sürətli yoludur.

Nəzarətsiz işləmə elə budur ki, bu, interfeys sualı deyil, dizayn sualına çevrilir. Yadda saxlanmış kod davamlı yükləmə etimadnaməsi deyil və saatlar sonra yenidən qoşulma təzə daxiletmə tələb edəcək, məgər quraşdırma operatorun qəsdən aktivləşdirdiyi token düzümünü dəstəkləmirsə.

Uğuru və uğursuzluğu sınayın, təkcə dialoqu deyil

Testin hər iki yarısını keçirin. Düzgün etimadnamələr etibarlı cavabla keçməlidir; düzgün etimadnamələr qəsdən səhv cavabla rədd edilməlidir. Əgər hər ikisi keçirsə, müştəri heç nənin yoxlamadığı daxiletməni toplayır və dialoq nəzarət vasitəsi ilə səhv salınıb. Bu tək test istənilən profil nəzərdən keçirməsindən daha çox quraşdırmanı tutur.

Sonra yenidən qoşulmadan sonra, qeydiyyatdan keçməmiş hesabla və istifadəçilərinizin həqiqətən işlətdiyi müştəri ilə bağlantını təkrarlayın. Sorğunun görünməsi müştəri davranışıdır; səhv kodun rədd edilməsi isə serverin nəyisə tətbiq etməsidir.