Aylıq məlumat kvotası OpenVPN hesabında hara aiddir

Tunel hər dəfə yenidən qoşulanda sıfırlanan kvota limit deyil və davamlı vəziyyət saxlamaq üçün yer olmadan VPN serverinə bayt sayğacı vurulanda məhz bunu alırsınız. Sayğac sessiyaya aiddir; kvota isə şəxsə və ya cihaz müqaviləsinə aiddir. Bu funksiyadakı bütün çətinliklər həmin uyğunsuzluqdan qaynaqlanır, ona görə də aşağıdakı yoxlamalar vəziyyətin harada saxlandığına və hansı qatın qərar verməsinə icazə verildiyinə aiddir.

Kvotanı tunelə deyil, hesaba bağlayın

Kvotanın subyektini adlandırmaqla başlayın. Bir şəxsin üç cihaz sertifikatı ola bilər və onlardan heç biri yalnız ayrıca autentifikasiya etdiyi üçün müstəqil aylıq büdcə almamalıdır. Yenidən qoşulmalara, yeni tunel ünvanlarına və ikinci şlüzə keçidə davam edən sabit hesab identifikatoru kvotanın istifadə edə biləcəyi yeganə dayaqdır. Sertifikatın ümumi adı bu açar kimi yalnız buraxılış siyasətiniz hər ada bir hesab zəmanət verdikdə işləyir.

Təyin edilmiş tunel ünvanı heç vaxt cavab deyil. Ünvanlar təkrar istifadə olunur, hovuzlar paylaşılır və eyni hesab eyni dəqiqədə iki şlüzdə iki dəfə görünə bilər. Əgər jurnal ünvana görə açarsa, bağlantını kəsib yenidən qoşulmaq çəni yenidən doldurmaq üçün kifayətdir.

Hesablamanı yoxlanıla bilən etmək üçün sessiya üzrə kifayət qədər qeyd aparın: hesab, hesablaşma dövrü, şlüz nüsxəsi, sessiya kimliyi, son müşahidə olunan sayğaclar və təsdiqlənmiş cəm. Sessiya kimliyinə demonun başlama nəslini daxil edin, çünki yenidən başladılan server müştəri ID-lərini təkrar istifadə edir və sadəlövh uyğunlaşdırma əvvəlki baza xəttini miras alardı.

Vahidi, istiqaməti və sıfırlama sərhədini müəyyənləşdirin

Hər hansı toplama başlamazdan əvvəl dörd tərif yazılı şəkildə həll edilməlidir. Kvota müştərinin göndərdiyi baytları, aldığı baytları, yoxsa hər ikisinin cəmini sayır? Gigabayt 10^9 baytdır, yoxsa 2^30? Dövr hansı yerli saatda və hansı saat qurşağında dəyişir? Və sayğac dəqiq nəyi ölçür, halbuki tunel əlavə yükü və yenidən ötürmələr daxildir, tətbiq faylının ölçüsü və provayderin hesab-fakturası isə deyil?

Bu seçimlərin heç biri səhv deyil, amma tətbiq və müştəriyə baxan rəqəm razılaşmalıdır. Eyni sistemin iki yarısının GiB, ya da yerli vaxt əvəzinə UTC gecə yarısında baş verən dəyişmə barədə razılaşmaması bütün kvotaya inamı sarsıdan məhz o cür bileti yaradır.

Bayt cəmlərini bir tutulan fərqə çevirin

idarəetmə interfeysi dövri BYTECOUNT_CLI sətirlərini bildirir; bu sətirlər müştəri ID-si ilə hər istiqamətdə yığılmış bayt cəmlərini daşıyır və bytecount əmri onların nə qədər tez-tez gəldiyini müəyyən edir. Serverin nöqteyi-nəzərindən alınan rəqəm müştərinin göndərdiyi baytları, göndərilən rəqəm isə ona çatdırılan baytları sayır. İntervalı jurnalın həzm edə biləcəyi bir şeyə qoyun; çox qısa interval əslində əldə etmədiyiniz dəqiqliyi alır.

Bir məhdudiyyət bütün dizaynı formalaşdırır: idarəetmə soketi tək nəzarət bağlantısı qəbul edir. Monitorinq ixrac edən, GUI və nəzarətçiniz hər biri öz bağlantısını aça bilməz. Kanalın hansı prosesə aid olduğunu qərar verin və qalanlar vəziyyəti ondan oxusun, çünki bu interfeys inzibati əməliyyatlar verir və onsuz da hostdan kənara çıxarılmamalıdır.

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

