Kie apartenas monata datumkvoto por OpenVPN-konto

Kvoto, kiu restartiĝas ĉiufoje, kiam la tunelo rekonektiĝas, ne estas limo, kaj ĝuste tion oni ricevas, kiam bajtokalkulilo estas ŝraŭbata al VPN-servilo sen loko por daŭra stato. La kalkulilo apartenas al sesio; la kvoto apartenas al persono aŭ al aparata kontrakto. Ĉiu malfacilaĵo de la funkcio venas de tiu miskongruo, do la subaj kontroloj temas pri tio, kie loĝas stato kaj kiu tavolo rajtas decidi.

Fiksu la kvoton al konto, ne al tunelo

Komencu nomante la subjekton de la kvoto. Unu persono povas havi tri aparatajn atestilojn, kaj neniu el ili devus ricevi sendependan monatan buĝeton nur ĉar ili aŭtentikiĝas aparte. Stabila konta identigilo, kiu postvivas rekonektojn, novajn tunelajn adresojn kaj translokiĝon al dua enirejo, estas la sola ankro, kiun kvoto povas uzi. La komuna nomo de atestilo funkcias kiel tiu ŝlosilo nur kiam via eldona politiko garantias unu konton por nomo.

Atribuita tunela adreso neniam estas la respondo. Adresoj estas recikligataj, naĝejoj estas dividataj, kaj la sama konto povas aperi dufoje sur du enirejoj en la sama minuto. Se la libro ŝlosas laŭ adreso, malkonekti kaj rekonekti sufiĉas por replenigi la tankon.

Registru sufiĉe por sesio, por ke la aritmetiko estu aŭdebla: la konto, la faktura periodo, la enireja instanco, la sesia identeco, la laste observitaj kalkuliloj kaj la fiksita sumo. Inkluzivu demonan startgeneracion en la sesian identecon, ĉar restartigita servilo reuzas klientajn identigilojn, kaj naiva kongruo heredus la antaŭan bazlinion.

Fiksu la unuon, direkton kaj restarigan limon

Kvar difinoj devas esti fiksitaj skribe antaŭ ol komenciĝi iu ajn kolektado. Ĉu la kvoto kalkulas bajtojn, kiujn la kliento sendas, bajtojn, kiujn ĝi ricevas, aŭ la sumon de ambaŭ? Ĉu gigabajto estas 10^9 bajtoj aŭ 2^30? Je kiu loka horo kaj en kiu horzono la periodo turniĝas? Kaj kion ĝuste mezuras la kalkulilo, konsiderante ke tunela superŝarĝo kaj retransmetoj estas inkluditaj, dum la dosiergrandeco de la aplikaĵo kaj fakturo de provizanto ne estas?

Neniu el tiuj elektoj estas malĝusta, sed la efektivigo kaj la nombro, kiun la kliento vidas, devas kongrui. Du duonoj de la sama sistemo, kiuj malkonsentas pri GiB, aŭ pri turniĝo okazanta je noktomezo UTC anstataŭ loka tempo, produktas ĝuste tian bileton, kiu subfosas fidon al la tuta kvoto.

Transformu bajtajn sumojn en unu ŝargitan delton

La administra interfaco raportas periodajn BYTECOUNT_CLI-liniojn, kiuj portas klientan identigilon kaj akumulitajn bajtajn sumojn en ĉiu direkto, kaj la komando bytecount difinas, kiom ofte ili alvenas. El la vidpunkto de la servilo, la ricevita nombro kalkulas la bajtojn, kiujn la kliento sendis, kaj la sendita nombro kalkulas la bajtojn liveritajn al ĝi. Agordu la intervalon al io, kion la libro povas absorbi; tre mallonga intervalo aĉetas precizecon, kiun vi fakte ne ricevas.

Unu limigo formas la tutan dezajnon: la administra ingo akceptas unu solan kontrolan konekton. Monitora eksportilo, GUI kaj via regilo ne povas ĉiu malfermi sian propran. Decidu, kiu procezo posedas la kanalon, kaj lasu la aliajn legi staton el ĝi, ĉar ĉi tiu interfaco donas administrajn agojn kaj ĝi principe ne devus esti elmetita ekster la gastiganto.

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

