Waar 'n maandelikse datakwota per OpenVPN-rekening hoort

'n Kwota wat terugstel wanneer die tonnel weer verbind, is nie 'n limiet nie, en dit is presies wat jy kry wanneer 'n grepteller op 'n VPN-bediener vasgebout word sonder 'n plek om duursame toestand te stoor. Die teller behoort aan 'n sessie; die kwota behoort aan 'n persoon of 'n toestelkontrak. Alles wat moeilik is aan die funksie kom uit daardie wanverhouding, so die kontroles hieronder gaan oor waar toestand woon en watter laag mag besluit.

Maak die kwota vas aan 'n rekening, nie aan 'n tonnel nie

Begin deur die onderwerp van die kwota te benoem. Een persoon kan drie toestelsertifikate hê, en nie een van hulle behoort 'n onafhanklike maandelikse begroting te kry bloot omdat hulle afsonderlik verifieer nie. 'n Stabiele rekeningidentifiseerder wat herverbindings, nuwe tonneladresse en 'n skuif na 'n tweede poort oorleef, is die enigste anker wat 'n kwota kan gebruik. 'n Sertifikaat se algemene naam werk as daardie sleutel net wanneer jou uitreikingsbeleid een rekening per naam waarborg.

'n Toegewysde tonneladres is nooit die antwoord nie. Adresse word herwin, poele word gedeel, en dieselfde rekening kan binne dieselfde minuut twee keer op twee poorte verskyn. As die grootboek op 'n adres sleutel, is ontkoppel en weer koppel genoeg om die tenk weer vol te maak.

Teken genoeg per sessie aan om die rekenkunde ouditeerbaar te maak: die rekening, die faktureringsperiode, die poortinstansie, die sessie-identiteit, die laas waargenome tellers en die vasgelegde totaal. Sluit 'n daemon-startgenerasie by die sessie-identiteit in, want 'n herbegin bediener hergebruik kliënt-ID's en 'n naïewe passing sou die vorige basislyn erf.

Bepaal die eenheid, rigting en herstelgrens

Vier definisies moet skriftelik vasgestel word voordat enige insameling begin. Tel die kwota grepe wat die kliënt stuur, grepe wat hy ontvang, of die som van albei? Is 'n gigagreep 10^9 grepe of 2^30? Op watter plaaslike uur en in watter tydsone rol die periode oor? En wat presies meet die teller, gegewe dat tonnel-oorhoofse koste en hertransmissies ingesluit is terwyl toepassing-lêergrootte en 'n verskaffer se faktuur nie is nie?

Nie een van daardie keuses is verkeerd nie, maar die implementering en die kliëntgerigte getal moet ooreenstem. Twee helftes van dieselfde stelsel wat verskil oor GiB, of oor 'n oorskakeling wat om middernag UTC in plaas van plaaslike tyd gebeur, lewer presies die soort kaartjie wat vertroue in die hele kwota ondermyn.

Verander grepetotale in een gehefte delta

Die bestuurskoppelvlak rapporteer periodieke BYTECOUNT_CLI-reëls wat 'n kliënt-ID plus opgehoopte grepetotale in elke rigting dra, en die bytecount-opdrag stel hoe gereeld dié aankom. Vanuit die bediener se oogpunt tel die ontvangde syfer grepe wat die kliënt gestuur het, en die gestuurde syfer tel grepe wat aan hom afgelewer is. Stel die interval na iets wat die grootboek kan absorbeer; 'n baie kort interval koop presisie wat jy nie werklik kry nie.

Een beperking vorm die hele ontwerp: die bestuursokket aanvaar 'n enkele beheerverbinding. 'n Monitering-uitvoerder, 'n GUI en jou kontroleerder kan nie elkeen sy eie oopmaak nie. Besluit watter proses die kanaal besit en laat die ander toestand daaruit lees, want hierdie koppelvlak verleen administratiewe handelinge en behoort in elk geval nie buite die gasheer blootgestel te word nie.

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

