OpenVPN auth-user-pass-verify skripti: chiqish kodini to'g'ri qo'ying

OpenVPN kirish skriptining aynan bitta chiqishiga asoslanadi: chiqish holatiga. Skript qiladigan qolgan hamma narsa bezak. Hook to'g'ri verifikatorga yetib borishi, javobni tahlil qilishi va do'stona satr chiqarishi mumkin, lekin muallif niyat qilgan narsaning teskarisini bildiruvchi holat qaytaradi. Avval shartnomani o'qing va adapterni uning atrofida yozing, shunda bu xatolar sinfi butunlay yo'qoladi.

Shartnoma kichik: yuborilgan hisobni aniqlang, tasdiqlangan verifikatordan ko'zlangan savolni so'rang va o'sha so'rov uchun faqat o'sha verifikatorning hujjatlashtirilgan ijobiy natijasini qabul qiling. Qolgan hamma narsa infratuzilma.

Hook qaytarishi mumkin bo'lgan uchta holat

auth-user-pass-verify uchun OpenVPN 2.6 qo'llanmasi chiqish kodi 0 ni qabul, 1 ni rad va 2 ni kechiktirilgan autentifikatsiya sifatida belgilaydi. Server tushunadigan yagona uchta javob shu, va har birining ulanishga ta'siri boshqacha. Oxirgi buyrug'ining holati bilan chiqadigan skript aslida log chaqiruvi yoki tozalash bosqichiga ovoz berish imkonini bergan. Holatni har bir shoxobchada aniq yozing, verifikatorga hech qachon yetib bormagan shoxobchalar ham.

HTTP muvaffaqiyati va autentifikatsiya muvaffaqiyati alohida qatlamlar, va ularni aralashtirish bu hookning xato bo'lishining eng keng tarqalgan yo'li. 202 javobi so'rov qayta ishlash uchun qabul qilinganini bildiradi, parol tasdiqlanganini emas. Kutilgan holat, javob shakli va yakuniy hukmni sizga berilgan API shartnomasidan aniqlang va ishonarli ko'ringani uchun maydon nomini o'ylab topmang.

Agar javob haqiqatan keyinroq kelsa, bu kechiktirilgan yo'l va uni shunday qurish kerak. Hech qachon tugamaydigan kechiktirilgan urinish resurslarni muddat tugaguncha ushlab turadi.

Hisob ma'lumotlari faylini yozilganidek o'qing

Hujjatlashtirilgan fayl orqali usulda server foydalanuvchi nomi va parolni vaqtinchalik faylning birinchi ikki qatori sifatida yozadi, o'sha yo'lni skriptga beradi va skript qaytganda faylni o'chiradi. O'sha ikki qatorni ma'lumot sifatida o'qing: faylni hech qachon source qilmang, hech qachon baholamang va uning mazmunini jarayon jadvali ko'radigan buyruq satriga hech qachon qo'ymang. Parolni bayt-bayt saqlang, chunki foydalanuvchi nomini normallashtirganday uni normallashtirish hisob ma'lumotlarini jimgina o'zgartiradi. O'sha vaqtinchalik fayl uchun katalog joylashtirish qarori, shuning uchun u mavjudligini va xostdagilar hammasi o'qiy olmasligini tasdiqlang.

Verifikatorning o'z hisob ma'lumotlarini foydalanuvchidan alohida saqlang: ular shlyuz integratsiyasiga tegishli, platformaning sir omborida yashaydi va faqat tekshirish ruxsatini talab qiladi, shuning uchun ma'lum bir shaxs autentifikatsiya qilinganiga dalil emas. Hook ikkinchi parol verifikatoriga aylanishiga ham yo'l qo'ymang. Xesh taqqoslashni qo'lda qayta yozish tsiklni optimallashtirish bilan xavfsiz bo'lmaydi, va xizmat ko'rsatilayotgan verifikator hisoblar omborining tuzli va qimmat sxemasini allaqachon tushunadi.

Tasniflab bo'lmaydigan javob nimani anglatishini hal qiling

Muddatlar, transport xatolari, buzilgan javoblar va mavjud bo'lmagan backend bitta xususiyatni bo'lishadi: ularning hech biri ijobiy tekshirish emas. Hook ularning har biri uchun yopiq holda muvaffaqiyatsiz bo'lishi va operator chora ko'ra oladigan sababni qayd etishi kerak. Bu sabab himoyalangan logga tegishli, ulanishga urinayotgan odamga qaytariladigan xabarga emas.

Verifikatorga umuman yetib bormaydigan yo'llarga ham shunchalik ehtiyot bo'ling. Yo'qolgan konfiguratsiya qiymati, o'qilmaydigan sir yoki o'rnatilmagan bog'liqlik tasodifiy qabul o'rniga alohida operatsion belgili rad javobini berishi kerak. Bu shoxobchalarni laboratoriyada bog'liqlikni olib tashlab sinab ko'ring, ular haqida o'ylash o'rniga. Log yozishdagi xato chiqish holatini o'zgartirishi mumkin bo'lgan joyda, log yozish qarorning bir qismiga aylangan va uni zararsiz qilish kerak.

Server konfiguratsiyasi bu yerda ham muhim: foydalanuvchi belgilagan skriptlar faqat joriy konfiguratsiya ularni talab qilingan xavfsizlik darajasida ruxsat berganida hisobga olinadi, va bu sozlama ko'tariladigan standart emas, ongli tanlov.

Hukmni tekshiring, chop etilgan satrni emas

Chiqish holatini bevosita tekshiradigan test quring. Namuna hisob ma'lumotlari faylini yozing, hookni ma'lum yaxshi va ma'lum yomon hisob bilan unga qarshi ishga tushiring va skript chop etadigan matnni emas, qobiq bildiradigan holatni o'qing. O'sha bitta tekshiruv mijoz ulanishidan oldin shartnoma xatolarining ko'pini ushlaydi.

Keyin o'sha holatlarni haqiqiy mijoz orqali ishlab chiqarishdan tashqari tinglovchiga qarshi ishga tushiring va server nima qayd etganini tasdiqlang: qabul qilindi, rad etildi yoki kechiktirildi. O'chirilgan hisob, noto'g'ri parol, buzilgan verifikator javobi, muddat va yetib bo'lmaydigan verifikatorni qamrab oling. Agar biron holat siz nomlay olmaydigan holatga tushsa, adapter tugamagan.

verifikator natijasidan chiqish holatiga bog'lanishni repozitoriyda skript yonida saqlang, keyingi muhandis kodni teskari muhandislik qilmasdan shartnomani o'qiy olishi uchun.