Fiksu la novajn bazliniojn kaj la uzan pliigon kune, por ke repludado de specimeno ŝargu nenion anstataŭ ŝargi dufoje. Kalkulilo, kiu moviĝas malantaŭen, estas signalo, ne ŝuldo: ĝi signifas, ke la sesio estis anstataŭigita aŭ ke la demono restartis, kaj la ĝusta respondo estas akordigi la sesian identecon anstataŭ krediti negativan sumon.

La malkonekta vojo bezonas la saman zorgon. Se fina evento portas sumojn de sesifino, ŝargu nur la diferencon de la laste fiksita specimeno. Aldoni la plenan sumon post kiam la perioda specimenado jam estis ŝargita estas la plej ofta duobla kalkulado en hejmfaritaj kvotsistemoj. Sesioj, kiuj transiras periodan limon, ankaŭ bezonas regulon, ĉar unu fina sumo portas neniun informon pri tio, kiam la bajtoj transiris noktomezon.

Elĉerpiĝo rifuzu akcepton, ne nur mortigu la tunelon

Kiam konto atingas sian limon, du aferoj devas okazi: ekzistantaj sesioj finiĝas, kaj novaj estas rifuzataj. La administra protokolo provizas client-kill laŭ klienta identigilo, kio traktas la unuan duonon kondiĉe ke vi listigu ĉiun vivan sesion de la konto anstataŭ mortigi la unu adreson, kiun vi hazarde rimarkis.

La dua duono estas kie kvotaj dezajnoj malsukcesas. Sola mortigo estas vetkuro kontraŭ la rekonekta buklo de la kliento, kiu volonte revenos post sekundoj. Akcepto devas konsulti la komunan libron, kaj en multienireja deplojo tiu kontrolo ne povas esti dosiero por maŝino. Ĉiu instanco, kiu povas akcepti ensaluton, devas vidi la saman elĉerpitan staton.

Ĵetonaj rekonektoj meritas sian propran teston. OpenVPN 2.6 povas validigi sesian ĵetonon interne per auth-gen-token, preterlasante la eksteran aŭtentikigan vokon, kiun via regilo uzis por plenumi la limon. Ĵetono, kiu ankoraŭ validas, do pruvas identecon, ne restantan kvoton, kaj ĉiu nova klienta instanco devas ankoraŭ konsulti la libron. Se vi anstataŭe ebligas management-client-auth, la regilo fariĝas la aŭtentikiganto kaj heredas la devon mem analizi sesian staton kaj rifuzi eksvalidiĝintajn aŭ nevalidajn ĵetonojn.

Akceptu la superŝuton, kiun kreas la specimenado

Perioda observado plus malkonekto donas al vi specimenan kvoton kun konata toleremo. Kliento povas superi ĝin proksimume je unu raporta intervalo plus la tempo, kiun la regilo bezonas por agi, kaj samtempaj sesioj sur unu konto multobligas tiun fenestron. Diru tion en la interfaco anstataŭ anonci precizan tranĉon ĉe la lasta bajto, kiun vi ne povas liveri.

Vera malmola plafono estas alia inĝeniera problemo: plenumo ene de la plusenda vojo, ligita al la sama konto tra sesioj. Legi kalkulilojn pli rapide ne estas la sama afero, kaj ĝi ne postvivas klienton, kiu simple malfermas pli da tuneloj.

Antaŭ lanĉo, rulu la akceptajn kazojn, kiuj rompas naivajn efektivigojn: ripetaj rekonektoj, du aparatoj samtempe, restartoj de regilo kaj enirejo, perdita malkonekta evento, turniĝo meze de sesio kaj ĵetona rekonekta provo tuj post elĉerpiĝo. Poste decidu la fiaskmanieron por interrompoj de librotenado. Daŭra libro protektas la uzon, kiun vi registris; ĝi ne povas revivigi observojn, kiuj neniam alvenis, kaj la kliento meritas scii, en kiu el tiuj du situacioj ĝi troviĝas.