Kur priklauso mėnesinė duomenų kvota vienai OpenVPN paskyrai

Kvota, kuri nustatoma iš naujo kiekvieną kartą, kai tunelis prisijungia iš naujo, nėra riba, ir būtent tai gaunama, kai baitų skaitiklis priveržiamas prie VPN serverio be vietos ilgalaikei būsenai. Skaitiklis priklauso sesijai; kvota priklauso asmeniui arba įrenginio sutarčiai. Visas funkcijos sudėtingumas kyla iš šio neatitikimo, todėl toliau pateikti patikrinimai yra apie tai, kur gyvena būsena ir kuriam sluoksniui leidžiama nuspręsti.

Prisekite kvotą prie paskyros, o ne prie tunelio

Pradėkite įvardydami kvotos subjektą. Vienas asmuo gali turėti tris įrenginių sertifikatus, ir nė vienas iš jų neturėtų gauti nepriklausomo mėnesinio biudžeto vien todėl, kad jie autentifikuojasi atskirai. Stabilus paskyros identifikatorius, išgyvenantis prisijungimus iš naujo, naujus tunelio adresus ir persikėlimą į antrąją tinklų sietuvą, yra vienintelis inkaras, kurį kvota gali naudoti. Bendrasis sertifikato pavadinimas veikia kaip tas raktas tik tada, kai jūsų išdavimo politika garantuoja vieną paskyrą vienam vardui.

Priskirtas tunelio adresas niekada nėra atsakymas. Adresai perdirbami, baseinai bendrinami, ir ta pati paskyra gali pasirodyti du kartus dviejuose sietuvuose tą pačią minutę. Jei knyga remiasi adresu, atsijungimo ir prisijungimo iš naujo pakanka bakui vėl pripildyti.

Užrašykite pakankamai kiekvienai sesijai, kad aritmetika būtų audituojama: paskyrą, atsiskaitymo laikotarpį, sietuvo egzempliorių, sesijos tapatybę, paskutinius stebėtus skaitiklius ir patvirtintą sumą. Įtraukite demono paleidimo kartą į sesijos tapatybę, nes paleistas iš naujo serveris naudoja tuos pačius klientų ID, ir naivus sutapimas paveldėtų ankstesnę bazinę liniją.

Nustatykite vienetą, kryptį ir atstatymo ribą

Prieš pradedant bet kokį rinkimą, raštu reikia sutarti dėl keturių apibrėžimų. Ar kvota skaičiuoja baitus, kuriuos klientas siunčia, kuriuos gauna, ar abiejų sumą? Ar gigabaitas yra 10^9 baitų, ar 2^30? Kurią vietinę valandą ir kurioje laiko juostoje laikotarpis persisuka? Ir ką tiksliai matuoja skaitiklis, turint omenyje, kad tunelio pridėtinės išlaidos ir pakartotiniai perdavimai įtraukti, o programos failo dydis ir tiekėjo sąskaita – ne?

Nė vienas iš šių pasirinkimų nėra klaidingas, bet įgyvendinimas ir kliento matomas skaičius turi sutapti. Dvi tos pačios sistemos pusės, nesutariančios dėl GiB arba dėl persisukimo, vykstančio UTC vidurnaktį, o ne vietiniu laiku, sukuria būtent tokį bilietą, kuris pakerta pasitikėjimą visa kvota.

Paverskite baitų sumas vienu apmokestintu skirtumu

Valdymo sąsaja praneša periodines BYTECOUNT_CLI eilutes, kurios neša kliento ID ir sukauptas baitų sumas kiekviena kryptimi, o komanda bytecount nustato, kaip dažnai jos ateina. Serverio požiūriu gautas skaičius skaičiuoja kliento išsiųstus baitus, o išsiųstas skaičius – jam pristatytus baitus. Nustatykite intervalą tokį, kad knyga galėtų jį absorbuoti; labai trumpas intervalas nuperka tikslumą, kurio iš tikrųjų negaunate.

Vienas apribojimas formuoja visą dizainą: valdymo lizdas priima vieną valdymo ryšį. Stebėjimo eksportuotojas, GUI ir jūsų valdiklis negali kiekvienas atsidaryti savo. Nuspręskite, kuris procesas valdo kanalą, ir leiskite kitiems iš jo skaityti būseną, nes ši sąsaja suteikia administracinius veiksmus ir bet kuriuo atveju neturėtų būti atskleista už pagrindinio kompiuterio ribų.

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

