Où se situe un quota mensuel de données par compte OpenVPN

Un quota qui se réinitialise à chaque reconnexion du tunnel n’est pas une limite, et c’est exactement ce que l’on obtient lorsqu’un compteur d’octets est vissé sur un serveur VPN sans endroit où stocker un état durable. Le compteur appartient à une session ; le quota appartient à une personne ou à un contrat d’appareil. Toute la difficulté de la fonctionnalité vient de ce décalage, aussi les contrôles ci-dessous portent-ils sur l’endroit où vit l’état et sur la couche autorisée à décider.

Ancrez le quota sur un compte, pas sur un tunnel

Commencez par nommer le sujet du quota. Une personne peut détenir trois certificats d’appareil, et aucun d’eux ne devrait recevoir un budget mensuel indépendant simplement parce qu’ils s’authentifient séparément. Un identifiant de compte stable qui survit aux reconnexions, aux nouvelles adresses de tunnel et à un déménagement vers une seconde passerelle est le seul ancrage qu’un quota puisse utiliser. Le nom commun d’un certificat ne sert de clé que si votre politique d’émission garantit un compte par nom.

Une adresse de tunnel attribuée n’est jamais la réponse. Les adresses sont recyclées, les pools sont partagés, et le même compte peut apparaître deux fois sur deux passerelles dans la même minute. Si le grand livre s’appuie sur une adresse, se déconnecter puis se reconnecter suffit à remplir à nouveau le réservoir.

Consignez assez d’informations par session pour que l’arithmétique soit auditable : le compte, la période de facturation, l’instance de passerelle, l’identité de session, les derniers compteurs observés et le total engagé. Incluez une génération de démarrage du démon dans l’identité de session, car un serveur redémarré réutilise les identifiants de client et une correspondance naïve hériterait de la ligne de base précédente.

Fixez l’unité, le sens et la frontière de réinitialisation

Quatre définitions doivent être arrêtées par écrit avant toute collecte. Le quota compte-t-il les octets que le client envoie, ceux qu’il reçoit, ou la somme des deux ? Un gigaoctet vaut-il 10^9 octets ou 2^30 ? À quelle heure locale et dans quel fuseau la période bascule-t-elle ? Et que mesure exactement le compteur, sachant que la surcharge du tunnel et les retransmissions sont incluses alors que la taille du fichier applicatif et la facture d’un fournisseur ne le sont pas ?

Aucun de ces choix n’est faux, mais l’implémentation et le chiffre présenté au client doivent s’accorder. Deux moitiés d’un même système en désaccord sur le GiB, ou sur un basculement à minuit UTC au lieu de l’heure locale, produisent exactement le type de ticket qui érode la confiance dans tout le quota.

Transformez les totaux d’octets en un seul delta facturé

L’interface de gestion signale des lignes BYTECOUNT_CLI périodiques portant un identifiant de client et des totaux cumulés d’octets dans chaque sens, et la commande bytecount règle leur fréquence d’arrivée. Du point de vue du serveur, le chiffre reçu compte les octets envoyés par le client et le chiffre envoyé compte les octets qui lui ont été livrés. Réglez l’intervalle sur quelque chose que le grand livre peut absorber ; un intervalle très court achète une précision que vous n’obtenez pas réellement.

Une contrainte façonne toute la conception : la socket de gestion n’accepte qu’une seule connexion de contrôle. Un exportateur de supervision, une interface graphique et votre contrôleur ne peuvent pas chacun ouvrir la leur. Décidez quel processus possède le canal et laissez les autres lire l’état à partir de lui, car cette interface accorde des actions administratives et ne devrait de toute façon pas être exposée hors de l’hôte.

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

Engagez ensemble les nouvelles lignes de base et l’incrément d’usage, afin que rejouer un échantillon ne facture rien au lieu de facturer deux fois. Un compteur qui recule est un signal, pas une dette : il signifie que la session a été remplacée ou que le démon a redémarré, et la bonne réponse est de réconcilier l’identité de session plutôt que de créditer un montant négatif.

Le chemin de déconnexion demande le même soin. Si un événement final porte des totaux de fin de session, ne facturez que la différence avec le dernier échantillon engagé. Ajouter le total complet alors que l’échantillonnage périodique a déjà été facturé est le double comptage le plus courant dans les systèmes de quota maison. Les sessions qui chevauchent une frontière de période ont aussi besoin d’une règle, car un seul total final ne dit rien sur le moment où les octets ont franchi minuit.

Faites que l’épuisement refuse l’admission, pas seulement qu’il tue le tunnel

Lorsqu’un compte atteint sa limite, deux choses doivent se produire : les sessions existantes se terminent et les nouvelles sont refusées. Le protocole de gestion fournit client-kill par identifiant de client, ce qui règle la première moitié à condition d’énumérer chaque session vivante du compte au lieu de tuer la seule adresse que vous avez remarquée.

La seconde moitié est là où les conceptions de quota échouent. Une mise à mort seule est une course contre la boucle de reconnexion du client, qui reviendra volontiers quelques secondes plus tard. L’admission doit consulter le grand livre partagé, et sur un déploiement multi-passerelles ce contrôle ne peut pas être un fichier par machine. Chaque instance capable d’accepter une connexion doit voir le même état épuisé.

Les reconnexions par jeton méritent leur propre test. OpenVPN 2.6 peut valider un jeton de session en interne avec auth-gen-token, en sautant l’appel d’authentification externe que votre contrôleur utilisait pour faire respecter le plafond. Un jeton encore valide prouve donc l’identité, pas le quota restant, et chaque nouvelle instance de client doit toujours consulter le grand livre. Si vous activez plutôt management-client-auth, le contrôleur devient l’authentificateur et hérite de l’obligation d’analyser lui-même l’état de session et de rejeter les jetons expirés ou invalides.

Acceptez le dépassement que crée l’échantillonnage

L’observation périodique plus la déconnexion vous donnent un quota échantillonné avec une tolérance connue. Un client peut dépasser d’environ un intervalle de rapport plus le temps nécessaire au contrôleur pour agir, et les sessions simultanées sur un compte multiplient cette fenêtre. Dites-le dans l’interface au lieu d’annoncer une coupure exacte au dernier octet que vous ne pouvez pas fournir.

Un vrai plafond dur est un autre problème d’ingénierie : une application à l’intérieur du chemin de transfert, liée au même compte à travers les sessions. Lire les compteurs plus vite n’est pas la même chose, et cela ne résiste pas à un client qui ouvre simplement plus de tunnels.

Avant le déploiement, exécutez les cas d’acceptation qui cassent les implémentations naïves : reconnexions répétées, deux appareils à la fois, redémarrages du contrôleur et de la passerelle, un événement de déconnexion perdu, un basculement en milieu de session et une tentative de reconnexion par jeton juste après l’épuisement. Décidez ensuite le mode de défaillance en cas de panne de la comptabilité. Un grand livre durable protège l’usage que vous avez enregistré ; il ne peut pas ressusciter des observations qui ne sont jamais arrivées, et le client mérite de savoir dans laquelle de ces deux situations il se trouve.