Kvar ein månadleg datakvote høyrer heime per OpenVPN-konto

Ein kvote som blir nullstilt kvar gong tunnelen koplar til på nytt, er ikkje ei grense, og det er nøyaktig det ein får når ein bytteteljar blir bolta på ein VPN-server utan ein stad å lagre varig tilstand. Teljaren høyrer til ein økt; kvoten høyrer til ein person eller ein einingskontrakt. All vanskane med funksjonen kjem frå denne uoverensstemminga, så kontrollane nedanfor handlar om kvar tilstanden bur og kva lag som har lov til å avgjere.

Fest kvoten til ein konto, ikkje til ein tunnel

Byrja med å namngje subjektet for kvoten. Éin person kan ha tre einingssertifikat, og ingen av dei bør få eit uavhengig månadleg budsjett berre fordi dei autentiserer seg kvar for seg. Ein stabil kontoidentifikator som overlever gjenoppkoplingar, nye tunneladresser og ei flytting til ein annan gateway, er det einaste ankeret ein kvote kan bruke. Eit sertifikats fellesnamn fungerer som den nøkkelen berre når utstedingspolitikken din garanterer éin konto per namn.

Ei tildelt tunneladresse er aldri svaret. Adresser blir resirkulerte, basseng blir delte, og same konto kan dukke opp to gonger på to gatewayar i same minutt. Viss hovudboka nøklar på ei adresse, er det nok å kople frå og til på nytt for å fylle tanken igjen.

Registrer nok per økt til at reknestykket kan reviderast: kontoen, faktureringsperioden, gateway-førekomsten, identiteten til økta, dei sist observerte teljarane og den fastsette summen. Ta med ein daemon-startgenerasjon i identiteten til økta, fordi ein omstarta server brukar klient-ID-ar på nytt, og ein naiv samanlikning ville arve førre grunnlinje.

Fastset eining, retning og nullstillingsgrense

Fire definisjonar må fastsetjast skriftleg før noka innsamling byrjar. Tel kvoten byte klienten sender, byte han tek imot, eller summen av begge? Er ein gigabyte 10^9 byte eller 2^30? På kva lokal time og i kva tidssone rullar perioden over? Og kva måler teljaren eigentleg, når tunnel-overhead og retransmisjonar er inkluderte, medan applikasjonsfilstorleiken og fakturaen frå ein leverandør ikkje er det?

Ingen av desse vala er feil, men implementasjonen og talet kunden ser må stemme. To halvdelar av same system som er usamde om GiB, eller om ein overgang som skjer ved midnatt UTC i staden for lokal tid, produserer nøyaktig den typen billett som undergrev tilliten til heile kvoten.

Gjer byttetotalar om til éin belasta delta

Administrasjonsgrensesnittet rapporterer periodiske BYTECOUNT_CLI-linjer som ber ein klient-ID pluss kumulative byttetotalar i kvar retning, og kommandoen bytecount set kor ofte dei kjem. Frå serveren sitt synspunkt tel det mottekne talet byta klienten sende, og det sende talet tel byta som vart leverte til han. Set intervallet til noko hovudboka kan absorbere; eit svært kort intervall kjøper ein presisjon du faktisk ikkje får.

Éi avgrensing formar heile designet: administrasjonssokkelen godtek éi enkel kontrolltilkopling. Ein overvakingseksportør, ein GUI og kontrolløren din kan ikkje kvar opne si eiga. Avgjer kva prosess som eig kanalen og la dei andre lese tilstand frå han, fordi dette grensesnittet gir administrative handlingar og uansett ikkje bør eksponerast utanfor 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 dei nye grunnlinjene og forbruksauken saman, slik at avspeling av ein prøve belastar ingenting i staden for å belaste to gonger. Ein teljar som flyttar seg bakover er eit signal, ikkje gjeld: det betyr at økta vart erstatta eller at daemonen vart omstarta, og det rette svaret er å avstemme identiteten til økta i staden for å kreditere eit negativt beløp.

Frakoplingsvegen treng same omhug. Viss ein endeleg hending ber totalar ved slutten av økta, belast berre skilnaden frå den sist fastsette prøva. Å leggje til heile totalen etter at periodisk prøvetaking allereie er belasta, er den vanlegaste dobbeltteljinga i heimelaga kvotesystem. Økter som kryssar ei periodegrense treng også ei regel, sidan éin endeleg total ikkje ber informasjon om når byta passerte midnatt.

Uttøming skal avvise innslepp, ikkje berre drepe tunnelen

Når ein konto når grensa si, må to ting skje: eksisterande økter blir avslutta, og nye blir avviste. Administrasjonsprotokollen tilbyr client-kill per klient-ID, som handterer den første halvdelen så lenge du listar opp kvar levande økt for kontoen i staden for å drepe den eine adressa du tilfeldigvis la merke til.

Den andre halvdelen er der kvotedesign sviktar. Eit drap åleine er eit kappløp med gjenoppkoplingløkka til klienten, som gjerne kjem tilbake sekund seinare. Innslepp må konsultere den delte hovudboka, og i ein utrulling med fleire gatewayar kan den kontrollen ikkje vere ei fil per maskin. Kvar førekomst som kan godta ein innlogging, må sjå den same uttømde tilstanden.

Tokenbaserte gjenoppkoplingar fortener sin eigen test. OpenVPN 2.6 kan validere eit sesjonstoken internt med auth-gen-token og hoppe over det eksterne autentiseringskallet som kontrolløren din brukte for å handheve taket. Eit token som framleis er gyldig beviser derfor identitet, ikkje gjenverande kvote, og kvar ny klientførekomst må framleis konsultere hovudboka. Viss du i staden aktiverer management-client-auth, blir kontrolløren autentiseringsseininga og arvar plikta til sjølv å analysere tilstanden til økta og avvise utløpte eller ugyldige token.

Godta overkøyringa som prøvetakinga skapar

Periodisk observasjon pluss frakopling gir deg ein prøveteken kvote med kjend toleranse. Ein klient kan overskride med omtrent eitt rapporteringsintervall pluss tida kontrolløren treng for å handle, og samtidige økter på éin konto multipliserer det vindauget. Sei det i grensesnittet i staden for å annonsere eit nøyaktig kutt ved siste byte som du ikkje kan levere.

Eit verkeleg hardt tak er eit anna ingeniørproblem: handheving inne i vidaresendingsvegen, knytt til same konto på tvers av økter. Å lese teljarar raskare er ikkje det same, og det overlever ikkje ein klient som berre opnar fleire tunnelar.

Før utrulling, køyr aksepttilfella som bryt naive implementasjonar: gjentekne gjenoppkoplingar, to einingar samtidig, omstart av kontrollør og gateway, ei tapt frakoplinghending, ein overgang midt i ei økt og eit token-gjenoppkoplingforsøk rett etter uttøming. Avgjer deretter feilmodusen for avbrot i rekneskapen. Ei varig hovudbok vernar forbruket du registrerte; ho kan ikkje gjenopplive observasjonar som aldri kom, og kunden fortener å vite kva av dei to situasjonane han er i.