Hvar mánaðarleg gagnakvóti á að eiga heima fyrir hvert OpenVPN-tékka

Kvóti sem endurstillist í hvert sinn sem göngin tengjast aftur er ekki takmörk, og það er einmitt það sem fæst þegar bætarteljara er skrúfað á VPN-þjón án staðar til að geyma varanlegt ástand. Teljarinn tilheyrir lotu; kvótinn tilheyrir manneskju eða tækjasamningi. Öll erfiðleikarnir við eiginleikann koma frá þessu misræmi, svo prófanirnar hér fyrir neðan snúast um hvar ástand býr og hvaða lag má ákveða.

Festið kvótann við tékka, ekki göng

Byrjið á að nefna viðfang kvótans. Ein manneskja getur haft þrjú tækjaskírteini, og ekkert þeirra ætti að fá sjálfstætt mánaðarlegt fjárhagsáætlun bara vegna þess að þau auðkenna sig sér. Stöðugur tékkaauðkenni sem lifir endurtengingar, ný gönguslóð og flutning á annað gátt er eini akkerið sem kvóti getur notað. Almennt nafn skírteinis virkar sem þessi lykill aðeins ef útgáfustefna þín tryggir eitt tékka fyrir hvert nafn.

Úthlutað gagnaslóð er aldrei svarið. Slóðum er endurnýtt, laugum er deilt, og sami tékki getur birst tvisvar á tveimur gáttum á sömu mínútu. Ef höfuðbókin lyklar á slóð er nóg að aftengja og tengja aftur til að fylla tankinn á ný.

Skráðu nóg fyrir hverja lotu svo reikningurinn sé endurskoðanlegur: tékkið, uppgjörstímabilið, gáttardæmið, auðkenni lotunnar, síðustu teljarar sem séust og heildarupphæðin sem skuldbundin er. Láttu kynslóð ræsingar daemons fylgja auðkenni lotunnar, því endurræstur þjónn endurnýtir auðkenni biðlara og barnaleg samsvörun myndi erfa fyrri grunnlínu.

Festu eininguna, stefnuna og endurstillingarmörkin

Fjórar skilgreiningar verða að vera skriflegar áður en nokkur söfnun hefst. Telur kvótinn bæti sem biðlarinn sendir, bæti sem hann tekur við, eða summu beggja? Er gígabæti 10^9 bæti eða 2^30? Á hvaða staðartíma og í hvaða tímabelti snýst tímabilið? Og hvað mælir teljarinn nákvæmlega, þar sem yfirhöfn ganganna og endursendingar eru innifaldar en skráarstærð forritsins og reikningur þjónustuveitanda ekki?

Ekkert þessara vala er rangt, en útfærslan og talan sem viðskiptavinurinn sér verða að stemma. Tveir helmingar sama kerfis sem eru ósammála um GiB, eða um snúning sem á sér stað á miðnætti UTC í stað staðartíma, framleiða einmitt þá tegund miða sem veðrar traust á öllum kvótanum.

Gerðu bætaheildir að einum rukkuðum mun

Stjórnviðmótið tilkynnir reglulegar BYTECOUNT_CLI línur sem bera biðlaraauðkenni ásamt uppsöfnuðum bætaheildum í hvora átt, og bytecount skipunin stillir hversu oft þær berast. Frá sjónarhóli þjónsins telur móttekin tala bætin sem biðlarinn sendi og senda talan telur bætin sem honum voru afhent. Stilltu bilið á eitthvað sem höfuðbókin getur melt; mjög stutt bil kaupir nákvæmni sem þú færð í raun ekki.

Ein takmörkun mótar alla hönnunina: stjórnsokkurinn tekur við einni stjórntengingu. Vöktunarexportari, GUI og stýringin þín geta ekki hvert opnað sína. Ákveddu hvaða ferli á rásina og láttu hin lesa ástand úr henni, því þetta viðmót veitir stjórnunaraðgerðir og ætti hvort eð er ekki að vera berskjaldað utan hýsilsins.

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

