Oylik ma'lumot kvotasi OpenVPN hisobi bo'yicha qayerda bo'lishi kerak

Tunnel har safar qayta ulanganda qayta o'rnatiladigan kvota chegara emas, va barqaror holatni saqlash uchun joy bo'lmagan VPN serveriga bayt hisoblagichi mahkamlansa, aynan shu narsa olinadi. Hisoblagich bitta sessiyaga tegishli; kvota esa shaxsga yoki qurilma shartnomasiga tegishli. Bu xususiyatning barcha qiyinchiligi shu nomuvofiqlikdan kelib chiqadi, shuning uchun quyidagi tekshiruvlar holat qayerda yashashi va qaysi qatlam qaror qabul qilishga haqli ekaniga bag'ishlangan.

Kvotani tunnelga emas, hisobga bog'lang

Kvota sub'ektini nomlashdan boshlang. Bir kishi uchta qurilma sertifikatiga ega bo'lishi mumkin va ularning hech biri faqat alohida autentifikatsiya qilgani uchun mustaqil oylik byudjet olmasligi kerak. Qayta ulanishlarga, yangi tunnel manzillariga va ikkinchi shlyuzga ko'chishga bardosh beradigan barqaror hisob identifikatori kvota foydalanishi mumkin bo'lgan yagona langardir. Sertifikatning umumiy nomi bu kalit sifatida faqat sizning chiqarish siyosatingiz har bir nomga bitta hisob kafolatlaganda ishlaydi.

Tayinlangan tunnel manzili hech qachon javob emas. Manzillar qayta ishlatiladi, hovuzlar umumiy, va bir hisob bir daqiqada ikki shlyuzda ikki marta ko'rinishi mumkin. Agar daftar manzilga tayansa, tankni yana to'ldirish uchun uzilib qayta ulanish kifoya.

Arifmetika tekshiriladigan bo'lishi uchun har bir sessiya bo'yicha yetarlicha yozib oling: hisob, hisob-kitob davri, shlyuz nusxasi, sessiya identifikatori, oxirgi kuzatilgan hisoblagichlar va tasdiqlangan jami. Sessiya identifikatoriga demon ishga tushish avlodini qo'shing, chunki qayta ishga tushirilgan server mijoz IDlarini qayta ishlatadi va sodda moslashtirish oldingi tayanch chizig'ini meros qilib olardi.

Birlik, yo'nalish va qayta o'rnatish chegarasini belgilang

Har qanday yig'ish boshlanishidan oldin to'rtta ta'rif yozma ravishda belgilanishi kerak. Kvota mijoz yuboradigan baytlarni, qabul qiladigan baytlarni yoki ikkalasining yig'indisini sanaydimi? Bir gigabayt 10^9 baytmi yoki 2^30mi? Qaysi mahalliy soatda va qaysi vaqt mintaqasida davr aylanadi? Va hisoblagich aniq nimani o'lchaydi, tunnelning qo'shimcha xarajatlari va qayta uzatishlar kiritilgan, ammo ilova fayli hajmi va provayder hisobi kiritilmagan?

Bu tanlovlarning hech biri xato emas, lekin joriy etish va mijoz ko'radigan raqam mos kelishi kerak. Bir tizimning ikki yarmi GiB yoki mahalliy vaqt o'rniga UTC yarim kechasida sodir bo'ladigan aylanish borasida kelishmasa, butun kvotaga ishonchni susaytiradigan xuddi shunday chipta paydo bo'ladi.

Bayt yig'indilarini bitta undirilgan farqqa aylantiring

Boshqaruv interfeysi mijoz IDsi va har bir yo'nalishdagi jamlangan bayt yig'indilarini olib yuruvchi davriy BYTECOUNT_CLI satrlarini xabar qiladi, bytecount buyrug'i esa ular qanchalik tez-tez kelishini belgilaydi. Server nuqtai nazaridan, olingan raqam mijoz yuborgan baytlarni sanaydi, yuborilgan raqam esa unga yetkazilgan baytlarni sanaydi. Intervalni daftar singdira oladigan qiymatga qo'ying; juda qisqa interval aslida olmaydigan aniqlikni sotib oladi.

Bitta cheklov butun dizaynni shakllantiradi: boshqaruv soketi bitta boshqaruv ulanishini qabul qiladi. Monitoring eksportchisi, GUI va sizning kontrolleriingiz har biri o'z ulanishini ocha olmaydi. Kanal qaysi jarayonga tegishli ekanini hal qiling va qolganlarga undan holat o'qishga ruxsat bering, chunki bu interfeys ma'muriy harakatlar beradi va baribir xostdan tashqarida ochilmasligi kerak.

