Ikki serverda bitta VPN hisobi: holatning uchta reyestri

Ikki VPN tugunidan birortasiga kira oladigan bitta hisob dasturiy savol bo‘lishidan ancha oldin dizayn savolini ko‘taradi. Hisob ko‘rinishi, har bir tugun egalik qiladigan tarmoq va ulangan mijoz ushlab turgan seans holatning uch xil turi bo‘lib, ularni u yerdan bu yerga nusxalaganingizda turlicha ishdan chiqadi. Uchtasini ham bitta tizimga nusxalash ulardan birini yo‘qotishning keng tarqalgan usuli.

Quyidagi uchta reyestrni tartib bilan ko‘rib chiqing. Har biri nima vakolatli, nima mahalliy va ikkinchi tugun yo‘q bo‘lganda nima bo‘lishini so‘raydi, javoblar esa bir-biridan kelib chiqmaydi.

Kim ulanishi mumkin: bitta vakolat, ko‘p tugun

Qabul reyestridan boshlang: qaysi identifikatsiya manbasi vakolatli, qaysi sertifikat beruvchilarga ishoniladi, qaysi hisoblar mos, qaysi ikkinchi omil qo‘llanadi va har bir hisob qayerga yetadi. So‘ng har bir tugun o‘zgarishlarni qanday va qanchalik tez bilishini yozib qo‘ying.

Umumiy ma’lumotlar bazasi bu javobning mumkin bo‘lgan tarkibiy qismidir. U har bir tegishli siyosat o‘sha yerda yashaydi yoki har bir tugun o‘zgarishni bir paytda qo‘llaydi degan isbot emas. A tugunida o‘chirilgan, ammo B tugunida hali qabul qilinayotgan hisob chiqish jarayoni tugamaganini bildiradi.

Vakolatga yetib bo‘lmaganda tugun nima qilishini hal qiling. Uzilish paytida keshlangan hisob ma’lumotlarini qabul qilish xavfsizlik narxi bo‘lgan siyosat tanlovi, ularni rad etish esa mavjudlik narxi bo‘lgan siyosat tanlovidir. Ikkalasi ham himoyalanadi; hujjatsiz qoldirish esa yo‘q.

Beruvchining vakolatini hisob ma’lumotlaridan alohida saqlang. Bir nechta shlyuz imzo kalitini ushlamasdan ham bir xil CA ga ishonishi mumkin, va har bir tugunga hali ham o‘z server sertifikati va o‘z mijoz tomonidagi ishonch munosabati kerak.

Tugun nimaga egalik qiladi: manzillar va marshrutlar

Ikkinchi reyestr har bir tugun uchun mahalliy: tinglash manzili, server identifikatsiyasi, manzillar hovuzi, xususiy resurslarga marshrutlar, hal qiluvchi siyosati va trafik internetga qanday chiqadi. Bir xil hisobni ikkala tugun ham xizmat qilishi mumkin, bu obyektlar esa alohida qoladi.

Qaytish yo‘li unutiladigan qismdir. Agar ikkala tugun bir hovuzdan manzillar bersa, xususiy tarmoq berilgan mijoz qaysi tugunga tegishli ekanini ayta olmaydi va javob noto‘g‘ri joyga ketishi mumkin. Turli hovuzlarga ham marshrutlar va ruxsatlar kerak, shuning uchun alohida raqamlar diapazoni to‘liq dizayn emas.

Mijozlarni ataylab bitta tugunga yo‘naltiring. DNS tanlovi, mijozning oxirgi nuqtalari ro‘yxatlari va frontend xizmati har xil salomatlik va nosozlikda almashtirish xatti-harakatiga ega turli mexanizmlardir. Bittasini tanlash yaxshi; «yuklamani muvozanatlash»ni dizayn deb hisoblash qaytish yo‘li va nosozlik xatti-harakatini aniqlanmagan qoldiradi.

Hujjatlashtirilgan mahsulot misoli bu yerda yordam beradi. Pritunl replikatsiya hujjatlari VPN tarmog‘ini har bir nusxa uchun obyekt deb qaraydi, turli nusxalardagi mijozlar bir-biriga yetib borish uchun qo‘shimcha marshrutlar va ulanishga muhtoj. Bu mahsulotga xos tartib, Community OpenVPN uchun retsept emas, lekin nusxa qo‘shish nafaqat hisob omborini, balki tarmoqni ham o‘zgartirishini ko‘rsatadi.

Seans nima: satr emas, jonli holat

Uchinchi reyestr jonli seansdir. Ulangan mijoz uni qabul qilgan tugunda protokol holati va tarmoq taqsimotiga ega. Hisobning boshqa tugunda ma’lum bo‘lishi bu tugunga seans, kalitlar yoki paketlarni davom ettirish qobiliyatini bermaydi.

Tugun ishdan chiqqanda nima bo‘lishini aniq ayting. Qo‘llab-quvvatlanadigan natija boshqa tugunga yangi autentifikatsiya va yangi manzil bilan qayta ulanish bo‘lishi mumkin, so‘ng ilova o‘zicha tiklanadi. Agar uzluksiz uzatish talab qilinsa, bu talab aniq amalga oshirish yordamini talab qiladi, ma’lumotlar bazasi replikatsiyasidan chiqarilgan xulosa emas. Javobni navbatchi injener topa oladigan joyga yozing.

Sig‘im qoidalari ham xuddi shunday yondashuvni talab qiladi. Hisobga ikki bir vaqtda seans chegarasi tugunlar orasida faqat biron vakolat band qilingan joylar haqida muvofiqlashtirilgan ko‘rinishga ega bo‘lsa amalga oshiriladi. Tugunga mahalliy ro‘yxatlar va tarixiy hisob yozuvi bu ko‘rinishga qo‘shilmaydi.

Uch reyestrni sinab ko‘rish

Har birini alohida sinab ko‘ring. A tuguni orqali kiring, so‘ng B tuguni orqali, va ikkalasi ham kutilgan manzil diapazonlari bilan muvaffaqiyatli bo‘lishini tasdiqlang. Bitta identifikatsiyani qaytarib oling va ikkala tugunni tekshiring, faqat tasodifan sinaganini emas. So‘ng bitta tugunni to‘xtatib, mijoz va xususiy ilova aslida nima qilishini kuzating.

Qabul sinoviga qaytish yo‘lini ham qo‘shing. B ga ulanadigan, ammo A orqasidagi resursdan javob ololmaydigan mijoz qabul tekshiruvidan o‘tib, tarmoq tekshiruvida yiqildi, va bu farq hisobotda ko‘rinishi kerak.

Ko‘p tugunli hisob dizayni faqat uchta reyestrning aniq egasi, o‘zgarish yo‘li va nosozlik xatti-harakati bo‘lganda to‘liq bo‘ladi. Konfiguratsiya faylini tugunlar orasida nusxalash bu savollarning birortasiga ham javob bermaydi.