Skuldbindtu nýju grunnlínurnar og notkunarvöxtinn saman, svo að endursköpun sýnis rukki ekkert í stað þess að rukka tvisvar. Teljari sem hreyfist aftur á bak er merki, ekki skuld: það þýðir að lotunni var skipt eða daemon endurræstur, og rétta svarið er að sætta auðkenni lotunnar í stað þess að lána neikvæða upphæð.

Rofleiðin þarf sömu umhyggju. Ef lokaatburður ber heildartölur lotuloka, rukkaðu aðeins muninn frá síðasta skuldbundna sýni. Að bæta fullri heild við eftir að reglubundin sýnataka hefur þegar verið rukkuð er algengasta tvöfaldi talningin í heimagerðum kvótakerfum. Lotur sem spanna tímabilamörk þurfa líka reglu, því ein loksheild ber engar upplýsingar um hvenær bætin fóru yfir miðnætti.

Upptaka synji aðgangi, ekki bara drepur göngin

Þegar tékki nær takmörkum sínum verða tveir hlutir að gerast: núverandi lotur enda og nýjum er hafnað. Stjórnunarprotokollið býður upp á client-kill eftir biðlaraauðkenni, sem sér um fyrri helminginn svo framarlega sem þú telur upp hverja lifandi lotu fyrir tékkið í stað þess að drepa einu slóðina sem þú tókst eftir.

Seinni helmingurinn er þar sem kvótahönnun bregst. Eitt dráp er kapphlaup við endurtengingarlykkju biðlarans, sem kemur fús aftur nokkrum sekúndum síðar. Aðgangur verður að ráðfæra sig við sameiginlegu höfuðbókina, og í uppsetningu með mörgum gáttum getur sú prófun ekki verið skrá á hverri vél. Hvert dæmi sem getur tekið við innskráningu verður að sjá sama upptekna ástand.

Endurtengingar byggðar á tákni eiga skilið eigin próf. OpenVPN 2.6 getur staðfest lotutákn innan frá með auth-gen-token og sleppt ytri auðkenningarkallinu sem stýringin þín notaði til að framfylgja þakinu. Tákn sem enn er gilt sannar því auðkenni, ekki eftirstöðvar kvóta, og hvert nýtt biðlaradæmi verður samt að ráðfæra sig við höfuðbókina. Ef þú virkjar management-client-auth í staðinn verður stýringin auðkenningaraðilinn og erfir skylduna að greina stöðu lotunnar og hafna útrunnum eða ógildum táknum sjálf.

Samþykktu umskotið sem sýnatakan skapar

Reglubundin athugun ásamt aftengingu gefur þér sýnatökukvóta með þekktri umburðarlyndi. Biðlari getur farið fram úr um það bil eitt skýrslubil ásamt þeim tíma sem stýringin þarf til að bregðast við, og samtímis lotur á einum tékka margfalda þann glugga. Segðu það í viðmótinu í stað þess að auglýsa nákvæman skurð á síðasta bæti sem þú getur ekki afhent.

Raunverulegt hart þak er annað verkfræðivandamál: framfylgd inni í framsendingarleiðinni, bundin sama tékka yfir lotur. Að lesa teljara hraðar er ekki það sama, og það lifir ekki af biðlara sem einfaldlega opnar fleiri göng.

Fyrir útgáfu skaltu keyra samþykktartilfellin sem brjóta barnalegar útfærslur: endurteknar endurtengingar, tvö tæki í einu, endurræsingar stýringar og gáttar, tapaður aftengingaratburður, snúningur mitt í lotu og tilraun til táknendurtengingar rétt eftir upptöku. Ákveddu síðan bilunarham fyrir truflanir í bókhaldi. Varanleg höfuðbók verndar notkunina sem þú skráðir; hún getur ekki reist athuganir sem aldrei bárust við og viðskiptavinurinn á skilið að vita hvorri af þessum tveimur aðstæðum hann er í.