Birinchi sessiya g‘alaba qozonadi: OpenVPN kirishlarini chiqarib yuborishdan oldin cheklash
Keyingi kirishni rad etish eskisini almashtirish bilan bir xil emas. Qaror bir xil nomdagi chiqarib yuborishdan oldin qabul qilinishi kerak, slot tekshiruvi esa atomik bo‘lishi lozim.
Har bir hisobga bitta sessiya ruxsat beruvchi siyosat ikkinchi kirish kelguncha hal qilingandek ko‘rinadi. Ikki natija mumkin: yangi kelgan joriy sessiyani almashtiradi yoki joriy sessiya slotni saqlab qoladi va yangi kelgan rad etiladi. Faqat ikkinchisi birinchi sessiya g‘alaba qozonadi siyosatidir. Ko‘pchilik murojaat qiladigan klient parametri bir vaqtlilikni yoqadi va shuning uchun bu natijani bermaydi.
Bitta sozlamaning ortida ikkita shartnoma yashiringan
Bir vaqtlilik o‘chirilganda bir xil sertifikat nomini olib kelgan ikkinchi ulanish allaqachon ishlab turgan sessiyani siqib chiqarishi mumkin. Bir vaqtlilikni yoqish bir paytda bir nechta sessiyaga ruxsat beradi, bu esa cheklovning aksidir. Ikkala holat ham rad etish siyosati emas, shuning uchun qaror butunlay boshqa joyda qabul qilinishi kerak.
Biror narsani joriy etishdan oldin shartnomani yozib qo‘ying: kim rad etiladi, qaysi dalil joriy sessiyani aniqlaydi va sessiya toza uzilishsiz o‘lsa nima bo‘ladi. Hech kim bunday ifodalamagan siyosatni keyin tekshirib bo‘lmaydi.
Chiqarib yuborish sizning ulanish ilgagingizdan oldin sodir bo‘ladi
2.6 server kod yo‘lida bir vaqtlilik o‘chirilganda yangi klient uchun erta tayyorgarlik bir xil nomdagi mavjud nusxalarni olib tashlaydi. Bu olib tashlash ulanish ishlovchilari zanjiri ishga tushishidan oldin sodir bo‘ladi. Shuning uchun takrorni payqab xatolik qaytaradigan skript yangi kelganni joriy sessiya allaqachon tashlab yuborilgandan keyin rad etadi - siyosat oldini olmoqchi bo‘lgan natijaning aynan o‘zi. Upstream amalga oshirishidagi qayta chaqiriqlar tartibi sizning build uchun yagona ishonchli javobdir.
| Stage | Who can still refuse | Effect on the incumbent |
|---|---|---|
| Certificate check | Server trust configuration | None |
| Authentication decision | The authentication controller | None, because establishment has not run |
| Connect handler | A profile script | Already evicted in the same-name case |
| Post-establishment | Status tooling, monitoring | Both sessions already exist or one is gone |
Holat faylini so‘rab turish ham darvoza emas. Birga kelgan ikki urinish ikkalasi ham bo‘sh slotni ko‘rishi mumkin, biri tasdiqlashidan oldin, va ikkalasi davom etadi.
Qarorni autentifikatsiyaga ko‘chiring
Sertifikat tekshirilgandan so‘ng boshqaruv interfeysi autentifikatsiya qarorini o‘z zimmasiga olishi mumkin. Bunday tartibda kontroler kuzatuvchi emas: u ulanayotgan har bir klient nusxasini qabul qiladi va bu nusxa davom eta oladimi deb javob beradi. Javob o‘rnatishdan oldin kelgani uchun rad etish joriy sessiyani tegmasdan qoldiradi. Xuddi shu kanal uzilishlar haqida xabar beradi va shu bilan kontroler slot qonuniy bo‘shatilganini biladi.
Har bir yangi nusxa bu darvozadan o‘tishi kerak, qayta ulanishlar va so‘rovsiz qayta autentifikatsiya qiladigan har qanday yo‘l ham. Ba‘zi nusxalar hech qachon yetib bormaydigan darvoza hech narsani himoya qilmaydi va bu o‘tkazib yuborish kimdir aylanib o‘tishni sinab ko‘rmaguncha ko‘rinmay qoladi.
Tokenlar darvoza yonidan o‘tishi mumkin
Token chiqarilgandan so‘ng, server uni ichkarida tekshirib, o‘sha ulanish uchun tashqi autentifikatsiyani o‘tkazib yuborishi mumkin. Boshqaruv chaqiruvi hech qachon sodir bo‘lmaydi, shuning uchun faqat o‘sha yerda joriy etilgan slot tekshiruvi yangi nusxani hech qachon ko‘rmaydi. Bu xatti-harakat foydalanuvchilar uchun qulaylik va bir vaqtlilik siyosati uchun teshikdir. Token bilan autentifikatsiya qilingan ulanishlarni teng vakolatli tekshiruvdan o‘tkazing yoki siyosat har bir ulanishda qaror talab qilsa, token yo‘lini o‘chiring.
Buni har bir tokenni shartsiz qabul qilish bilan qoplamang. Muddati o‘tgan yoki noto‘g‘ri token baribir muvaffaqiyatsiz bo‘lishi kerak va u boshqa hamma narsa kabi o‘sha qaror nuqtasi orqali muvaffaqiyatsiz bo‘lishi kerak.
Bronni nusxaga bog‘lang, manzilga emas
Manzil zaif identifikatsiya: o‘sha noutbukdan qayta ulanish boshqa manzildan kelishi mumkin, nusxalangan hisob ma’lumotlari esa o‘sha manzildan kelishi mumkin. Bronni server tayinlaydigan klient nusxasiga bog‘lang, shunda allaqachon qabul qilingan nusxaning qayta autentifikatsiyasi egasi sifatida taniladi. Yangi nusxa identifikatori o‘sha tokenni taqdim etsa ham birinchi g‘alaba qozonadi qarori orqali o‘z slotini olishi kerak.
Faqat muvaffaqiyatsiz urinishga tegishli bronni bo‘shating. Eski urinishdan kechikkan uzilish hodisasi yangiroq egasining slotini tozalamasligi kerak, shuning uchun bo‘shatish hisobni emas, nusxani nomlaydi. Kontroler qayta ishga tushgandan so‘ng kimnidir qabul qilishdan oldin tirik sessiyalarni moslang va hisobga xizmat qiladigan har bir shlyuzda o‘sha qoidani qo‘llang.
Haqiqatan eskirgan slot qanday tiklanashini alohida hal qiling. Administratorga uni tozalashning hujjatlashtirilgan usuli kerak va bu yo‘l faqat qayta ulanish tugmasini bosadigan foydalanuvchi uchun ochiq bo‘lmasligi kerak.
Muhim juftlarni sinab ko‘ring: deyarli bir vaqtda ikki kirish, toza uzilishdan keyingi qayta ulanish, joriy sessiyaning qayta autentifikatsiyasi, rad etilgan yangi kelgan va kontrolerning qayta ishga tushishi. Har bir holatda joriy sessiya foydalanishga yaroqli qolishi, yangi kelgan esa boshqa hisoblarga zarar yetkazmasdan rad etilishi kerak.