Wêr't in moanlikse datakwota by in OpenVPN-account heart

In kwota dy't weromset wurdt elke kear as de tunnel wer ferbynt, is gjin limyt, en dat is krekt wat jo krije as in byte-teller op in VPN-tsjinner fêstskroeve wurdt sûnder in plak foar duorjende steat. De teller heart by in sesje; de kwota heart by in persoan of in apparaatkontrakt. Alle swierrichheden fan 'e funksje komme út dat misferstân, dêrom geane de kontrôles hjirûnder oer wêr't steat wennet en hokker laach beslute mei.

Fêstigje de kwota oan in account, net oan in tunnel

Begjin mei it neamen fan it ûnderwerp fan 'e kwota. Ien persoan kin trije apparaatsertifikaten hawwe, en gjin fan harren heart in selsstannich moanlikse budzjet te krijen allinnich om't se apart autentisearje. In stabile account-identifikaasje dy't werferbiningen, nije tunneladressen en in ferhuzing nei in twadde gateway oerlibbet, is it iennige anker dat in kwota brûke kin. De mienskiplike namme fan in sertifikaat wurket as dy kaai allinnich as jo útjaanbelied ien account per namme garandearret.

In tawiisd tunneladres is nea it antwurd. Adressen wurde recycled, pools wurde dield, en deselde account kin twa kear op twa gateways ferskine yn deselde minút. As it grutboek op in adres kaaielet, is ôfbrekke en wer ferbinen genôch om de tank wer fol te meitsjen.

Skriuw genôch per sesje op om de rekkenkunde kontrolearber te meitsjen: de account, de fakturearringsperioade, de gateway-eksimplaar, de sesje-identiteit, de lêst waarnommen tellers en it fêstleine totaal. Nim in daemon-startgeneraasje op yn 'e sesje-identiteit, want in werstarte tsjinner brûkt kliïnt-ID's opnij en in naïve oerienkomst soe de foarige basisline ervje.

Fêstigje de ienheid, rjochting en weromsetgrins

Fjouwer definysjes moatte skriftlik fêstlein wurde foardat hokker samling dan ek begjint. Telt de kwota bytes dy't de kliïnt stjoert, bytes dy't er ûntfangt, of de som fan beide? Is in gigabyte 10^9 bytes of 2^30? Op hokker pleatslike oere en yn hokker tiidssône rôlet de perioade om? En wat mjit de teller krekt, mei't tunnel-oerhaad en werstjoeringen ynbegrepen binne, wylst de bestânsgrutte fan 'e applikaasje en de faktuer fan in leveransier dat net binne?

Gjin fan dy karren is ferkeard, mar de ymplemintaasje en it nûmer dat de klant sjocht moatte oerienkomme. Twa helten fan itselde systeem dy't it net iens binne oer GiB, of oer in omslach dy't om middernacht UTC bart ynstee fan pleatslike tiid, meitsje krekt datsoarte ticket dat it fertrouwen yn 'e hiele kwota ûndergraaft.

Meitsje fan byte-totalen ien rekkenne delta

De behearinterface rapportearret periodyk BYTECOUNT_CLI-regels dy't in kliïnt-ID plus kumulative byte-totalen yn elke rjochting drage, en it bytecount-kommando stelt yn hoe faak dy oankomme. Fan it eachpunt fan 'e tsjinner ôf telt it ûntfongen sifer de bytes dy't de kliïnt stjoerd hat en it ferstjoerde sifer telt de bytes dy't oan him levere binne. Set it ynterval op eat dat it grutboek absorbearje kin; in hiel koart ynterval keapet krektens dy't jo net echt krije.

Ien beheining foarmet it hiele ûntwerp: de behearsocket akseptearret ien inkele kontrôleferbining. In monitoring-eksporteur, in GUI en jo controller kinne net elk har eigen iepenje. Beslis hokker proses it kanaal besit en lit de oaren steat dêrút lêze, want dizze interface jout administratyke aksjes en soe dochs net bûten de host bleatsteld wurde moatte.

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

