Waar een maandelijkse databundel per OpenVPN-account hoort

Een bundel die elke keer wordt gereset wanneer de tunnel opnieuw verbindt, is geen limiet, en dat is precies wat je krijgt wanneer een byteteller op een VPN-server wordt geschroefd zonder plek voor duurzame staat. De teller hoort bij een sessie; de bundel hoort bij een persoon of een apparaatcontract. Alle moeilijkheid van de functie komt uit die mismatch, dus de controles hieronder gaan over waar staat leeft en welke laag mag beslissen.

Koppel de bundel aan een account, niet aan een tunnel

Begin met het benoemen van het onderwerp van de bundel. Eén persoon kan drie apparaatcertificaten hebben, en geen daarvan zou een onafhankelijk maandbudget moeten krijgen alleen omdat ze apart authenticeren. Een stabiele accountidentificatie die herverbindingen, nieuwe tunneladressen en een verhuizing naar een tweede gateway overleeft, is het enige anker dat een bundel kan gebruiken. De common name van een certificaat werkt als die sleutel alleen wanneer je uitgiftebeleid één account per naam garandeert.

Een toegewezen tunneladres is nooit het antwoord. Adressen worden hergebruikt, pools worden gedeeld, en hetzelfde account kan twee keer op twee gateways verschijnen in dezelfde minuut. Als het grootboek op een adres sleutelt, is loskoppelen en opnieuw verbinden genoeg om de tank weer te vullen.

Leg per sessie genoeg vast om de rekensom controleerbaar te maken: het account, de factureringsperiode, de gateway-instantie, de sessie-identiteit, de laatst waargenomen tellers en het vastgelegde totaal. Neem een daemon-startgeneratie op in de sessie-identiteit, want een herstarte server hergebruikt client-ID's en een naïeve match zou de vorige basislijn erven.

Leg de eenheid, richting en resetgrens vast

Vier definities moeten schriftelijk worden vastgelegd voordat enige verzameling begint. Telt de bundel bytes die de client verstuurt, bytes die hij ontvangt, of de som van beide? Is een gigabyte 10^9 bytes of 2^30? Op welk lokaal uur en in welke tijdzone rolt de periode om? En wat meet de teller precies, aangezien tunnel-overhead en hertransmissies zijn inbegrepen terwijl de bestandsgrootte van de applicatie en de factuur van een provider dat niet zijn?

Geen van die keuzes is fout, maar de implementatie en het getal dat de klant ziet moeten overeenkomen. Twee helften van hetzelfde systeem die het oneens zijn over GiB, of over een omslag die om middernacht UTC plaatsvindt in plaats van lokale tijd, produceren precies het soort ticket dat het vertrouwen in de hele bundel ondermijnt.

Maak van bytetotalen één afgerekende delta

De beheerinterface rapporteert periodieke BYTECOUNT_CLI-regels die een client-ID plus cumulatieve bytetotalen per richting dragen, en het commando bytecount stelt in hoe vaak die binnenkomen. Vanuit het standpunt van de server telt het ontvangen getal de bytes die de client heeft gestuurd en het verzonden getal telt de bytes die aan hem zijn afgeleverd. Zet het interval op iets wat het grootboek kan absorberen; een zeer kort interval koopt precisie die je in werkelijkheid niet krijgt.

Eén beperking vormt het hele ontwerp: de beheersocket accepteert één enkele controleverbinding. Een monitoring-exporteur, een GUI en je controller kunnen niet elk hun eigen verbinding openen. Bepaal welk proces het kanaal bezit en laat de andere de staat daaruit lezen, want deze interface geeft administratieve acties en zou hoe dan ook niet buiten de host moeten worden blootgesteld.

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

Leg de nieuwe basislijnen en de gebruikstoename samen vast, zodat het opnieuw afspelen van een sample niets in rekening brengt in plaats van dubbel te rekenen. Een teller die achteruit beweegt is een signaal, geen schuld: het betekent dat de sessie is vervangen of dat de daemon opnieuw is gestart, en het juiste antwoord is de sessie-identiteit verzoenen in plaats van een negatief bedrag te crediteren.

Het ontkoppelpad vraagt dezelfde zorg. Als een laatste gebeurtenis totalen aan het einde van de sessie draagt, reken dan alleen het verschil met het laatst vastgelegde sample af. Het volledige totaal toevoegen nadat periodieke bemonstering al is afgerekend, is de meest voorkomende dubbele telling in zelfgebouwde bundelsystemen. Sessies die een periodegrens overschrijden hebben ook een regel nodig, omdat één eindtotaal geen informatie draagt over wanneer de bytes middernacht passeerden.

Laat uitputting de toelating weigeren, niet alleen de tunnel doden

Wanneer een account zijn limiet bereikt, moeten er twee dingen gebeuren: bestaande sessies eindigen en nieuwe worden geweigerd. Het beheerprotocol biedt client-kill per client-ID, wat de eerste helft afhandelt zolang je elke levende sessie van het account opsomt in plaats van het ene adres te doden dat je toevallig opmerkte.

De tweede helft is waar bundelontwerpen falen. Alleen doden is een race tegen de herverbindingslus van de client, die seconden later graag terugkomt. Toelating moet het gedeelde grootboek raadplegen, en bij een uitrol met meerdere gateways kan die controle geen bestand per machine zijn. Elke instantie die een login kan accepteren, moet dezelfde uitgeputte staat zien.

Herverbindingen op basis van tokens verdienen hun eigen test. OpenVPN 2.6 kan een sessietoken intern valideren met auth-gen-token, waarbij de externe authenticatieaanroep wordt overgeslagen die je controller gebruikte om het plafond af te dwingen. Een token dat nog geldig is bewijst dus identiteit, niet de resterende bundel, en elke nieuwe clientinstantie moet nog steeds het grootboek raadplegen. Als je in plaats daarvan management-client-auth inschakelt, wordt de controller de authenticator en erft de plicht om zelf de sessiestatus te analyseren en verlopen of ongeldige tokens te weigeren.

Accepteer de overschrijding die de bemonstering veroorzaakt

Periodieke waarneming plus ontkoppeling geven je een bemonsterde bundel met een bekende tolerantie. Een client kan ongeveer één rapportage-interval plus de tijd die de controller nodig heeft om te handelen overschrijden, en gelijktijdige sessies op één account vermenigvuldigen dat venster. Zeg dat in de interface in plaats van een exacte afsnijding op de laatste byte te adverteren die je niet kunt leveren.

Een echt hard plafond is een ander technisch probleem: handhaving binnen het doorstuurpad, gekoppeld aan hetzelfde account over sessies heen. Tellers sneller lezen is niet hetzelfde, en het overleeft geen client die gewoon meer tunnels opent.

Voer voor de uitrol de acceptatiegevallen uit die naïeve implementaties breken: herhaalde herverbindingen, twee apparaten tegelijk, herstarts van controller en gateway, een verloren ontkoppelgebeurtenis, een omslag midden in een sessie en een token-herverbindingspoging direct na uitputting. Bepaal daarna de faalmodus voor onderbrekingen in de boekhouding. Een duurzaam grootboek beschermt het gebruik dat je hebt vastgelegd; het kan waarnemingen die nooit aankwamen niet nieuw leven inblazen, en de klant verdient het te weten in welke van die twee situaties hij zit.