Yeni baza xətlərini və istifadə artımını birlikdə təsdiqləyin ki, nümunənin təkrar oynadılması iki dəfə tutmaq əvəzinə heç nə tutmasın. Geriyə hərəkət edən sayğac siqnaldır, borc deyil: bu, sessiyanın dəyişdirildiyini və ya demonun yenidən başladıldığını bildirir və düzgün cavab mənfi məbləğ yazmaq əvəzinə sessiya kimliyini uzlaşdırmaqdır.

Bağlantının kəsilmə yolu da eyni qayğıya ehtiyac duyur. Əgər son hadisə sessiyanın sonundakı cəmləri daşıyırsa, yalnız son təsdiqlənmiş nümunədən fərqi tutun. Dövri seçmə artıq tutulduqdan sonra tam cəmi əlavə etmək evdə hazırlanmış kvota sistemlərində ən geniş yayılmış ikiqat saymadır. Dövr sərhədini keçən sessiyaların da qaydaya ehtiyacı var, çünki bir son cəm baytların gecə yarısını nə vaxt keçdiyi barədə heç bir məlumat daşımır.

Tükənmə tuneli öldürməklə yox, qəbulu rədd etsin

Hesab öz limitinə çatdıqda iki hərəkət baş verməlidir: mövcud sessiyalar bitsin və yeniləri rədd edilsin. İdarəetmə protokolu müştəri ID-si ilə client-kill təqdim edir və bu, hesab üzrə hər canlı sessiyanı sadaladığınız müddətcə birinci yarısını həll edir; təsadüfən gördüyünüz tək ünvanı öldürməklə yox.

İkinci yarı kvota dizaynlarının uğursuz olduğu yerdir. Tək öldürmə müştərinin yenidən qoşulma dövrəsinə qarşı yarışdır və o, saniyələr sonra məmnuniyyətlə geri qayıdır. Qəbul paylaşılan jurnala müraciət etməlidir və çoxşlüzlü yerləşdirmədə bu yoxlama maşın başına fayl ola bilməz. Girişi qəbul edə bilən hər nüsxə eyni tükənmə vəziyyətini görməlidir.

Token əsaslı yenidən qoşulmalar öz testlərinə layiqdir. OpenVPN 2.6 sessiya tokenini auth-gen-token ilə daxildən doğrulaya bilir və nəzarətçinizin limiti tətbiq etmək üçün istifadə etdiyi xarici autentifikasiya çağırışını atlayır. Ona görə də hələ də etibarlı olan token kimliyi sübut edir, qalan kvotanı yox, və hər yeni müştəri nüsxəsi yenə də jurnala müraciət etməlidir. Əvəzində management-client-auth-u aktivləşdirsəniz, nəzarətçi autentifikatora çevrilir və sessiya vəziyyətini təhlil etmək, vaxtı keçmiş və ya etibarsız tokenləri özü rədd etmək öhdəliyini miras alır.

Seçmənin yaratdığı aşmanı qəbul edin

Dövri müşahidə üstəgəl bağlantının kəsilməsi sizə məlum dözümlülüklə seçmə kvota verir. Müştəri təxminən bir hesabat intervalı üstəgəl nəzarətçinin hərəkət etməsi üçün lazım olan vaxt qədər aşa bilər və bir hesabda eyni vaxtda olan sessiyalar bu pəncərəni çoxaldır. Son baytda dəqiq kəsim vəd edə bilmədiyiniz halda bunu interfeysdə deyin.

Əsl sərt tavan başqa mühəndislik problemidir: ötürmə yolunun içində, sessiyalar boyu eyni hesaba bağlı icra. Sayğacları daha sürətli oxumaq eyni şey deyil və sadəcə daha çox tunel açan müştəriyə tab gətirmir.

Yerləşdirmədən əvvəl sadəlövh tətbiqləri sındıran qəbul hallarını işə salın: təkrar yenidən qoşulmalar, eyni anda iki cihaz, nəzarətçi və şlüzün yenidən başladılması, itirilmiş bağlantı kəsilməsi hadisəsi, sessiya ortasında dövr dəyişməsi və tükənmədən dərhal sonra cəhd edilən token yenidən qoşulması. Sonra hesabatlıq kəsilmələri üçün uğursuzluq rejimini müəyyənləşdirin. Davamlı jurnal qeyd etdiyiniz istifadəni qoruyur; heç vaxt gəlməyən müşahidələri dirildə bilməz və müştəri bu iki vəziyyətdən hansında olduğunu bilməyə layiqdir.