Access Server'dan OpenVPN Community'ga: nimani qayta qurish kerak

Access Server va OpenVPN Community bir xil protokolda gaplashadi, qolgan deyarli hech narsada esa bir xil emas. Handshake, shifrlash kelishuvi va tunnel ma'lumot tekisligi mos keladi, shuning uchun mijoz ko'pincha profilini o'zgartirmasdan ikkalasiga ham ulanishi mumkin. Farq shundaki, konfiguratsiya kimga tegishli: bir mahsulot siyosatni yozadigan va majburlaydigan boshqaruv qatlamini beradi, ikkinchisi esa sizga konfiguratsiya fayli va bir to'plam bog'lanish nuqtalarini berib, qarorni o'zingiz qabul qilishingizni kutadi.

Ana shu farq — migratsiya rejasi. Eski mahsulot sizning nomingizdan qabul qilgan har qanday qaror yangi joylashuvda aniq bir qarorga aylanishi kerak.

Ikki joylashuv qayerda almashtiriladigan bo'lishdan to'xtaydi

Access Server'da veb-boshqaruv interfeysi foydalanuvchilar, guruhlar, har bir foydalanuvchi uchun ruxsatlar, sertifikat berish va odam yuklab oladigan profil to'plamiga egalik qiladi. Uning ostidagi daemon shu qatlam tomonidan sozlanadi, shuning uchun ishlab turgan xizmat siz kamdan-kam qo'lda tahrirlaydigan saqlangan holat mahsulotidir. OpenVPN Community'da konfiguratsiya fayli — bu holatning o'zi: u tinglovchini, sertifikat markazini, autentifikatsiya bog'lanish nuqtasini va har bir uzatiladigan parametrni nomlaydi va hech narsa uni siz uchun qayta yozmaydi. Shunday qilib bir xil TLS mexanizmi ikki butunlay boshqacha egalik modeli ostida turadi.

Qisqa xarita bu tafovutni konkret qiladi. Foydalanuvchilar va guruhlar faqat eski ma'lumotlar bazasida mavjud bo'lib, ularni qayta yaratmaguningizcha shunday qoladi. Profil to'plamlari konfiguratsiya fayli va o'zingiz tarqatadigan sertifikatlarga aylanadi. Har bir foydalanuvchi uchun ruxsatlar client-config-dir ichidagi direktivalarga aylanadi. Boshqaruv interfeysi esa sertifikat berish va fayllarni tahrirlash uchun tanlagan jarayoningizga aylanadi.

Bu xaritani serverga tegishdan oldin yozib qo'ying. To'ldira olmaydigan har bir qator — siz yo'qotish arafasida turgan funksiya, va uni indamay yo'qotish migratsiyani ikki haftadan keyin uzilishga aylantirishning yo'lidir.

Identifikatsiya sertifikat fayllari bilan birga o'tmaydi

Eski markazdan olingan sertifikatlar yangi xizmatda to'g'ri tahlil qilinishi mumkin, ammo baribir noto'g'ri identifikatsiya bo'lib qoladi, chunki eski mahsulot ularni yangisi ko'rmaydigan hisob holati bilan bog'lagan edi. Avval yangi joylashuv faqat sertifikat bilanmi, PAM yoki RADIUS'ga yetadigan plagin bilanmi yoki ikkalasining kombinatsiyasi bilanmi autentifikatsiya qilishini hal qiling, so'ng har bir variant kerakli xususiyatlarni saqlab qolishini tekshiring. Har bir foydalanuvchi identifikatsiyasisiz umumiy sertifikat — uni ushlab turgan har kim uchun bitta hisob ma'lumoti. Bekor qilish ham birinchi kundan ishlashi kerak, bu OpenVPN Community'da crl-verify orqali havola qilinadigan CRL fayli va uni qayta yaratadigan jarayonni anglatadi.

Ro'yxatga olishni o'tishdan oldin rejalashtiring, keyin emas. Yangi sertifikatlar, sinovdan o'tgan bekor qilish yo'li va bir kishini o'chirishning hujjatlashtirilgan usuli — bular keyingi ish emas, zaruriy shartlar. Agar ko'p faktorli autentifikatsiya eski mahsulot integratsiyasidan kelgan bo'lsa, o'rnini bosuvchini aniq ayting, chunki o'rnatilmagan plagin eng yomon paytda yopiq holatda ishlamay qoladi.

Marshrutlash va nomlarni hal qilish konfiguratsiyani yozuvchiga ergashadi

Marshrutlar, DNS sozlamalari va to'liq tunnel xatti-harakati ikkala mahsulotda ham uzatiladigan parametrlardir, ammo faqat bittasi ularni siz uchun hisoblaydi. OpenVPN Community'da siz push direktivalarini o'zingiz yozasiz, redirect-gateway serverga yoki mijozga tegishli ekanini o'zingiz hal qilasiz va xostda forwarding hamda NAT borligini tasdiqlaysiz. Tugallangan handshake sizga forwarding, manzil tarjimasi yoki mijoz haqiqatda olgan marshrutlar haqida hech narsa aytmaydi.

Har bir mijoz xatti-harakati uchun client-config-dir va mijoz sertifikatining umumiy nomi bilan atalgan fayl kerak, saytdan saytga peer uchun esa uning orqasidagi prefikslar uchun iroute yozuvlari kerak. Nomni noto'g'ri qo'ysangiz, parametrlar xatosiz e'tiborsiz qoldiriladi. O'z manzillar hovuzidagi bitta ishlab chiqarishdan tashqari mijoz bilan sinab ko'ring, so'ng unga tayinlangan manzilni, berilgan marshrutlarni va u bilan qolgan resolver sozlamalarini o'qing.

O'tishni eski xizmat qaytishi mumkin bo'ladigan tartibda bajaring

Yangi tinglovchini boshqa port yoki manzilda ishga tushiring va o'rinbosarni isbotlaguningizcha eskisini trafik xizmatida ushlab turing. Bitta soketda ikkita daemon — bu orqaga qaytish rejasi emas.

Bir vaqtda bitta guruhni ko'chiring, uning o'z sertifikatlari, o'z hovuzi va o'z marshrutlari bilan, va qaytish yo'lini hodisa paytida kashf qilish o'rniga oldindan mashq qiling. Faqat yangi xizmat to'xtatilgandagina ishlaydigan qaytish ham qaytishdir, lekin u hech narsa yonmayotgan paytda sinovdan o'tishi kerak.

Nihoyat, to'g'ridan-to'g'ri ekvivalenti bo'lmagan funksiyalarni sanab chiqing va har birining taqdirini yozma hal qiling: o'z-o'ziga xizmat ko'rsatadigan profil yuklab olish, har bir foydalanuvchi uchun ruxsat bayroqlari, boshqaruv interfeysining o'zi, jonli ulanish hisoboti. Ularni hujjatlashtirilgan qo'lda jarayon bilan almashtirish — bu qonuniy javob. Qatorni bo'sh qoldirish esa unday emas.

Ish tugallangan hisoblanadi, qachonki eski portalni hech qachon ko'rmagan foydalanuvchi ro'yxatdan o'ta olsa, ulana olsa, kerakli ichki manzilga yeta olsa va toza bekor qilina olsa. Shu nuqtagacha bo'lgan hamma narsa — tayyorgarlik.