Kam patří měsíční datová kvóta u účtu OpenVPN

Kvóta, která se resetuje při každém opětovném připojení tunelu, není limit, a přesně to dostanete, když se počítadlo bajtů přišroubuje k serveru VPN bez místa pro trvalý stav. Počítadlo patří relaci; kvóta patří osobě nebo smlouvě o zařízení. Vše obtížné na této funkci pramení z tohoto nesouladu, proto se níže uvedené kontroly týkají toho, kde žije stav a které vrstvě je dovoleno rozhodovat.

Připoutejte kvótu k účtu, ne k tunelu

Začněte pojmenováním subjektu kvóty. Jeden člověk může mít tři certifikáty zařízení a žádný z nich by neměl dostat nezávislý měsíční rozpočet jen proto, že se ověřuje zvlášť. Stabilní identifikátor účtu, který přežije opětovná připojení, nové adresy tunelu i přesun na druhou bránu, je jediná kotva, kterou kvóta může použít. Obecné jméno certifikátu funguje jako takový klíč jen tehdy, když vaše politika vydávání zaručuje jeden účet na jméno.

Přidělená adresa tunelu není nikdy odpověď. Adresy se recyklují, fondy se sdílejí a stejný účet se může objevit dvakrát na dvou bránách ve stejné minutě. Pokud se kniha vede podle adresy, odpojení a opětovné připojení stačí k doplnění nádrže.

Zaznamenávejte na relaci dostatek údajů, aby byla aritmetika auditovatelná: účet, zúčtovací období, instance brány, identitu relace, naposledy pozorovaná počítadla a potvrzený součet. Zahrňte do identity relace generaci startu démona, protože restartovaný server znovu používá ID klientů a naivní shoda by zdědila předchozí základní linii.

Určete jednotku, směr a hranici resetu

Před zahájením jakéhokoli sběru je třeba písemně ujasnit čtyři definice. Počítá kvóta bajty, které klient odešle, bajty, které přijme, nebo součet obojího? Je gigabajt 10^9 bajtů, nebo 2^30? Ve kterou místní hodinu a v jakém časovém pásmu se období překlápí? A co přesně počítadlo měří, když jsou zahrnuty režie tunelu a opakované přenosy, zatímco velikost souboru aplikace a faktura poskytovatele nikoli?

Žádná z těchto voleb není špatná, ale implementace a číslo, které vidí zákazník, se musí shodovat. Dvě poloviny stejného systému, které se neshodnou na GiB nebo na překlopení o půlnoci UTC místo místního času, produkují přesně ten typ tiketu, který podkopává důvěru v celou kvótu.

Převeďte součty bajtů na jednu účtovanou deltu

Rozhraní pro správu hlásí pravidelné řádky BYTECOUNT_CLI nesoucí ID klienta a kumulativní součty bajtů v každém směru a příkaz bytecount určuje, jak často přicházejí. Z pohledu serveru přijatá hodnota počítá bajty, které klient odeslal, a odeslaná hodnota počítá bajty doručené jemu. Nastavte interval na něco, co kniha zvládne vstřebat; velmi krátký interval kupuje přesnost, kterou ve skutečnosti nedostanete.

Celý návrh formuje jedno omezení: soket pro správu přijímá jediné řídicí spojení. Exportér monitoringu, GUI a váš kontroler si nemohou každý otevřít vlastní. Rozhodněte, který proces kanál vlastní, a nechte ostatní číst stav z něj, protože toto rozhraní uděluje administrativní akce a stejně by nemělo být vystaveno mimo hostitele.

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

Potvrzujte nové základní linie a přírůstek spotřeby společně, aby přehrání vzorku neúčtovalo nic místo dvojího účtování. Počítadlo, které se posouvá zpět, je signál, ne dluh: znamená, že relace byla nahrazena nebo se démon restartoval, a správnou reakcí je sladit identitu relace, nikoli připsat zápornou částku.

Cesta odpojení vyžaduje stejnou péči. Pokud závěrečná událost nese součty na konci relace, účtujte pouze rozdíl od posledního potvrzeného vzorku. Přidání plného součtu poté, co už bylo pravidelné vzorkování účtováno, je nejčastějším dvojím počítáním v domácích kvótních systémech. Relace, které překračují hranici období, také potřebují pravidlo, protože jediný závěrečný součet nenese informaci o tom, kdy bajty přešly půlnoc.

Ať vyčerpání odmítne vstup, ne jen zabije tunel

Když účet dosáhne svého limitu, musí se stát dvě věci: stávající relace skončí a nové se odmítnou. Protokol pro správu nabízí client-kill podle ID klienta, což řeší první polovinu, pokud vyjmenujete každou živou relaci účtu, místo abyste zabili jednu adresu, které jste si náhodou všimli.

Druhá polovina je místo, kde kvótní návrhy selhávají. Samotné zabití je závod s klientovou smyčkou opětovného připojení, která se ochotně vrátí o několik sekund později. Vstup musí konzultovat sdílenou knihu a při nasazení s více bránami nemůže být tato kontrola souborem na každém stroji. Každá instance, která může přijmout přihlášení, musí vidět stejný vyčerpaný stav.

Opětovná připojení založená na tokenech si zaslouží vlastní test. OpenVPN 2.6 umí ověřit token relace interně pomocí auth-gen-token a přeskočit externí volání ověření, které váš kontroler používal k vymáhání stropu. Token, který je stále platný, tedy prokazuje identitu, nikoli zbývající kvótu, a každá nová instance klienta musí knihu stejně konzultovat. Pokud místo toho zapnete management-client-auth, kontroler se stane autentizátorem a zdědí povinnost sám analyzovat stav relace a odmítat propadlé nebo neplatné tokeny.

Přijměte překročení, které vzorkování vytváří

Pravidelné pozorování plus odpojení vám dávají vzorkovanou kvótu se známou tolerancí. Klient může překročit zhruba o jeden interval hlášení plus čas, který kontroler potřebuje k zásahu, a souběžné relace na jednom účtu toto okno násobí. Řekněte to v rozhraní, místo abyste inzerovali přesný řez na posledním bajtu, který nedokážete dodat.

Skutečný tvrdý strop je jiný inženýrský problém: vynucení uvnitř předávací cesty, svázané se stejným účtem napříč relacemi. Rychlejší čtení počítadel není totéž a nepřežije klienta, který prostě otevře více tunelů.

Před nasazením spusťte akceptační případy, které lámou naivní implementace: opakovaná připojení, dvě zařízení najednou, restarty kontroleru a brány, ztracená událost odpojení, překlopení uprostřed relace a pokus o opětovné připojení tokenem hned po vyčerpání. Poté rozhodněte o režimu selhání při výpadcích účtování. Trvalá kniha chrání spotřebu, kterou jste zaznamenali; nedokáže vzkřísit pozorování, která nikdy nedorazila, a zákazník si zaslouží vědět, ve které z těchto dvou situací je.