Fêstigje de nije basislinen en de gebrûkstamming tegearre, sadat it opnij spyljen fan in meunster neat rekkenet ynstee fan twa kear te rekenjen. In teller dy't efterút giet is in sinjaal, gjin skuld: it betsjut dat de sesje ferfongen is of dat de daemon werstart is, en it goede antwurd is de sesje-identiteit te fermoedsoenjen ynstee fan in negatyf bedrach te kreditearen.

It ôfbrekpaad hat deselde soarch nedich. As in lêste barren totalen fan sesje-ein draacht, rekenje dan allinnich it ferskil mei it lêst fêstleine meunster. It folsleine totaal tafoegje nei't periodyk meunsterjen al rekkene is, is de meast foarkommende dûbele telling yn selsmakke kwotasystemen. Sesjes dy't oer in perioadegrins hinne geane hawwe ek in regel nedich, mei't ien lêst totaal gjin ynformaasje draacht oer wannear't de bytes middernacht oerstutsen.

Lit útputting de tagong wegerje, net allinnich de tunnel deadzje

As in account syn limyt berikt, moatte twa dingen barre: besteande sesjes einigje en nije wurde wegere. It behearprotokol biedt client-kill per kliïnt-ID, wat de earste helte docht salang't jo elke libbene sesje fan 'e account opneame ynstee fan it iene adres te deadzjen dat jo tafallich seagen.

De twadde helte is wêr't kwota-ûntwerpen misse. In deadzjen allinnich is in wedrin tsjin 'e werferbininglus fan 'e kliïnt, dy't grif sekonden letter weromkomt. Tagong moat it dielde grutboek rieplachtsje, en by in útrulling mei meardere gateways kin dy kontrôle gjin bestân per masine wêze. Elk eksimplaar dat in oanmelding akseptearje kin, moat deselde útpûte steat sjen.

Token-basearre werferbiningen fertsjinje har eigen test. OpenVPN 2.6 kin in sesjetoken yntern falidearje mei auth-gen-token, en slacht de eksterne autentikaasje-oprop oer dy't jo controller brûkte om it plafond te hanthavenjen. In token dat noch jildich is bewiist dus identiteit, net oerbliuwende kwota, en elk nij kliïnteksimplaar moat noch altyd it grutboek rieplachtsje. As jo ynstee management-client-auth ynskeakelje, wurdt de controller de autentikator en erft dy de ferplichting om sels sesjesteat te ûntlijen en ferrûne of ûnjildige tokens te wegerjen.

Akseptearje it oersjitten dat it meunsterjen makket

Periodyk waarnimmen plus ôfbrekken jouwe jo in bemeunstere kwota mei in bekende tolerânsje. In kliïnt kin sawat ien rapportaazje-ynterval plus de tiid dy't de controller nedich hat om te hanneljen oersjitte, en tagelyk sesjes op ien account fermannichfâldigje dat finster. Sis dat yn 'e interface ynstee fan in krekte snij by de lêste byte oan te kundigjen dy't jo net leverje kinne.

In echte hurde plafond is in oar yngenieursprobleem: hanthavening binnen it trochstjoerpaad, bûn oan deselde account oer sesjes hinne. Tellen lêze is net itselde, en it oerlibbet in kliïnt net dy't gewoan mear tunnels iepenet.

Rin foar de útrulling de akseptaasjefallen dy't naïve ymplemintaasjes brekke: werhelle werferbiningen, twa apparaten tagelyk, werstarts fan controller en gateway, in ferlern ôfbrekbarren, in omslach midden yn in sesje en in token-werferbining besocht fuort nei útputting. Beslis dan de flatermodus foar ûnderbrekkingen yn 'e boekhâlding. In duorjend grutboek beskermet it gebrûk dat jo fêstlein hawwe; it kin waarnimmings dy't nea oankamen net wer ta libben bringe, en de klant fertsjinnet te witten yn hokker fan dy twa situaasjes er sit.