Kam spada mesečna podatkovna kvota na račun OpenVPN

Kvota, ki se ponastavi vsakič, ko se tunel znova poveže, ni omejitev, in točno to dobimo, ko se števec bajtov privija na strežnik VPN brez mesta za trajno stanje. Števec pripada seji; kvota pripada osebi ali pogodbi o napravi. Vsa težavnost funkcije izhaja iz tega neskladja, zato se spodnje preverbe ukvarjajo s tem, kje živi stanje in kateri sloj sme odločati.

Kvoto pritrdite na račun, ne na tunel

Začnite z poimenovanjem subjekta kvote. Ena oseba ima lahko tri potrdila naprav in nobeno od njih ne bi smelo dobiti neodvisnega mesečnega proračuna samo zato, ker se preverja ločeno. Stabilen identifikator računa, ki preživi ponovne povezave, nove naslove tunela in selitev na drugo prehodno postajo, je edino sidro, ki ga kvota lahko uporabi. Splošno ime potrdila deluje kot ta ključ le, ko vaša politika izdajanja zagotavlja en račun na ime.

Dodeljeni naslov tunela nikoli ni odgovor. Naslovi se reciklirajo, bazeni se delijo in isti račun se lahko pojavi dvakrat na dveh prehodnih postajah v isti minuti. Če se knjiga vodi po naslovu, zadostujeta odklop in ponovna povezava, da se rezervoar znova napolni.

Zapišite dovolj na sejo, da bo aritmetika revizijsko sledljiva: račun, obračunsko obdobje, primerek prehodne postaje, identiteto seje, nazadnje opažene števce in potrjeni seštevek. V identiteto seje vključite generacijo zagona demona, ker ponovno zagnan strežnik znova uporabi ID-je odjemalcev in bi naivno ujemanje podedovalo prejšnjo osnovno črto.

Določite enoto, smer in mejo ponastavitve

Pred začetkom kakršnega koli zbiranja je treba pisno določiti štiri definicije. Ali kvota šteje bajte, ki jih odjemalec pošlje, ki jih prejme, ali vsoto obojega? Je gigabajt 10^9 bajtov ali 2^30? Ob kateri lokalni uri in v katerem časovnem pasu se obdobje obrne? In kaj točno meri števec, glede na to, da so vključeni stroški tunela in ponovni prenosi, medtem ko velikost datoteke aplikacije in račun ponudnika nista?

Nobena od teh izbir ni napačna, vendar se morata izvedba in število, ki ga vidi stranka, ujemati. Dve polovici istega sistema, ki se ne strinjata glede GiB ali glede obrata ob polnoči UTC namesto po lokalnem času, ustvarita točno tisto vrsto zahtevka, ki spodkopava zaupanje v celotno kvoto.

Pretvorite vsote bajtov v eno zaračunano razliko

Upravljalni vmesnik poroča periodične vrstice BYTECOUNT_CLI, ki nosijo ID odjemalca in kumulativne vsote bajtov v vsaki smeri, ukaz bytecount pa določi, kako pogosto prihajajo. S stališča strežnika prejeta številka šteje bajte, ki jih je odjemalec poslal, poslana številka pa bajte, ki so mu bili dostavljeni. Interval nastavite na nekaj, kar lahko knjiga absorbira; zelo kratek interval kupi natančnost, ki je v resnici ne dobite.

Ena omejitev oblikuje celotno zasnovo: upravljalni vtič sprejme eno samo krmilno povezavo. Izvoznik za spremljanje, GUI in vaš krmilnik ne morejo vsak odpreti svoje. Odločite, kateri proces ima kanal, in pustite drugim, da berejo stanje iz njega, ker ta vmesnik dodeljuje administrativna dejanja in tako ali tako ne bi smel biti izpostavljen zunaj gostitelja.

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

Potrdite nove osnovne črte in prirast porabe skupaj, da ponovno predvajanje vzorca ne zaračuna ničesar namesto dvakrat. Števec, ki se premika nazaj, je signal, ne dolg: pomeni, da je bila seja zamenjana ali da je bil demon znova zagnan, in pravilen odgovor je uskladiti identiteto seje, ne knjižiti negativnega zneska.

Pot odklopa zahteva enako skrbnost. Če končni dogodek nosi vsote ob koncu seje, zaračunajte le razliko od zadnjega potrjenega vzorca. Dodajanje celotne vsote potem, ko je bilo periodično vzorčenje že zaračunano, je najpogostejše dvojno štetje v doma narejenih sistemih kvot. Seje, ki prečkajo mejo obdobja, potrebujejo tudi pravilo, saj ena končna vsota ne nosi informacije o tem, kdaj so bajti prečkali polnoč.

Izčrpanje naj zavrne dostop, ne le ubije tunela

Ko račun doseže svojo mejo, se morata zgoditi dve stvari: obstoječe seje se končajo in nove se zavrnejo. Upravljalni protokol ponuja client-kill po ID-ju odjemalca, kar reši prvo polovico, če naštejete vsako živo sejo računa, namesto da ubijete en naslov, ki ste ga slučajno opazili.

Druga polovica je mesto, kjer zasnove kvot odpovedo. Samo ubijanje je tekma s ponovno povezovalno zanko odjemalca, ki se bo z veseljem vrnil nekaj sekund pozneje. Dostop mora upoštevati deljeno knjigo, pri namestitvi z več prehodnimi postajami pa to preverjanje ne more biti datoteka na vsakem stroju. Vsak primerek, ki lahko sprejme prijavo, mora videti isto izčrpano stanje.

Ponovne povezave na podlagi žetona si zaslužijo lasten test. OpenVPN 2.6 lahko interno preveri sejni žeton z auth-gen-token in preskoči zunanji klic overjanja, ki ga je vaš krmilnik uporabljal za uveljavljanje zgornje meje. Zato žeton, ki je še veljaven, dokazuje identiteto, ne preostale kvote, in vsak nov primerek odjemalca mora še vedno upoštevati knjigo. Če namesto tega omogočite management-client-auth, krmilnik postane overitelj in podeduje obveznost, da sam analizira stanje seje in zavrača potekle ali neveljavne žetone.

Sprejmite preseganje, ki ga ustvari vzorčenje

Periodično opazovanje in odklop vam dajeta vzorčeno kvoto z znano toleranco. Odjemalec lahko preseže za približno en interval poročanja plus čas, ki ga krmilnik potrebuje za ukrepanje, sočasne seje na enem računu pa to okno pomnožijo. Povejte to v vmesniku, namesto da oglašujete natančen odrez na zadnjem bajtu, ki ga ne morete zagotoviti.

Resnična trda zgornja meja je drug inženirski problem: uveljavljanje znotraj poti posredovanja, vezano na isti račun skozi seje. Hitrejše branje števcev ni isto in ne preživi odjemalca, ki preprosto odpre več tunelov.

Pred uvedbo zaženite sprejemne primere, ki zlomijo naivne izvedbe: ponavljajoče se ponovne povezave, dve napravi hkrati, ponovni zagoni krmilnika in prehodne postaje, izgubljen dogodek odklopa, obrat sredi seje in poskus ponovne povezave z žetonom takoj po izčrpanju. Nato določite način odpovedi za prekinitve v obračunu. Trajna knjiga ščiti zabeleženo porabo; ne more obuditi opazovanj, ki nikoli niso prispela, in stranka si zasluži vedeti, v kateri od teh dveh situacij je.