Wohin ein monatliches Datenkontingent pro OpenVPN-Konto gehört

Ein Kontingent, das bei jeder Neuverbindung des Tunnels zurückgesetzt wird, ist keine Grenze, und genau das bekommt man, wenn ein Byte-Zähler an einen VPN-Server geschraubt wird, ohne einen Ort für dauerhaften Zustand. Der Zähler gehört zu einer Sitzung; das Kontingent gehört zu einer Person oder einem Gerätevertrag. Alles Schwierige an der Funktion rührt aus dieser Diskrepanz, deshalb geht es bei den Prüfungen unten darum, wo Zustand lebt und welche Schicht entscheiden darf.

Binden Sie das Kontingent an ein Konto, nicht an einen Tunnel

Beginnen Sie damit, das Subjekt des Kontingents zu benennen. Eine Person kann drei Gerätezertifikate halten, und keines davon sollte ein eigenes Monatsbudget bekommen, nur weil es sich getrennt authentifiziert. Eine stabile Konto-Kennung, die Neuverbindungen, neue Tunneladressen und einen Umzug auf ein zweites Gateway übersteht, ist der einzige Anker, den ein Kontingent nutzen kann. Der Common Name eines Zertifikats taugt nur dann als dieser Schlüssel, wenn Ihre Ausstellungsrichtlinie ein Konto pro Name garantiert.

Eine zugewiesene Tunneladresse ist nie die Antwort. Adressen werden wiederverwendet, Pools geteilt, und dasselbe Konto kann in derselben Minute zweimal auf zwei Gateways erscheinen. Wenn das Journal auf eine Adresse schlüsselt, genügt Trennen und Neuverbinden, um den Tank wieder zu füllen.

Halten Sie pro Sitzung genug fest, damit die Arithmetik prüfbar bleibt: das Konto, den Abrechnungszeitraum, die Gateway-Instanz, die Sitzungsidentität, die zuletzt beobachteten Zähler und die festgeschriebene Summe. Nehmen Sie eine Daemon-Startgeneration in die Sitzungsidentität auf, denn ein neu gestarteter Server verwendet Client-IDs wieder, und ein naiver Abgleich würde die vorherige Basislinie erben.

Legen Sie Einheit, Richtung und Rücksetzgrenze fest

Vier Definitionen müssen schriftlich festgelegt werden, bevor irgendeine Erfassung beginnt. Zählt das Kontingent Bytes, die der Client sendet, Bytes, die er empfängt, oder die Summe beider? Ist ein Gigabyte 10^9 Bytes oder 2^30? Zu welcher lokalen Stunde und in welcher Zeitzone rollt der Zeitraum um? Und was genau misst der Zähler, wenn Tunnel-Overhead und Neuübertragungen enthalten sind, die Dateigröße der Anwendung und die Rechnung eines Anbieters aber nicht?

Keine dieser Entscheidungen ist falsch, aber die Implementierung und die Zahl, die der Kunde sieht, müssen übereinstimmen. Zwei Hälften desselben Systems, die sich über GiB uneinig sind oder über einen Wechsel um Mitternacht UTC statt Ortszeit, erzeugen genau die Art Ticket, die das Vertrauen in das ganze Kontingent untergräbt.

Machen Sie aus Byte-Summen ein berechnetes Delta

Die Verwaltungsschnittstelle meldet regelmäßige BYTECOUNT_CLI-Zeilen, die eine Client-ID plus kumulative Byte-Summen in jeder Richtung tragen, und der Befehl bytecount legt fest, wie oft diese eintreffen. Aus Sicht des Servers zählt die empfangene Zahl die vom Client gesendeten Bytes, und die gesendete Zahl zählt die an ihn ausgelieferten Bytes. Setzen Sie das Intervall so, dass das Journal es aufnehmen kann; ein sehr kurzes Intervall kauft eine Präzision, die Sie tatsächlich nicht bekommen.

Eine Einschränkung prägt das ganze Design: Der Verwaltungs-Socket akzeptiert eine einzige Steuerverbindung. Ein Monitoring-Exporter, eine GUI und Ihr Controller können nicht jeweils eine eigene öffnen. Entscheiden Sie, welcher Prozess den Kanal besitzt, und lassen Sie die anderen den Zustand daraus lesen, denn diese Schnittstelle gewährt administrative Aktionen und sollte ohnehin nicht außerhalb des Hosts exponiert werden.

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

