Kam patrí mesačná dátová kvóta na účet OpenVPN

Kvóta, ktorá sa resetuje pri každom opätovnom pripojení tunela, nie je limit, a presne to dostanete, keď sa počítadlo bajtov priskrutkuje k serveru VPN bez miesta na trvalý stav. Počítadlo patrí relácii; kvóta patrí osobe alebo zmluve o zariadení. Celá náročnosť funkcie pramení z tohto nesúladu, preto sa nižšie uvedené kontroly týkajú toho, kde žije stav a ktorá vrstva smie rozhodovať.

Pripevnite kvótu k účtu, nie k tunelu

Začnite pomenovaním subjektu kvóty. Jeden človek môže mať tri certifikáty zariadení a žiadny z nich by nemal dostať nezávislý mesačný rozpočet len preto, že sa overuje samostatne. Stabilný identifikátor účtu, ktorý prežije opätovné pripojenia, nové adresy tunela aj presun na druhú bránu, je jediná kotva, ktorú môže kvóta použiť. Všeobecný názov certifikátu funguje ako taký kľúč len vtedy, keď vaša politika vydávania zaručuje jeden účet na názov.

Pridelená adresa tunela nie je nikdy odpoveď. Adresy sa recyklujú, fondy sa zdieľajú a ten istý účet sa môže objaviť dvakrát na dvoch bránach v tej istej minúte. Ak sa kniha vedie podľa adresy, odpojenie a opätovné pripojenie stačí na to, aby sa nádrž znova naplnila.

Zaznamenávajte na reláciu dosť údajov, aby bola aritmetika auditovateľná: účet, zúčtovacie obdobie, inštanciu brány, identitu relácie, naposledy pozorované počítadlá a potvrdený súčet. Zahrňte do identity relácie generáciu štartu démona, pretože reštartovaný server znova používa ID klientov a naivné porovnanie by zdedilo predchádzajúcu základnú líniu.

Určite jednotku, smer a hranicu resetu

Pred začiatkom akéhokoľvek zberu treba písomne určiť štyri definície. Počíta kvóta bajty, ktoré klient odošle, ktoré prijme, alebo súčet oboch? Je gigabajt 10^9 bajtov alebo 2^30? V ktorú miestnu hodinu a v ktorom časovom pásme sa obdobie preklápa? A čo presne počítadlo meria, keď sú zahrnuté réžia tunela a opakované prenosy, ale veľkosť súboru aplikácie a faktúra poskytovateľa nie?

Žiadna z týchto volieb nie je nesprávna, ale implementácia a číslo, ktoré zákazník vidí, sa musia zhodovať. Dve polovice toho istého systému, ktoré sa nezhodnú na GiB alebo na preklopení o polnoci UTC namiesto miestneho času, produkujú presne ten typ tiketu, ktorý podkopáva dôveru v celú kvótu.

Premeňte súčty bajtov na jednu účtovanú deltu

Rozhranie na správu hlási pravidelné riadky BYTECOUNT_CLI nesúce ID klienta a kumulatívne súčty bajtov v každom smere a príkaz bytecount určuje, ako často prichádzajú. Z pohľadu servera prijatá hodnota počíta bajty, ktoré klient odoslal, a odoslaná hodnota počíta bajty doručené jemu. Nastavte interval na niečo, čo kniha dokáže vstrebať; veľmi krátky interval kupuje presnosť, ktorú v skutočnosti nedostanete.

Celý návrh formuje jedno obmedzenie: soket na správu prijíma jediné riadiace spojenie. Exportér monitorovania, GUI a váš kontrolér si nemôžu každý otvoriť vlastný. Rozhodnite, ktorý proces kanál vlastní, a nechajte ostatných čítať stav z neho, pretože toto rozhranie poskytuje administratívne akcie a tak či tak by nemalo byť vystavené mimo hostiteľa.

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

Potvrdzujte nové základné línie a prírastok spotreby spoločne, aby prehratie vzorky neúčtovalo nič namiesto dvojitého účtovania. Počítadlo, ktoré sa posúva späť, je signál, nie dlh: znamená, že relácia bola nahradená alebo sa démon reštartoval, a správnou reakciou je zosúladiť identitu relácie, nie pripísať zápornú sumu.

Cesta odpojenia vyžaduje rovnakú starostlivosť. Ak záverečná udalosť nesie súčty na konci relácie, účtujte iba rozdiel od poslednej potvrdenej vzorky. Pridanie plného súčtu po tom, čo už bolo pravidelné vzorkovanie účtované, je najčastejším dvojitým počítaním v domácich kvótových systémoch. Relácie, ktoré prekračujú hranicu obdobia, tiež potrebujú pravidlo, pretože jediný záverečný súčet neobsahuje informáciu o tom, kedy bajty prešli polnocou.

Vyčerpanie nech odmietne vstup, nie len zabije tunel

Keď účet dosiahne svoj limit, musia sa stať dve veci: existujúce relácie skončia a nové sa odmietnu. Protokol na správu ponúka client-kill podľa ID klienta, čo rieši prvú polovicu, ak vymenujete každú živú reláciu účtu namiesto toho, aby ste zabili jednu adresu, ktorú ste si náhodou všimli.

Druhá polovica je miesto, kde kvótové návrhy zlyhávajú. Samotné zabitie je pretek s cyklom opätovného pripojenia klienta, ktorý sa ochotne vráti o pár sekúnd. Vstup musí konzultovať zdieľanú knihu a pri nasadení s viacerými bránami táto kontrola nemôže byť súborom na každom stroji. Každá inštancia, ktorá môže prijať prihlásenie, musí vidieť rovnaký vyčerpaný stav.

Opätovné pripojenia založené na tokene si zaslúžia vlastný test. OpenVPN 2.6 dokáže overiť token relácie interne pomocou auth-gen-token a preskočiť externé volanie overenia, ktoré váš kontrolér používal na vymáhanie stropu. Token, ktorý je stále platný, teda preukazuje identitu, nie zostávajúcu kvótu, a každá nová inštancia klienta musí knihu naďalej konzultovať. Ak namiesto toho zapnete management-client-auth, kontrolér sa stane autentifikátorom a zdedí povinnosť sám analyzovať stav relácie a odmietať prepadnuté alebo neplatné tokeny.

Prijmite prekročenie, ktoré vytvára vzorkovanie

Pravidelné pozorovanie plus odpojenie vám dávajú vzorkovanú kvótu so známou toleranciou. Klient môže prekročiť zhruba o jeden interval hlásenia plus čas, ktorý kontrolér potrebuje na zásah, a súbežné relácie na jednom účte toto okno násobia. Povedzte to v rozhraní namiesto inzerovania presného odseknutia na poslednom bajte, ktoré nedokážete dodať.

Skutočný tvrdý strop je iný inžiniersky problém: vynútenie vnútri cesty preposielania, zviazané s tým istým účtom naprieč reláciami. Rýchlejšie čítanie počítadiel nie je to isté a neprežije klienta, ktorý jednoducho otvorí viac tunelov.

Pred nasadením spustite akceptačné prípady, ktoré lámu naivné implementácie: opakované pripojenia, dve zariadenia naraz, reštarty kontroléra a brány, stratená udalosť odpojenia, preklopenie uprostred relácie a pokus o opätovné pripojenie tokenom hneď po vyčerpaní. Potom rozhodnite režim zlyhania pri výpadkoch účtovania. Trvalá kniha chráni spotrebu, ktorú ste zaznamenali; nedokáže vzkriesiť pozorovania, ktoré nikdy nedorazili, a zákazník si zaslúži vedieť, v ktorej z týchto dvoch situácií je.