Var en månatlig datakvot hör hemma per OpenVPN-konto

En kvot som nollställs varje gång tunneln återansluter är ingen gräns, och det är precis vad man får när en byteräknare skruvas fast på en VPN-server utan en plats för varaktigt tillstånd. Räknaren tillhör en session; kvoten tillhör en person eller ett enhetsavtal. All svårighet med funktionen kommer från denna missanpassning, så kontrollerna nedan handlar om var tillståndet bor och vilket lager som får besluta.

Fäst kvoten vid ett konto, inte vid en tunnel

Börja med att namnge kvotens subjekt. En person kan ha tre enhetscertifikat, och inget av dem bör få en oberoende månadsbudget bara för att de autentiserar sig separat. En stabil kontoidentifierare som överlever återanslutningar, nya tunneladresser och en flytt till en andra gateway är det enda ankaret en kvot kan använda. Ett certifikats vanliga namn fungerar som den nyckeln bara när din utfärdandepolicy garanterar ett konto per namn.

En tilldelad tunneladress är aldrig svaret. Adresser återanvänds, pooler delas, och samma konto kan dyka upp två gånger på två gateways i samma minut. Om huvudboken nycklar på en adress räcker det att koppla från och återansluta för att fylla tanken igen.

Registrera tillräckligt per session för att aritmetiken ska vara granskningsbar: kontot, faktureringsperioden, gateway-instansen, sessionens identitet, de senast observerade räknarna och den fastställda summan. Ta med en daemon-startgeneration i sessionens identitet, eftersom en omstartad server återanvänder klient-ID:n och en naiv matchning skulle ärva den tidigare baslinjen.

Fastställ enhet, riktning och nollställningsgräns

Fyra definitioner måste fastställas skriftligt innan någon insamling börjar. Räknar kvoten byte som klienten skickar, byte som den tar emot, eller summan av båda? Är en gigabyte 10^9 byte eller 2^30? Vid vilken lokal timme och i vilken tidszon rullar perioden över? Och vad mäter räknaren egentligen, när tunnel-overhead och omsändningar ingår medan programfilens storlek och en leverantörs faktura inte gör det?

Inget av dessa val är fel, men implementeringen och talet som kunden ser måste stämma överens. Två halvor av samma system som är oense om GiB, eller om ett omslag som sker vid midnatt UTC i stället för lokal tid, producerar precis den typ av biljett som urholkar förtroendet för hela kvoten.

Gör bytetotaler till en enda debiterad delta

Administrationsgränssnittet rapporterar periodiska BYTECOUNT_CLI-rader som bär ett klient-ID plus kumulativa bytetotaler i varje riktning, och kommandot bytecount anger hur ofta de anländer. Från serverns synvinkel räknar det mottagna talet byten som klienten skickat och det skickade talet räknar byten som levererats till den. Sätt intervallet till något som huvudboken kan absorbera; ett mycket kort intervall köper en precision du faktiskt inte får.

En begränsning formar hela designen: administrationsuttaget accepterar en enda styranslutning. En övervakningsexportör, ett GUI och din styrenhet kan inte var och en öppna sin egen. Bestäm vilken process som äger kanalen och låt de andra läsa tillstånd från den, eftersom detta gränssnitt ger administrativa åtgärder och hur som helst inte bör exponeras utanför värden.

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

Fäst de nya baslinjerna och användningsökningen tillsammans, så att uppspelning av ett prov debiterar ingenting i stället för att debitera två gånger. En räknare som rör sig bakåt är en signal, inte en skuld: det betyder att sessionen ersattes eller att daemonen startades om, och rätt svar är att stämma av sessionens identitet i stället för att kreditera ett negativt belopp.

Frånkopplingsvägen kräver samma omsorg. Om en slutlig händelse bär totaler vid sessionens slut, debitera bara skillnaden mot det senast fastställda provet. Att lägga till hela totalen efter att periodisk provtagning redan debiterats är den vanligaste dubbla räkningen i egenbyggda kvotsystem. Sessioner som korsar en periodgräns behöver också en regel, eftersom en enda sluttotal inte bär information om när byten passerade midnatt.

Uttömning ska neka insläpp, inte bara döda tunneln

När ett konto når sin gräns måste två saker hända: befintliga sessioner avslutas och nya nekas. Administrationsprotokollet erbjuder client-kill per klient-ID, vilket hanterar den första halvan så länge du räknar upp varje levande session för kontot i stället för att döda den enda adress du råkade lägga märke till.

Den andra halvan är där kvotdesigner misslyckas. Enbart dödande är en kapplöpning med klientens återanslutningsloop, som gärna kommer tillbaka sekunder senare. Insläppet måste rådfråga den delade huvudboken, och i en utrullning med flera gateways kan den kontrollen inte vara en fil per maskin. Varje instans som kan acceptera en inloggning måste se samma uttömda tillstånd.

Tokenbaserade återanslutningar förtjänar sitt eget test. OpenVPN 2.6 kan validera en sessionstoken internt med auth-gen-token och hoppa över det externa autentiseringsanropet som din styrenhet använde för att upprätthålla taket. En token som fortfarande är giltig bevisar därför identitet, inte återstående kvot, och varje ny klientinstans måste fortfarande rådfråga huvudboken. Om du i stället aktiverar management-client-auth blir styrenheten autentiseraren och ärver skyldigheten att själv analysera sessionstillståndet och neka utgångna eller ogiltiga tokens.

Acceptera den överkörning som provtagningen skapar

Periodisk observation plus frånkoppling ger dig en provtagen kvot med en känd tolerans. En klient kan överskrida med ungefär ett rapporteringsintervall plus den tid styrenheten behöver för att agera, och samtidiga sessioner på ett konto multiplicerar det fönstret. Säg det i gränssnittet i stället för att annonsera en exakt avskärning vid sista byten som du inte kan leverera.

Ett verkligt hårt tak är ett annat ingenjörsproblem: upprätthållande inne i vidarebefordringsvägen, knutet till samma konto över sessioner. Att läsa räknare snabbare är inte samma sak, och det överlever inte en klient som helt enkelt öppnar fler tunnlar.

Före utrullning, kör de acceptansfall som bryter naiva implementationer: upprepade återanslutningar, två enheter samtidigt, omstarter av styrenhet och gateway, en förlorad frånkopplingshändelse, ett omslag mitt i en session och ett token-återanslutningsförsök direkt efter uttömning. Bestäm sedan felläget för avbrott i redovisningen. En varaktig huvudbok skyddar den användning du registrerade; den kan inte återuppliva observationer som aldrig anlände, och kunden förtjänar att veta vilken av de två situationerna den är i.