Hvor en månedlig datakvote hører hjemme per OpenVPN-konto

En kvote som nullstilles hver gang tunnelen kobles til på nytt, er ikke en grense, og det er nøyaktig det man får når en bytteteller boltes på en VPN-server uten et sted å lagre varig tilstand. Telleren tilhører en økt; kvoten tilhører en person eller en enhetskontrakt. All vanskeligheten med funksjonen kommer fra denne uoverensstemmelsen, så kontrollene nedenfor handler om hvor tilstanden bor og hvilket lag som har lov til å bestemme.

Fest kvoten til en konto, ikke til en tunnel

Begynn med å navngi kvotens subjekt. Én person kan ha tre enhetssertifikater, og ingen av dem bør få et uavhengig månedlig budsjett bare fordi de autentiserer seg separat. En stabil kontoidentifikator som overlever gjenoppkoblinger, nye tunneladresser og en flytting til en annen gateway, er det eneste ankeret en kvote kan bruke. Et sertifikats fellesnavn fungerer som den nøkkelen bare når utstedelsespolitikken din garanterer én konto per navn.

En tildelt tunneladresse er aldri svaret. Adresser resirkuleres, bassenger deles, og samme konto kan dukke opp to ganger på to gatewayer i samme minutt. Hvis hovedboken nøkler på en adresse, er det nok å koble fra og til på nytt for å fylle tanken igjen.

Registrer nok per økt til at regnestykket kan revideres: kontoen, faktureringsperioden, gateway-forekomsten, øktens identitet, de sist observerte tellerne og den fastsatte summen. Ta med en daemon-startgenerasjon i øktens identitet, fordi en omstartet server gjenbruker klient-ID-er, og en naiv sammenstilling ville arve forrige grunnlinje.

Fastsett enhet, retning og nullstillingsgrense

Fire definisjoner må fastsettes skriftlig før noen innsamling begynner. Teller kvoten byte klienten sender, byte den mottar, eller summen av begge? Er en gigabyte 10^9 byte eller 2^30? På hvilken lokal time og i hvilken tidssone ruller perioden over? Og hva måler telleren egentlig, når tunnel-overhead og retransmisjoner er inkludert, mens applikasjonsfilens størrelse og en leverandørs faktura ikke er det?

Ingen av disse valgene er feil, men implementasjonen og tallet kunden ser må stemme overens. To halvdeler av samme system som er uenige om GiB, eller om en overgang som skjer ved midnatt UTC i stedet for lokal tid, produserer nøyaktig den typen billett som undergraver tilliten til hele kvoten.

Gjør byttetotaler om til én belastet delta

Administrasjonsgrensesnittet rapporterer periodiske BYTECOUNT_CLI-linjer som bærer en klient-ID pluss kumulative byttetotaler i hver retning, og kommandoen bytecount angir hvor ofte de kommer. Fra serverens synspunkt teller det mottatte tallet bytene klienten sendte, og det sendte tallet teller bytene som ble levert til den. Sett intervallet til noe hovedboken kan absorbere; et svært kort intervall kjøper en presisjon du faktisk ikke får.

Én begrensning former hele designet: administrasjonssokkelen godtar én enkelt kontrolltilkobling. En overvåkingseksportør, en GUI og kontrolleren din kan ikke hver åpne sin egen. Bestem hvilken prosess som eier kanalen og la de andre lese tilstand fra den, fordi dette grensesnittet gir administrative handlinger og uansett ikke bør eksponeres utenfor verten.

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

Fest de nye grunnlinjene og forbruksøkningen sammen, slik at avspilling av en prøve belaster ingenting i stedet for å belaste to ganger. En teller som beveger seg bakover er et signal, ikke gjeld: det betyr at økten ble erstattet eller at daemonen ble omstartet, og riktig svar er å avstemme øktens identitet i stedet for å kreditere et negativt beløp.

Frakoblingsveien trenger samme omhu. Hvis en endelig hendelse bærer totaler ved øktens slutt, belast bare differansen fra den siste fastsatte prøven. Å legge til hele totalen etter at periodisk prøvetaking allerede er belastet, er den vanligste dobbelttellingen i hjemmelagde kvotesystemer. Økter som krysser en periodegrense trenger også en regel, siden én endelig total ikke bærer informasjon om når bytene passerte midnatt.

Uttømming skal avvise innslipp, ikke bare drepe tunnelen

Når en konto når grensen sin, må to ting skje: eksisterende økter avsluttes, og nye avvises. Administrasjonsprotokollen tilbyr client-kill per klient-ID, som håndterer den første halvdelen så lenge du lister opp hver levende økt for kontoen i stedet for å drepe den ene adressen du tilfeldigvis la merke til.

Den andre halvdelen er der kvotedesign svikter. En drap alene er et kappløp med klientens gjenoppkoblingsløkke, som gjerne kommer tilbake sekunder senere. Innslipp må konsultere den delte hovedboken, og i en utrulling med flere gatewayer kan den kontrollen ikke være en fil per maskin. Hver forekomst som kan godta en innlogging, må se den samme uttømte tilstanden.

Tokenbaserte gjenoppkoblinger fortjener sin egen test. OpenVPN 2.6 kan validere et sesjonstoken internt med auth-gen-token og hoppe over det eksterne autentiseringskallet som kontrolleren din brukte for å håndheve taket. Et token som fortsatt er gyldig beviser derfor identitet, ikke gjenværende kvote, og hver ny klientforekomst må fortsatt konsultere hovedboken. Hvis du i stedet aktiverer management-client-auth, blir kontrolleren autentiseringsenheten og arver plikten til selv å analysere øktens tilstand og avvise utløpte eller ugyldige tokens.

Aksepter overkjøringen som prøvetakingen skaper

Periodisk observasjon pluss frakobling gir deg en prøvetatt kvote med kjent toleranse. En klient kan overskride med omtrent ett rapporteringsintervall pluss tiden kontrolleren trenger for å handle, og samtidige økter på én konto multipliserer det vinduet. Si det i grensesnittet i stedet for å annonsere et nøyaktig kutt ved siste byte som du ikke kan levere.

Et virkelig hardt tak er et annet ingeniørproblem: håndheving inne i videresendingsveien, knyttet til samme konto på tvers av økter. Å lese tellere raskere er ikke det samme, og det overlever ikke en klient som bare åpner flere tunneler.

Før utrulling, kjør aksepttilfellene som bryter naive implementasjoner: gjentatte gjenoppkoblinger, to enheter samtidig, omstart av kontroller og gateway, en tapt frakoblingshendelse, en overgang midt i en økt og et token-gjenoppkoblingsforsøk rett etter uttømming. Bestem deretter feilmodusen for avbrudd i regnskapet. En varig hovedbok beskytter forbruket du registrerte; den kan ikke gjenopplive observasjoner som aldri ankom, og kunden fortjener å vite hvilken av de to situasjonene de er i.