rx_delta = sample.rx_now - session.prev_rx
tx_delta = sample.tx_now - session.prev_tx
charge  = rx_delta + tx_delta
# same transaction:
ledger.total += charge
session.prev_rx, session.prev_tx = sample.rx_now, sample.tx_now

Yangi tayanch chiziqlar va foydalanish o'sishini birga tasdiqlang, shunda namunani qayta ijro etish ikki marta undirish o'rniga hech narsa undirmaydi. Orqaga harakatlanuvchi hisoblagich signal, qarz emas: bu sessiya almashtirilgani yoki demon qayta ishga tushirilganini bildiradi, va to'g'ri javob salbiy summani kreditlash emas, sessiya identifikatorini kelishtirishdir.

Uzilish yo'li ham xuddi shunday e'tiborni talab qiladi. Agar yakuniy hodisa sessiya oxiridagi yig'indilarni olib yursa, faqat oxirgi tasdiqlangan namunadan farqni undiring. Davriy namuna olish allaqachon undirilgandan keyin to'liq yig'indini qo'shish uy sharoitida yasalgan kvota tizimlarida eng keng tarqalgan ikki marta hisoblashdir. Davr chegarasini kesib o'tadigan sessiyalar ham qoidaga muhtoj, chunki bitta yakuniy yig'indi baytlar yarim kechani qachon kesib o'tgani haqida ma'lumot olib yurmaydi.

Tugash kirishni rad etsin, faqat tunnelni o'ldirmasin

Hisob o'z chegarasiga yetganda ikki narsa sodir bo'lishi kerak: mavjud sessiyalar tugaydi va yangilari rad etiladi. Boshqaruv protokoli mijoz IDsi bo'yicha client-kill taqdim etadi, bu hisobning har bir tirik sessiyasini sanab chiqsangiz birinchi yarmini hal qiladi, tasodifan ko'rgan bitta manzilni o'ldirish o'rniga.

Ikkinchi yarmi kvota dizaynlari muvaffaqiyatsiz bo'ladigan joy. Faqat o'ldirish mijozning qayta ulanish halqasi bilan poyga, u bir necha soniyadan keyin mamnuniyat bilan qaytadi. Kirish umumiy daftar bilan maslahatlashishi kerak, va ko'p shlyuzli joylashtirishda bu tekshiruv har bir mashina uchun fayl bo'la olmaydi. Har bir kirishni qabul qila oladigan nusxa bir xil tugagan holatni ko'rishi kerak.

Token asosidagi qayta ulanishlar o'z sinoviga loyiq. OpenVPN 2.6 auth-gen-token bilan sessiya tokenini ichkarida tekshira oladi va kontrolleriingiz chegarani amalga oshirish uchun ishlatgan tashqi autentifikatsiya chaqiruvini o'tkazib yuboradi. Shuning uchun hali amal qiladigan token shaxsni isbotlaydi, qolgan kvotani emas, va har bir yangi mijoz nusxasi baribir daftar bilan maslahatlashishi kerak. Buning o'rniga management-client-auth ni yoqsangiz, kontroller autentifikatorga aylanadi va sessiya holatini o'zi tahlil qilib, muddati o'tgan yoki yaroqsiz tokenlarni o'zi rad etish majburiyatini meros qilib oladi.

Namuna olish keltirib chiqaradigan oshib ketishni qabul qiling

Davriy kuzatish va uzilish sizga ma'lum tolerantlik bilan namunalangan kvota beradi. Mijoz taxminan bitta hisobot oralig'i va kontroller harakat qilishi uchun kerak bo'ladigan vaqtga oshib ketishi mumkin, va bitta hisobdagi bir vaqtning o'zida sessiyalar bu oynani bir necha barobar oshiradi. Oxirgi baytda aniq kesishni reklama qilish o'rniga, buni interfeysda ayting, chunki siz buni ta'minlay olmaysiz.

Haqiqiy qattiq shift boshqa muhandislik muammosi: uzatish yo'lining ichida, sessiyalar bo'ylab bir xil hisobga bog'langan ijro. Hisoblagichlarni tezroq o'qish bir xil narsa emas va shunchaki ko'proq tunnel ochadigan mijozga bardosh bermaydi.

Joylashtirishdan oldin sodda joriy etishlarni buzadigan qabul holatlarini ishga tushiring: takroriy qayta ulanishlar, bir vaqtda ikkita qurilma, kontroller va shlyuzning qayta ishga tushishi, yo'qolgan uzilish hodisasi, sessiya o'rtasida davr aylanishi va tugagandan so'ng darhol token bilan qayta ulanishga urinish. Keyin hisob-kitob uzilishlari uchun nosozlik rejimini hal qiling. Barqaror daftar siz qayd etgan foydalanishni himoya qiladi; u hech qachon kelmagan kuzatishlarni tiriltira olmaydi, va mijoz o'sha ikki holatdan qaysi birida ekanini bilishga loyiq.