Leg die nuwe basislyne en die verbruikstoename saam vas, sodat die herspeling van 'n monster niks hef in plaas van twee keer te hef. 'n Teller wat agteruit beweeg is 'n sein, nie 'n skuld nie: dit beteken die sessie is vervang of die daemon is herbegin, en die korrekte reaksie is om die sessie-identiteit te versoen eerder as om 'n negatiewe bedrag te krediteer.

Die ontkoppelpad verg dieselfde sorg. As 'n finale gebeurtenis einde-van-sessie-totale dra, hef slegs die verskil van die laas vasgelegde monster. Om die volle totaal by te voeg nadat periodieke monstering reeds gehef is, is die mees algemene dubbele telling in selfgeboude kwotastelsels. Sessies wat oor 'n periodegrens strek, het ook 'n reël nodig, want een finale totaal dra geen inligting oor wanneer die grepe middernag oorgesteek het nie.

Laat uitputting toelating weier, nie net die tonnel doodmaak nie

Wanneer 'n rekening sy limiet bereik, moet twee dinge gebeur: bestaande sessies eindig, en nuwes word geweier. Die bestuursprotokol bied client-kill per kliënt-ID, wat die eerste helfte hanteer solank jy elke lewende sessie vir die rekening opsom in plaas daarvan om die een adres dood te maak wat jy toevallig raakgesien het.

Die tweede helfte is waar kwota-ontwerpe misluk. 'n Doodmaak alleen is 'n wedloop teen die kliënt se herverbindingslus, wat met graagte sekondes later terugkom. Toelating moet die gedeelde grootboek raadpleeg, en op 'n multi-poort-ontplooiing kan daardie kontrole nie 'n per-masjien-lêer wees nie. Elke instansie wat 'n aanmelding kan aanvaar, moet dieselfde uitgeputte toestand sien.

Tokengebaseerde herverbindings verdien hul eie toets. OpenVPN 2.6 kan 'n sessietoken intern valideer met auth-gen-token, en slaan die eksterne verifikasie-oproep oor wat jou kontroleerder gebruik het om die perk af te dwing. 'n Token wat nog geldig is, bewys dus identiteit, nie oorblywende kwota nie, en elke nuwe kliëntinstansie moet steeds die grootboek raadpleeg. As jy eerder management-client-auth aktiveer, word die kontroleerder die verifieerder en erf hy die verpligting om sessietoestand te ontleed en verstrykte of ongeldige tokens self te verwerp.

Aanvaar die oorskiet wat die monstering skep

Periodieke waarneming plus ontkoppeling gee jou 'n gemonsterde kwota met 'n bekende toleransie. 'n Kliënt kan ongeveer een rapporteringsinterval plus die tyd wat die kontroleerder nodig het om op te tree, oorskiet, en gelyktydige sessies op een rekening vermenigvuldig daardie venster. Sê so in die koppelvlak in plaas daarvan om 'n presiese laaste-greep-afsnit te adverteer wat jy nie kan lewer nie.

'n Werklike harde plafon is 'n ander ingenieursprobleem: handhawing binne die deurstuurpad, gebind aan dieselfde rekening oor sessies heen. Tellers vinniger lees is nie dieselfde ding nie, en dit oorleef nie 'n kliënt wat bloot meer tonnels oopmaak nie.

Voor ontplooiing, hardloop die aanvaardinggevalle wat naïewe implementerings breek: herhaalde herverbindings, twee toestelle gelyktydig, kontroleerder- en poortherbebuttings, 'n verlore ontkoppelgebeurtenis, 'n oorskakeling midde-in 'n sessie, en 'n tokenherverbinding wat reg ná uitputting probeer word. Besluit dan die foutmodus vir rekeningkundige onderbrekings. 'n Duursame grootboek beskerm die verbruik wat jy aangeteken het; dit kan nie waarnemings herstel wat nooit aangekom het nie, en die kliënt verdien om te weet in watter van daardie twee situasies hy is.