Patvirtinkite naujas bazines linijas ir naudojimo prieaugį kartu, kad pavyzdžio pakartojimas nieko neapmokestintų, o ne apmokestintų du kartus. Atgal judantis skaitiklis yra signalas, ne skola: tai reiškia, kad sesija buvo pakeista arba demonas paleistas iš naujo, ir teisingas atsakymas yra suderinti sesijos tapatybę, o ne įskaityti neigiamą sumą.

Atjungimo kelias reikalauja tokios pačios priežiūros. Jei galutinis įvykis neša sesijos pabaigos sumas, apmokestinkite tik skirtumą nuo paskutinio patvirtinto pavyzdžio. Visos sumos pridėjimas po to, kai periodinis ėmimas jau apmokestintas, yra dažniausias dvigubas skaičiavimas naminių kvotų sistemose. Sesijos, kertančios laikotarpio ribą, taip pat reikalauja taisyklės, nes viena galutinė suma neteikia informacijos, kada baitai kirto vidurnaktį.

Išnaudojimas teatmeta prisijungimą, o ne tik užmuša tunelį

Kai paskyra pasiekia savo ribą, turi įvykti du dalykai: esamos sesijos baigiasi, o naujos atmetamos. Valdymo protokolas siūlo client-kill pagal kliento ID, kuris išsprendžia pirmąją pusę, jei išvardijate kiekvieną gyvą paskyros sesiją, o ne nužudote vienintelį adresą, kurį atsitiktinai pastebėjote.

Antroji pusė yra vieta, kur kvotų dizainai žlunga. Vien nužudymas yra lenktynės su kliento prisijungimo iš naujo kilpa, kuri mielai grįš po kelių sekundžių. Prisijungimas turi pasitarti su bendra knyga, o diegime su keliais sietuvais šis patikrinimas negali būti failas kiekviename kompiuteryje. Kiekvienas egzempliorius, galintis priimti prisijungimą, turi matyti tą pačią išnaudotą būseną.

Prisijungimai iš naujo pagal žetoną nusipelno savo testo. OpenVPN 2.6 gali viduje patikrinti sesijos žetoną su auth-gen-token, praleisdamas išorinį autentifikavimo kvietimą, kurį jūsų valdiklis naudojo ribai vykdyti. Todėl vis dar galiojantis žetonas įrodo tapatybę, o ne likusią kvotą, ir kiekvienas naujas kliento egzempliorius vis tiek turi pasitarti su knyga. Jei vietoj to įjungsite management-client-auth, valdiklis taps autentifikatoriumi ir paveldės pareigą pačiam analizuoti sesijos būseną ir atmesti pasibaigusius ar negaliojančius žetonus.

Priimkite viršijimą, kurį sukuria ėmimas

Periodinis stebėjimas ir atjungimas suteikia jums pavyzdinę kvotą su žinoma tolerancija. Klientas gali viršyti maždaug vienu ataskaitos intervalu ir laiku, kurio reikia valdikliui sureaguoti, o vienos paskyros lygiagrečios sesijos padaugina šį langą. Pasakykite tai sąsajoje, o ne reklamuokite tikslų paskutinio baito atpjovimą, kurio negalite užtikrinti.

Tikra kieta lubos yra kita inžinerinė problema: vykdymas persiuntimo kelyje, susietas su ta pačia paskyra per sesijas. Greitesnis skaitiklių skaitymas nėra tas pats, ir tai neatlaiko kliento, kuris tiesiog atidaro daugiau tunelių.

Prieš diegdami paleiskite priėmimo atvejus, kurie laužo naivius įgyvendinimus: pakartotiniai prisijungimai iš naujo, du įrenginiai vienu metu, valdiklio ir sietuvo paleidimai iš naujo, prarastas atjungimo įvykis, laikotarpio persisukimas sesijos viduryje ir bandymas prisijungti iš naujo su žetonu iškart po išnaudojimo. Tada nuspręskite apskaitos sutrikimų gedimo režimą. Ilgalaikė knyga apsaugo užfiksuotą naudojimą; ji negali prikelti stebėjimų, kurie niekada neatėjo, ir klientas nusipelno žinoti, kurioje iš šių dviejų situacijų jis yra.