Nega .ovpn faylini tahrirlash serverda MFAʼni yoqa olmaydi

Profilga auth-user-pass qoʻshasiz, qayta ulanasiz va mijoz foydalanuvchi nomi bilan parolni soʻraydi. MFA yoqilgandek koʻrinadi. Keyin notoʻgʻri hisobdan kod yoki oʻn daqiqa oldin muddati tugagan kod kiritasiz, tunnel baribir koʻtariladi. Bu — alomat: mijoz oʻzgardi, server oʻzgarmadi. Bir martalik parol faqat serverdagi tekshiruvchi uni talab qilayotgan identifikatsiya uchun haqiqiy ekanini hal qilganda omil boʻladi.

Soʻrov faqat mijoz soʻraganini isbotlaydi, ortiqchasini emas

.ovpn fayli — mijoz tomonidagi hujjat. U mijozga hisob maʼlumotlarini soʻrashni, ularni keshga saqlashni yoki buni toʻxtatishni aytishi mumkin. Lekin u foydalanuvchini roʻyxatga ololmaydi, PAM modulini oʻrnatolmaydi yoki serverni hozir tekshirmayotgan ikkinchi omilni talab qilishga majburlay olmaydi.

Telefonga autentifikatsiya ilovasini oʻrnatish ham bu munosabatni yaratmaydi. Google Authenticator PAM loyihasi OTP tekshiruvi komponenti boʻlib, u OpenVPN orqasida turishi mumkin; bu import qilingan profilga Google hisobiga kirishni yopishtirish usuli emas.

Roʻyxatga olish — profil qila olmaydigan qism

TOTP autentifikatsiya ilovasi va uning tekshiruvchisi oʻrtasida boʻlishilgan roʻyxatga olish materialini talab qiladi. Telefondagi olti raqam — chiqish; ularning orqasidagi urugʻ — sir, va u bitta identifikatsiyaga tegishli.

Shuning uchun operatorga toʻgʻri urugʻni toʻgʻri VPN identifikatsiyasiga bogʻlaydigan roʻyxatga olish jarayoni, shuningdek yoʻqolgan telefon uchun tasdiqlangan almashtirish yoʻli kerak. Foydalanuvchilarga oʻz nomidagi faylni yuklashga ruxsat berish roʻyxatga olishni hisobni egallash imkoniyatiga aylantiradi va yuklamani shifrlash buni oʻzgartirmaydi.

PAM asosidagi dizayn har bir VPN foydalanuvchisi uchun alohida Unix hisobi yaratishi shart emas. Modul hujjatlari muqobil sir yoʻllarini va fayllarga kirish uchun maxsus hisobni qoʻllab-quvvatlaydi, bu fayl tizimi identifikatsiyasi, tekshirilayotgan kirish identifikatsiyasi emas.

Odatiy xato — bitta foydalanuvchi misolidan koʻchirilgan, bitta foydalanuvchi nomi bilan tugaydigan qatʼiy sir yoʻli. Bu bitta identifikatsiyaning namoyishi, har bir foydalanuvchi boʻyicha qidiruv emas, va uni har bir soʻrovga qoʻllash hech kimga mustaqil roʻyxatga olingan autentifikatsiya ilovasini bermaydi. Identifikatsiya xaritasini yozing, urugʻ fayllarini himoya qiling va parol, sertifikat hamda hisob tekshiruvlarini bir xil autentifikatsiya stekida saqlang.

PAM stekini oʻqib, aslida nima talab qilinishini koʻring

account required pam_permit.so kabi satr hisobning yaroqliligini amalga oshirmaydi va omil qoʻshmaydi. U PAM hisoblarini boshqarish bosqichiga ruxsat beradi, bu bosqich haqida bayonot, sizning foydalanuvchilaringiz haqida emas.

Xuddi shu narsa yumshoq roʻyxatga olish parametrlariga ham tegishli. Roʻyxatga olingan sirsiz foydalanuvchilarni qabul qilish ataylab qilingan joriy etish qarori boʻlishi mumkin, lekin bu MFA majburiy ekanining isboti emas va uni tugash sanasi bilan vaqtinchalik istisno sifatida yozib qoʻyish kerak.

Mijozning oʻzaro taʼsirini server dizayniga moslang

auth-user-pass

Bu direktiva foydalanuvchi nomi va parolni kiritishni soʻraydi. U PAMʼni sozlamaydi, roʻyxatga olish yozuvini yaratmaydi va serverga parol maydonida TOTP qiymati borligini aytmaydi. Server integratsiyasi va mijoz joriy etish haqiqatan qoʻllab-quvvatlaydigan oʻzaro taʼsir boʻyicha kelishishi kerak: chaqiriq, hujjatlashtirilgan birlashgan hisob maʼlumotlari formati yoki mahsulotga xos oqim.

Mijoz bitta maydonni koʻrsatdi deb parolga kod qoʻshmang. Bu faqat server plaginasi aynan shu formatni kutadigan joyda ishlaydi, boshqa hamma joyda chalkash tarzda muvaffaqiyatsiz boʻladi.

Urugʻlar va QR materialini umumiy profillardan va oddiy diagnostika jurnallaridan uzoqda saqlang. Autentifikatsiyalangan kirish kanali orqali yuborilgan kod boshqariladigan roʻyxatga olish paytida berilgan urugʻ bilan bir xil obyekt emas, va ularni qoʻllab-quvvatlash chiptasida aralashtirish sirlarning chiqib ketish yoʻli.

Qayta ulanishlar, tokenlar va masalani hal qiladigan test

Birinchi muvaffaqiyatli kirishdan keyin nima boʻlishini rejalashtiring. Ilgari qabul qilingan kod keyingi autentifikatsiyada muddati oʻtgan yoki takror sifatida rad etilgan boʻlishi mumkin. auth-nocache hisob maʼlumotlarini saqlashni boshqaradi va MFA oʻrnatmaydi, reneg-sec 0 esa forum mavzularida qanchalik tez-tez uchrasa ham TOTP qoʻllab-quvvatlashining taʼrifi emas.

Baʼzi joriy etishlar dastlabki tekshiruvdan keyin autentifikatsiya tokenlarini chiqaradi, shunda qayta ulanishlar yana soʻramaydi. Bu oʻz amal qilish oynasi va bekor qilish tarixiga ega dizayn qarori, siz meros oladigan standart qiymat emas.

Keyin kirish siyosatini odamlar haqiqatan ishlatadigan mijoz bilan sinab koʻring. Toʻgʻri parol, sertifikat va joriy kodga ega roʻyxatga olingan foydalanuvchi ulanishi kerak. Notoʻgʻri kod, roʻyxatga olinmagan foydalanuvchi va taqiqlangan hisob — har biri muvaffaqiyatsiz boʻlishi kerak, sababi esa server jurnalida koʻrinishi kerak. Oʻsha rad javoblarini koʻrmaguningizcha, sizda soʻrov bor, siyosat emas.