Avval EAP usuli: VPN qaysi parol xeshini ishlatishi mumkin
VPN sirning o'zini tekshiradi, veb-xeshni emas. Usulni o'qing, so'ng o'sha parollar ishlashda davom etadi deb va'da berishdan oldin ombor nima saqlashini tekshiring.
Ko'p jamoalarda ishlaydigan veb-kirish va o'sha jadvaldagi har bir parolni rad etuvchi VPN bo'ladi. Veb-ilova o'zi hisoblagan xeshni solishtiradi, tunnel esa mijozdan sirga egalikni server tekshira oladigan tarzda isbotlashni talab qiladi. Bu saqlangan materialga qo'yiladigan turlicha talablardir. Ana shu ikkisi orasidagi bo'shliqda bunday loyihalarning ko'pchiligi to'xtab qoladi.
Avval usul, keyin sxema
Har qanday sxemaga qarashdan oldin tanlangan usul qanday dalil talab qilishini yozib qo'ying. Sinov-javob usuliga server kutilgan javobni hisoblay oladigan material kerak, bu amalda parol yoki mos keladigan hosilaviy shakl demakdir. Parolni himoyalangan tunnel ichida olib yuruvchi usulga tekshiruvchida parolning o'zi kerak. Usul hujjatlarini mijoz sozlamalari uchun emas, tekshiruvchi talabi uchun o'qing, chunki mijoz talablari odatda oson qismdir.
Zamonaviy veb-freymvork yaratgan tuzli xesh ikkalasini ham bermaydi. U bitta aniq taqqoslashni tekshiradi va kelib chiqqan sirga qaytarilmaydi.
Sinov-javob tuzli xeshdan foydalana olmaydi
MSCHAPv2 — sinov-javob almashinuvi, shu sababli server parolni hech qachon olmaydi va saqlangan satrni solishtira olmaydi. Kutilgan javobni o'zida bor materialdan chiqarishi kerak, shuning uchun mos keladigan saqlash shakllari shunchalik tordir. Har bir foydalanuvchi uchun tuzli bcrypt yoki Argon2 qiymati almashinuvni butunlay istisno qiladigan tarzda bir tomonlamadir. Quyidagi jadval usul nomidan emas, saqlash shaklidan boshlanadi, chunki javobni saqlash shakli hal qiladi.
| What the store holds | What that material can verify | What has to change |
|---|---|---|
| A bcrypt or Argon2 value with a per-user salt | nothing challenge-response can use, and not the password either | re-enrol the users, or place a verifying service in front |
| An unsalted NT-hash | MSCHAPv2, and inner PAP through a TLS tunnel | nothing, as long as that store is the verifier |
| A client certificate with a revocation list | EAP-TLS only | move enrolment and revocation to the PKI owner |
strongSwan uchun SQL plaginining hujjatlari sozlash va hisob ma'lumotlari uchun o'z sxemasini belgilaydi va loyiha bu plaginni hanuz eksperimental deb belgilaydi. Unda hech narsa ilovaning foydalanuvchilar jadvaliga moslashmaydi va saqlangan qiymatni qaysi xeshlash sxemasi yaratganini taxmin qilmaydi. Shuning uchun real variantlar shlyuz ishlata oladigan omborga ko'chish yoki mavjud ombor oldida almashinuvni bajara oladigan autentifikatsiya xizmatidir. Qolgan hamma narsa ichida yashirin taxmin bo'lgan bog'lovchidir.
RADIUS ishni ko'chiradi, talabni emas
EAP ni RADIUS serveriga topshirish tekshiruv joyini o'zgartiradi va odatda audit izini yaxshilaydi. U bir tomonlama xeshdan parolni tiklamaydi, shuning uchun autentifikatsiya xizmatiga o'zi tugatadigan usulga mos material hanuz kerak. Jamoalar buni RADIUS yo'lini qurib, narigi uchda o'sha devorga duch kelgandan keyin biladi.
RADIUS serveri mos hisob ma'lumotlari bo'lgan katalogni o'qiy oladigan joyda yechim ishlaydi va VPN shlyuzi sodda qoladi. O'qiy olmaydigan joyda halol javob yana bitta bog'lovchi emas, ro'yxatga olishdagi o'zgarishdir. Ta'minlash va bekor qilish identifikatsiyaga ega bo'lganga tegishli, shuning uchun qo'llab-quvvatlanadigan sinxronlash jarayonisiz ko'chirilgan jadval yagona kirish emas, hisob ma'lumotlarining ikkinchi hayot davridir. Kimdir parolni faqat bitta joyda tiklaganda u birinchi marta siljiydi va bu siljish ikkala tizimda mavjud hisob har birida boshqacha tutmaguncha jim turadi.
Katalogni o'qiyotgan hisobni faqat shu o'qish bilan cheklang va uni shlyuz o'z sozlamasi uchun ishlatadigan hisobdan alohida tuting. Umumiy ma'muriy hisob faqat-o'qish uchun qurilgan yechimni ancha keng ta'sir radiusiga aylantiradi.
Hisob qayerda yashashi kerak
Material masalasi hal bo'lgach, ikkita arxitektura qoladi. Shlyuz faqat o'zi o'qiydigan kichik hisob ma'lumotlari omboriga ega bo'lishi mumkin yoki korporativ katalog oldida turgan autentifikatsiya xizmatiga topshirishi mumkin.
Birinchisini o'ylab ko'rish osonroq va foydalanuvchi uchun yomonroq, chunki unga saqlash uchun ikkinchi parol qoladi. Ikkinchisi bitta identifikatsiyani saqlaydi va endi birov ulanishidan oldin ishlashi kerak bo'lgan xizmatga bog'liqlik qo'shadi. Hech biri xato emas, lekin tanlov shlyuz sozlamasi yonida qayd etilishi kerak, aks holda keyingi injener boshqasi tanlangan deb o'ylaydi. Nima tanlasangiz ham, quyidagi ikkita buyruq o'zgartirishdan oldingi joriy holatni ko'rsatadigan buyruqlardir.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsHisob autentifikatsiyasi vakolatni ham hal qilmaydi. Guruh a'zoligi, qurilma holati va tarmoq ruxsati foydalanuvchi kerakli identifikatsiyani isbotlagandan keyin ham aniq xaritalashni talab qiladi. Mukammal autentifikatsiyadan o'tib hech narsaga ruxsat bermaydigan ulanish siyosat natijasidir, usuldagi nuqson emas.