Siz sertifikat va kalit satrlarini o'chirasiz, profilni topshirasiz, lekin ulanish hali ham sertifikat xatosi bilan muvaffaqiyatsiz tugaydi. Profil hech qachon bu talabni amalga oshiruvchi narsa bo'lmagan. Mijoz sertifikati majburiy yoki yo'qligini server hal qiladi va mijoz tomonidagi hech qanday o'zgartirish buni muzokara bilan bekor qilmaydi. Shuning uchun tuzatish — server siyosatini ataylab o'zgartirish va unga bog'liq bo'lgan hamma narsa shu bosqichda yangilanadi.

Profil siyosat emas

Community OpenVPN 2.6 mijoz sertifikatlarini majburiy holda olib keladi, chunki verify-client-cert sukut bo'yicha require ga teng. Uni none ga o'rnatish sertifikat talabini to'xtatadi va mijoz autentifikatsiyasini server allaqachon ishlatayotgan foydalanuvchi nomi va parol tartibiga topshiradi. Eski qo'llanmalar xuddi shu g'oyaning eskirgan yozilishi bo'lgan client-cert-not-required ga murojaat qiladi, shuning uchun o'rnatilgan versiyangiz hujjatlashtiradigan direktivadan foydalaning. Qanday bo'lmasin, o'zgarish serverda sodir bo'ladi va hech bir mijoz profili buni amalga oshira olmaydi.

Quyidagi fragment server tomonidagi butun o'zgarish bo'lib, o'zi ishlaydigan autentifikatsiya konfiguratsiyasi emas. verify-client-cert none sertifikat talabini olib tashlaydi, username-as-common-name esa hisob nomini keyingi qayta chaqiruvlar va har bir mijozning fayllari ko'radigan identifikatsiyaga aylantiradi. Hech bir satr parolni tekshirmaydi, shuning uchun tekshiruvchi hali ham mavjud bo'lishi kerak.

verify-client-cert none
username-as-common-name

Bu tekshiruvchi auth-user-pass-verify tomonidan boshqariladigan plagin yoki skript bo'lib, yuqoridagi satrlardan biri mazmunga ega bo'lishidan oldin u o'z joyida bo'lishi shart. Tartibni teskari aylantirish sizga server sertifikat talab qilmaydigan va hisobni tekshirmaydigan oyna beradi.

Serverni hali ham nima tekshiradi

Mijoz sertifikatidan voz kechish TLS dan voz kechish emas. Server o'z sertifikati va kalitini saqlaydi, mijoz esa CA ishonchi va uni soxtakor bilan gaplashishdan to'xtatadigan xost nomi tekshiruvlarini saqlaydi. Mijozda endi sertifikat yo'qligi sababli remote-cert-tls server yoki CA to'plamini olib tashlash keng tarqalgan va jiddiy noto'g'ri o'qish bo'lib, 2.6 havolasi ikki yo'nalish mustaqil ekanligini aniq aytadi. Biri serverni mijozga isbotlaydi; ikkinchisi mijozni serverga.

Profil tls-auth yoki tls-crypt blokini ham olib yurishi mumkin. Bu o'zining tarqatish va aylantirish tsikliga ega umumiy boshqaruv kanali kaliti, shuning uchun sertifikat yoki kalit satrlarisiz fayl avtomatik ravishda nashr qilish uchun xavfsiz emas. Uni o'qib bo'lmaguncha sir sifatida tuting.

Ishlaydigan profildan ko'chirilgan sertifikat fayli o'z-o'zidan hech narsani isbotlamaydi; egalik unga mos keladigan maxfiy kalitni saqlashni anglatadi, buni sertifikat bilan autentifikatsiya qilingan joylashtirish tekshiradi. Sertifikatni o'z ichiga olgan fayl u bilan autentifikatsiya qilish mumkin bo'lgan fayl emas.

Tekshiruvchi nima qilishi kerak

Sertifikat talabi olib tashlangach, hamma narsa tekshiruvchiga tayanadi: plagin yoki auth-user-pass-verify tomonidan boshqariladigan skript. U yaroqsiz hisob ma'lumotlarini rad etishi, o'chirilgan yoki yaroqsiz hisoblarni rad etishi va backend'iga yetib bora olmasa yopiq holda muvaffaqiyatsiz bo'lishi kerak. username-as-common-name ko'pincha yonida yoqiladi va keyingi qayta chaqiruvlar hamda har bir mijozning konfiguratsiya fayllari ko'radigan identifikatsiyani o'zgartiradi. U parolni tekshirmaydi va yaroqsiz hisobni yaroqli qilmaydi. Bular alohida ishlar va ularni aralashtirish — migratsiyaning baxtli yo'l sinovidan o'tib, birinchi haqiqiy hodisasida muvaffaqiyatsiz bo'lish yo'li.

Salbiy holatlarni ijobiy holat kabi sinchkovlik bilan sinab ko'ring. Parol so'rovini ko'rsatuvchi profil faqat mijoz so'rov chizishini isbotlaydi, noto'g'ri parolni qabul qiladigan server esa ancha yomonroq narsani isbotlaydi. Sinov to'plamiga faqat yomon parol emas, o'chirilgan hisob va muddati o'tgan hisob ma'lumotlarini ham qo'shing.

Siyosat, profil va xaritalashni birga o'zgartiring

Uchta narsani muvofiqlashtiring: server direktivasi, mijoz profili va har bir mijoz identifikatsiyasini xaritalash. Ularni alohida o'zgartirsangiz, mijozlar tekshiruvdan oldin muvaffaqiyatsiz bo'ladi yoki administrator kutmagan nom bilan ulanadi, bu esa yomonroq, chunki muvaffaqiyatga o'xshaydi. Noto'g'ri identifikatsiya ostida muvaffaqiyatli ulanishni muvaffaqiyatsizdan ko'ra sezish qiyinroq.

Bu yo'l uchun ikkita sinov hisobini saqlang, biri haqiqiy va biri ma'lum yomon, va tekshiruvchidagi har qanday o'zgarishdan keyin ikkalasini ishlating. Haqiqiy hisob baxtli yo'lni va identifikatsiya xaritalashini isbotlaydi; yomon hisob rad etish hali ishlayotganini isbotlaydi. Hech bir sinov sizga yaroqlilik qoidalari haqida hech narsa aytmaydi, shuning uchun joylashtirishda bunday qoidalar bo'lsa, siyosiy sabablarga ko'ra rad etilishi kerak bo'lgan hisobni qo'shing. Har o'zgarishdan keyin uchtasini ham ishga tushiring, chunki hamma narsani qabul qila boshlagan tekshiruvchi ishlaydigan kirishga aynan o'xshaydi.

Server aslida qaysi autentifikatsiya usullarini qabul qilishini yozib qo'ying, profil taklif qiladiganlarini emas. Bu yozuv odamlar doim so'raydigan savolga javob beradi, ya'ni bu xizmatga kim ulanishi mumkin. U keyingi administratordan ham uzoq yashaydi, u aks holda buni paketlar tutishdan qayta kashf qiladi.

O'xshash maqolalar