Niyə .ovpn faylını redaktə etmək serverdə MFA-nı işə sala bilməz

Profilə auth-user-pass əlavə edirsiniz, yenidən qoşulursunuz və müştəri istifadəçi adı ilə parol soruşur. Görünür MFA işə düşüb. Sonra yanlış hesabdan kod, ya da on dəqiqə əvvəl vaxtı bitmiş kod daxil edirsiniz, tunel yenə qalxır. Simptom budur: müştəri dəyişdi, server dəyişmədi. Birdəfəlik parol yalnız o zaman amil sayılır ki, serverdəki yoxlayıcı onun iddia edən identiklik üçün etibarlı olub-olmadığını həll etsin.

Sorğu yalnız müştərinin soruşduğunu sübut edir, başqa heç nə

.ovpn faylı müştəri tərəfindəki sənəddir. O, müştəriyə etimadnamələri istəməyi, onları keşləməyi və ya keşləməyi dayandırmağı deyə bilər. İstifadəçini qeydiyyata ala, PAM modulu qura və ya serverin hazırda yoxlamadığı ikinci amili tələb etməsinə səbəb ola bilməz.

Telefona autentifikasiya tətbiqi quraşdırmaq da o əlaqəni yaratmır. Google Authenticator PAM layihəsi OTP yoxlama komponentidir və OpenVPN arxasında dayana bilər; o, Google hesabı ilə girişi idxal edilmiş profilə bağlamağın yolu deyil.

Qeydiyyat profilin edə bilmədiyi hissədir

TOTP autentifikasiya tətbiqi ilə onun yoxlayıcısı arasında paylaşılan qeydiyyat materialı tələb edir. Telefondakı altı rəqəm çıxışdır; onların arxasındakı toxum isə sirdir və bir identikliyə aiddir.

Yəni operator düzgün toxumu düzgün VPN identikliyinə bağlayan qeydiyyat prosesinə, üstəgəl itirilmiş telefon üçün təsdiqlənmiş əvəzetmə yolu-una ehtiyac duyur. İstifadəçilərə öz adlarını daşıyan fayl yükləməyə icazə vermək qeydiyyatı hesab ələ keçirmə imkanına çevirir və yükləməni şifrələmək bunu dəyişmir.

PAM əsaslı dizayn hər VPN istifadəçisi üçün ayrıca Unix hesabı yaratmalı deyil. Modul sənədləri alternativ sir yollarını və fayl girişi üçün ayrılmış hesabı dəstəkləyir; bu, yoxlanılan giriş identikliyi deyil, fayl sistemi identikliyidir.

Ümumi səhv bir istifadəçi nümunəsindən köçürülmüş, bir istifadəçi adı ilə bitən sabit sir yoludur. Bu, bir identikliyin nümayişidir, istifadəçi üzrə axtarış deyil və onu hər sorğu üçün istifadə etmək heç kimə müstəqil qeydiyyata alınmış autentifikasiya tətbiqi vermir. İdentiklik xəritəsini yazın, toxum fayllarını qoruyun və parol, sertifikat və hesab yoxlamalarını eyni autentifikasiya yığınında saxlayın.

PAM yığınını həqiqətən nə tələb olunduğu üçün oxuyun

account required pam_permit.so kimi bir sətir hesab uyğunluğunu həyata keçirmir və amil əlavə etmir. O, həmin PAM hesab idarəetmə mərhələsinə icazə verir; bu, istifadəçiləriniz haqqında deyil, mərhələ haqqında bir ifadədir.

Eyni şey mülayim qeydiyyat seçimlərinə də aiddir. Qeydiyyata alınmış sirri olmayan istifadəçiləri qəbul etmək qəsdən seçilmiş yayım qərarı ola bilər, lakin bu, MFA-nın məcburi olduğuna sübut deyil və son tarixi olan müvəqqəti istisna kimi yazılmalıdır.

Müştərinin qarşılıqlı əlaqəsini serverin dizaynına uyğunlaşdırın

auth-user-pass

Bu direktiv istifadəçi adı və parol daxiletməsini tələb edir. O, PAM-ı konfiqurasiya etmir, qeydiyyat qeydi yaratmır və serverə parol sahəsində TOTP dəyərinin olduğunu demir. Server inteqrasiyası və müştəri yerləşdirmənin həqiqətən dəstəklədiyi qarşılıqlı əlaqə barədə razılaşmalıdır: çağırış, sənədləşdirilmiş birləşmiş etimadnamə formatı və ya məhsula xas axın.

Yalnız müştəri bir sahə göstərdiyi üçün parola kod əlavə etməyin. Bu, yalnız serverin plagini məhz həmin formatı gözlədiyi yerdə işləyir və hər yerdə qarışıq şəkildə uğursuz olur.

Toxumları və QR materialını paylaşılan profillərdən və gündəlik diaqnostik jurnallardan uzaq saxlayın. Doğrulanmış giriş kanalı ilə təqdim edilən kod, nəzarətli qeydiyyat zamanı verilən toxumla eyni obyekt deyil və onları dəstək bileti içində qarışdırmaq sirlərin qaçdığı yoldur.

Yenidən qoşulmalar, tokenlər və məsələni həll edən sınaq

İlk uğurlu girişdən sonra nə olacağını planlaşdırın. Əvvəl qəbul edilmiş kod növbəti autentifikasiyada vaxtı keçmiş və ya təkrar kimi rədd edilə bilər. auth-nocache etimadnamələrin saxlanmasını idarə edir və MFA quraşdırmır, reneg-sec 0 isə forum mövzularında nə qədər tez-tez görünsə də, TOTP dəstəyinin tərifi deyil.

Bəzi yerləşdirmələr ilkin yoxlamadan sonra autentifikasiya tokenləri verir ki, yenidən qoşulmalar təkrar soruşmasın. Bu, öz etibarlılıq pəncərəsi və ləğvetmə hekayəsi olan dizayn qərarıdır, miras aldığınız standart deyil.

Sonra qəbul siyasətini insanların həqiqətən istifadə etdiyi müştəri ilə sınayın. Düzgün parolu, sertifikatı və cari kodu olan qeydiyyatlı istifadəçi qoşulmalıdır. Yanlış kod, qeydiyyatı olmayan istifadəçi və qadağan edilmiş hesab hər biri uğursuz olmalı və səbəb server jurnalında görünməlidir. O rəddləri görməyincə, sizdə siyasət deyil, sorğu var.