Schreiben Sie die neuen Basislinien und den Nutzungszuwachs zusammen fest, damit das erneute Abspielen einer Probe nichts berechnet, statt doppelt zu berechnen. Ein Zähler, der rückwärts läuft, ist ein Signal, keine Schuld: Er bedeutet, dass die Sitzung ersetzt oder der Daemon neu gestartet wurde, und die richtige Antwort ist, die Sitzungsidentität abzugleichen, statt einen negativen Betrag gutzuschreiben.

Der Trennungsweg braucht dieselbe Sorgfalt. Trägt ein abschließendes Ereignis Summen zum Sitzungsende, berechnen Sie nur die Differenz zur zuletzt festgeschriebenen Probe. Die volle Summe zu addieren, nachdem die periodische Probenahme bereits berechnet wurde, ist die häufigste Doppelzählung in selbstgebauten Kontingentsystemen. Sitzungen, die eine Zeitraumgrenze überschreiten, brauchen ebenfalls eine Regel, denn eine einzelne Endsumme enthält keine Information darüber, wann die Bytes Mitternacht passiert haben.

Erschöpfung soll die Zulassung verweigern, nicht nur den Tunnel töten

Wenn ein Konto sein Limit erreicht, müssen zwei Dinge geschehen: bestehende Sitzungen enden, und neue werden abgelehnt. Das Verwaltungsprotokoll bietet client-kill per Client-ID, was die erste Hälfte erledigt, solange Sie jede lebende Sitzung des Kontos aufzählen, statt die eine Adresse zu töten, die Ihnen zufällig aufgefallen ist.

Die zweite Hälfte ist der Punkt, an dem Kontingentdesigns scheitern. Ein Kill allein ist ein Wettlauf mit der Neuverbindungsschleife des Clients, die Sekunden später bereitwillig zurückkommt. Die Zulassung muss das geteilte Journal befragen, und bei einer Bereitstellung mit mehreren Gateways kann diese Prüfung keine Datei pro Maschine sein. Jede Instanz, die ein Login annehmen kann, muss denselben erschöpften Zustand sehen.

Tokenbasierte Neuverbindungen verdienen einen eigenen Test. OpenVPN 2.6 kann ein Sitzungstoken intern mit auth-gen-token validieren und überspringt damit den externen Authentifizierungsaufruf, mit dem Ihr Controller die Obergrenze durchsetzte. Ein noch gültiges Token belegt daher Identität, nicht verbleibendes Kontingent, und jede neue Client-Instanz muss weiterhin das Journal befragen. Wenn Sie stattdessen management-client-auth aktivieren, wird der Controller zum Authentifikator und erbt die Pflicht, Sitzungszustand selbst zu parsen und abgelaufene oder ungültige Tokens selbst abzulehnen.

Akzeptieren Sie die Überschreitung, die die Probenahme erzeugt

Periodische Beobachtung plus Trennung ergeben ein beprobtes Kontingent mit bekannter Toleranz. Ein Client kann um etwa ein Meldeintervall plus die Zeit überschießen, die der Controller zum Handeln braucht, und parallele Sitzungen auf einem Konto vervielfachen dieses Fenster. Sagen Sie das in der Oberfläche, statt einen exakten Schnitt am letzten Byte zu versprechen, den Sie nicht liefern können.

Eine echte harte Obergrenze ist ein anderes Ingenieursproblem: Durchsetzung im Weiterleitungspfad, gebunden an dasselbe Konto über Sitzungen hinweg. Zähler schneller zu lesen ist nicht dasselbe, und es übersteht keinen Client, der einfach mehr Tunnel öffnet.

Führen Sie vor dem Rollout die Abnahmefälle aus, die naive Implementierungen brechen: wiederholte Neuverbindungen, zwei Geräte gleichzeitig, Neustarts von Controller und Gateway, ein verlorenes Trennungsereignis, ein Wechsel mitten in der Sitzung und ein Token-Reconnect direkt nach der Erschöpfung. Legen Sie dann den Fehlermodus für Ausfälle der Abrechnung fest. Ein dauerhaftes Journal schützt die erfasste Nutzung; es kann Beobachtungen, die nie ankamen, nicht wiederbeleben, und der Kunde verdient zu wissen, in welcher der beiden Situationen er steckt.